Identity resilience glossary
Identity failover
Identity failover is the transfer of authentication service to a prepared alternative when the primary identity service cannot support the required sign-ins. It aims to keep selected applications accessible during a disruption. It requires compatible application trust, identity data, and access controls; having a second identity tenant or a backup alone does not provide working failover.
Failover is different from restore
A restore brings back saved identity data or configuration. Failover changes which service handles access requests. Either may be part of a business continuity plan, but they address different problems. Restoring a deleted application assignment does not switch authentication providers. Switching providers does not necessarily repair the primary environment or preserve every application's behavior.
An application continuity example
Consider a customer portal whose primary authentication service becomes unavailable. A prepared alternative is useful only if the portal accepts its identity tokens and the right customers can use it. The team must also account for access rules and the user experience. If customers can sign in but cannot reach their orders, the business workflow has not recovered.
Why another tenant is not enough
Applications rely on specific trust settings, not just a provider's name or support for the same protocol. OpenID Connect, for example, identifies an issuer and publishes endpoints and signing-key information. A different tenant cannot be assumed to act as an interchangeable replacement. Adding another identity system also adds dependencies that must be understood and maintained.
What to establish before relying on failover
Document the applications covered, how switching is triggered, which identities and controls remain available, and how the primary service will resume operation. Failover commonly implies automatic switching; a planned or operator-led transition may be described as a switchover. Confirm the actual behavior instead of assuming zero downtime. Test an end-to-end access journey and the return path, not only whether the alternative service responds.