Perspective
Identity Recovery Is Its Own Workflow
Key Finding
Identity recovery is a distinct workflow with its own dependencies. Designing it after the rest of DR has been designed produces a recovery plan that does not work when it is needed.
The 2024 CrowdStrike Falcon outage, the recurring Microsoft Entra ID disruptions, and the Okta support-system breach all share a property that most DR plans do not handle: the failure surface included identity itself. The conventional plan — restore systems, log users in, investigate — assumes the IdP is available and that the operations team can authenticate to the tools they need.
The architectural fix is to treat identity recovery as a workflow with its own dependency graph:
- Break-glass authentication that does not depend on the same IdP that failed. - BitLocker, KMS, HSM, and admin-recovery keys held outside the identity service that protects them. - Tenant baselines (policies, roles, federation trusts, lifecycle rules) held as code with point-in-time restore. - Forensic-grade audit retention measured in years, in a store outside the platform whose actions it records. - Drill cadence that exercises the workflow at scale — not a tabletop, an actual recovery.
We operate this workflow through our Identity Resilience practice. The tenants stay where they are; the resilience layer runs alongside them. The first time the IdP is the service that needs recovering, the plan is the one that meets the moment.
Need help with your identity architecture?
Every incident on this page was preventable with the right architecture. Let's talk about yours.
Book a Conversation