Who should own identity recovery when Entra ID or Okta is disrupted?

Why This Matters for Security Teams

When Entra ID or Okta is disrupted, identity recovery becomes a business continuity problem, not just an IAM ticket queue. Ownership has to span IAM engineering, infrastructure operations, incident command, and communications because the same control plane governs privileged access, recovery accounts, and audit evidence. NHI recovery is especially unforgiving: the Ultimate Guide to NHIs notes that 91.6% of secrets remain valid five days after notification, which shows how often remediation lags behind the incident itself. That delay matters because recovery steps often rely on secrets, service accounts, and break-glass paths that are easy to forget until the directory is already degraded. For governance, the right lens is continuity of identity services under NIST Cybersecurity Framework 2.0, where restoration, communications, and validation are all explicit operational outcomes. In practice, many security teams discover ownership gaps only after users cannot authenticate, automation fails, and no one has authority to validate the restored trust chain.

How It Works in Practice

The practical model is a three-way split with one accountable owner. IAM owns identity restoration logic, recovery policies, admin role reconstitution, and directory integrity checks. Operations owns platform availability, DNS, network dependencies, device access, and any failover required to reach alternate administration paths. Crisis management owns decision timing, executive reporting, customer or employee communications, and approval for emergency exceptions. That structure is consistent with the governance approach in the Top 10 NHI Issues and the incident patterns described in the 52 NHI Breaches Analysis. The recovery plan should include:

• Offline copies of recovery procedures, admin break-glass paths, and contact trees.
• Pre-approved validation steps for authentication, MFA, role assignment, and token issuance.
• Separate evidence capture for who restored access, when, and under what authority.
• Checks for service accounts, API keys, and automation tokens that depend on the identity provider.

A strong plan also distinguishes human recovery from NHI recovery. Human admin access may come back first, but workloads still need workload identity, secret rotation, and authorization validation before the environment is safe to resume normal operation. Current guidance suggests aligning this with zero-trust recovery principles, not assuming a restored login page means a restored identity fabric. These controls tend to break down when the directory outage also affects the very admin channels needed to execute the recovery steps because alternate authority was never rehearsed.

Common Variations and Edge Cases

Tighter recovery control often increases coordination overhead, requiring organisations to balance speed against evidence, separation of duties, and change approval. The main variation is whether the disruption is a service outage, a tenant lockout, or a suspected compromise, because each one changes who can approve emergency access and how much validation is required. If the directory is merely unavailable, the focus is restoration and failover. If it is suspected to be compromised, identity recovery must include containment, credential revocation, and forensic preservation before full service is reopened. Best practice is evolving for hybrid environments where Entra ID or Okta is only one part of a larger identity mesh, because local AD, VPN, PAM, and SaaS apps may each depend on different trust anchors. That is why the JetBrains GitHub plugin token exposure case is useful as a reminder that recovery often fails at the secret layer, not the login layer. For validation, NIST Cybersecurity Framework 2.0 supports a response-and-recovery mindset, but there is no universal standard for exact ownership matrices yet. The most reliable pattern is a named incident owner in IAM, an operational recovery lead, and a crisis manager with authority to decide when identity service is safe to trust again.

Related resources from NHI Mgmt Group

• Why does Entra ID SSPR fall short in hybrid environments?
• Who should own the move from legacy PAM to identity-driven access?
• When does a machine identity become a compliance problem?
• Why is it important to integrate identity and data governance?