Emergency Identity Operations When the Primary IdP Is Unavailable: Keep critical work running safely

When the primary identity provider goes down, or has to be taken offline because it has been compromised, almost every application, administrator and incident responder loses the ability to sign in at once. Single sign-on concentrates access in one place, which is good for security and bad for continuity unless you have planned for the IdP being unavailable. This guide covers emergency identity operations: classifying what must keep working, the fallback mechanisms that exist, how to switch to them without opening the door to attackers, how to keep workloads and non-human identities running, and how to return to normal. It is for IAM architects, infrastructure and continuity leads, and incident responders. Emergency administrator accounts themselves are covered in the Break-Glass Account Guide; this page is about running the business and the response through the outage.

Key takeaways

• Classify before the outage. Decide which applications must work within minutes, hours or days, and what level of access is acceptable for each when normal controls are missing. Decisions made during an outage are rushed and too permissive.
• Know which failure you are in. A cloud IdP outage, an on-premises federation or directory failure, an MFA provider outage and a compromised IdP need different responses. The last one forbids most of the shortcuts that help with the first three.
• Prepare contingency policies in advance and keep them disabled. Pre-built, reviewed, report-only fallback policies that can be switched on in minutes are safer than editing production policy under pressure.
• Responders need an access path that does not depend on the IdP. Out-of-band communications, local or cloud-native emergency accounts and offline documentation must exist before you need them.
• Every emergency change must be reversed and reviewed. Log each step, revoke tokens and credentials used during the event, and restore normal policy on a checklist, not from memory.

Failure scenarios and what they allow

Classifying what must keep working

Microsoft's guidance on resilient access control classifies applications by tolerable downtime: category 1 within minutes (revenue-critical), category 2 within hours and category 3 within days. For categories 1 and 2 it recommends deciding in advance what level of access is acceptable (full, restricted session or limited), which access avenues stay open (for example browser only, corporate network only or named countries) and whether policies should fail open or closed. That approach applies to any IdP.

Deciding between fail open and fail closed

For each category 1 and 2 function, record whether access should continue with reduced controls (fail open) or stop (fail closed) when a control such as MFA or device compliance cannot be evaluated. The choice is a business decision, signed by the application owner and the security owner, not something an on-call engineer should decide at 3am.

• Fail closed by default for: administrative access, payment and money movement, access to regulated personal data, and any system an attacker could use to persist.
• Consider restricted fail open for: read-only email and documents from managed devices, customer communications and safety-critical operational information, where stopping work causes more harm than a narrowly scoped, monitored exception.
• Never fail open when compromise is suspected: the same policy that helps in an outage gives an attacker an easier path.

Fallback mechanisms

Provider resilience features

Some cloud IdPs keep working through partial outages. Microsoft Entra ID's backup authentication system, for example, can re-authenticate a user if they authenticated to the same application on the same device within the last three days, do not need an interactive sign-in, are in their home tenant and have had no revocation event since. It protects managed identities but not other service principals, protects SAML applications configured for IdP-initiated sign-on but not SP-initiated sign-on, and cannot perform fresh certificate revocation checks during the outage. Know what your provider's resilience covers and design for it: some Conditional Access settings, such as disabling resilience defaults, remove users from that protection. Sign-ins served this way can be found in the sign-in logs by filtering on token issuer type Microsoft Entra Backup Auth.

Contingency access policies

• Pre-built and disabled: create the fallback policies now, review them, and keep them in report-only or disabled state. Microsoft recommends a naming convention such as EMnnn - ENABLE IN EMERGENCY: [Disruption][i/n] - [Apps] - [Controls] [Conditions] so responders can find and enable them in the right order.
• Compensating controls, not removed controls: when MFA is unavailable, require a compliant or hybrid-joined device, a corporate network location and a restricted, browser-only session, and limit the policy to a named contingency group.
• Ordered activation: add the restrictive policies first, then relax the failed control for the contingency group only, then confirm users outside the group are blocked.

Alternative authentication paths

• Cloud authentication behind federation: for hybrid environments, Microsoft recommends enabling password hash synchronisation even when federation or pass-through authentication is the primary method, so sign-in can be switched to the cloud if on-premises components fail.
• Multiple MFA channels: users registered for methods that use different channels (an app over the internet, a hardware or software OATH token, a platform authenticator) are not all affected by one provider failure. Prefer phishing-resistant methods; see the Phishing-Resistant MFA Guide.
• Direct federation for cloud consoles: AWS documents emergency access for when IAM Identity Center is unavailable but the external IdP is not, using direct SAML federation from the IdP to individual accounts, and points to break-glass access when the IdP itself cannot be relied on. AWS stresses that this must be deployed before a disruption, because you may not be able to create the roles during one, and tested periodically.
• Local emergency accounts: for critical infrastructure (hypervisors, network devices, backup systems, PAM vault), keep local accounts with strong credentials in an offline or independently hosted vault. These must not depend on the IdP that has failed.

Running the emergency

1. Declare and classify: the incident lead confirms the scenario from the table above. If compromise is suspected, treat it as compromise until proven otherwise.
2. Switch communications: move the response team to an out-of-band channel that does not use the primary IdP, with a pre-agreed contact list.
3. Enable category 1 access: responders and operators use emergency accounts or provider-native emergency access. Every use is logged and announced in the response channel.
4. Apply contingency policies in order: only those prepared for the scenario, only for named groups, with each change recorded with time and person.
5. Tell users what to expect: which services are available, how to reach the help desk, and that the help desk will not ask for passwords or MFA codes. Outages attract opportunistic social engineering.
6. Increase monitoring: watch sign-ins under contingency policies, use of emergency accounts and any changes to identity configuration.
7. Hold the line on privilege: no new standing admin rights, no shared accounts, no disabling of MFA for administrators.

Workloads and non-human identities during an outage

Services, pipelines and automation often authenticate through the same IdP or rely on tokens it issues. Plan for them separately.

• Know which workloads depend on the IdP: service accounts, OAuth client credentials, federated workload identities and SCIM connectors. Some, such as managed identities in Microsoft's backup system, may continue to work; others will fail when tokens expire.
• Avoid emergency static secrets: creating long-lived keys to keep a pipeline running during an outage leaves credentials that outlive the event. If unavoidable, give them an expiry, an owner and a rotation task in the recovery checklist.
• Customer-facing workload identity should not depend on the workforce IdP: separating them limits the blast radius of a workforce outage. See the Workload Identity Federation Guide.
• Token lifetime trade-off: longer-lived tokens survive short outages but slow revocation. Continuous access evaluation, where supported, lets providers issue longer-lived tokens while still revoking on events such as account disablement, password change or explicit revocation.

Returning to normal

1. Confirm the IdP is healthy and, after a compromise, that trust has been re-established (signing keys rotated, malicious configuration removed).
2. Disable contingency policies in reverse order and confirm normal policies are enforced.
3. Rotate credentials of every emergency account used, and revoke refresh tokens for accounts used during the event, as Microsoft recommends.
4. Revoke or rotate any emergency static credentials created for workloads.
5. Archive sign-in and audit logs for the event period and review all access made under contingency policies.
6. Run a post-incident review: what failed, which fallbacks worked, and how long each step took.

Implementing the capability

1. Map dependencies: for each category 1 and 2 function, trace authentication end to end, including on-premises components, MFA providers and DNS.
2. Build fallbacks: emergency accounts per critical platform, contingency policies, alternative authentication paths and an out-of-band communications channel.
3. Write the runbook: one page per scenario, with activation order, roles, and the reversal steps. Keep an offline copy.
4. Test in a tabletop: walk through each scenario with IAM, infrastructure, security and business owners.
5. Test for real: enable contingency policies for a test group in a maintenance window, sign in with each emergency account, and fail over a pilot application. Microsoft suggests monitoring report-only contingency policies with Conditional Access insights before you ever need them.
6. Repeat: at least twice a year and after every significant IdP or policy change.

Small organisations: two cloud-only emergency accounts with phishing-resistant credentials, a second MFA method for every user, local admin access to critical devices and a phone tree cover most scenarios. Large organisations: add per-platform emergency access, pre-built contingency policy sets per scenario, and an independent response environment for IdP compromise.

Detection and measurement

• Alert on every emergency account sign-in and every activation of a contingency policy, outside a planned test.
• Time to category 1 access: measured in tests from declaration to responders working; set a target in minutes.
• Runbook test coverage: share of scenarios tested in the last six months.
• Users with two or more MFA methods on different channels: a direct measure of resilience to MFA outages.
• Emergency changes reversed within 24 hours of recovery: target 100 percent.
• Critical systems with an IdP-independent access path: tracked per category 1 system.

Framework mapping

Common failure patterns

• Emergency accounts federated to the failed IdP: they fail with everything else.
• Response communications on the same identity platform: the team cannot coordinate when chat and email need the IdP.
• Disabling MFA globally: the quickest fix becomes the attacker's opportunity, and is often forgotten when service returns.
• Untested contingency policies: written once, never enabled, and wrong when needed.
• Emergency static secrets left behind: keys created to keep a pipeline running remain valid for years.
• Treating a compromise as an outage: enabling relaxed policies while an attacker still controls the IdP.

Lessons from incidents

In the MGM Resorts breach, the attackers said a help desk call gave them administrator access to the company's identity provider and cloud tenants, and systems were disrupted for about ten days. When the IdP itself is in attacker hands, the response team cannot rely on it to coordinate or to administer recovery. That is the scenario that most needs pre-staged emergency access, out-of-band communications and an agreed decision on what to shut down, and it is the one where contingency shortcuts built for ordinary outages must stay switched off.

Practitioner checklist

• Applications classified by tolerable downtime, with an approved emergency access level for each.
• Runbook per scenario: cloud IdP outage, on-premises dependency, MFA outage, network failure, IdP compromise.
• Emergency accounts per critical platform that do not depend on the primary IdP, with phishing-resistant credentials.
• Contingency access policies built, named for emergency use and kept disabled or report-only.
• Alternative authentication path prepared (for example synchronised password hashes behind federation).
• Users registered for at least two MFA methods on different channels.
• Out-of-band communications and offline runbook copies ready.
• Workload and NHI dependencies on the IdP mapped, with no plan that relies on new static secrets.
• Alerts on emergency account use and contingency policy activation.
• Full test at least twice a year, with recovery and reversal steps timed.

Standards and references

• Microsoft Learn: Create a resilient access control management strategy
• Microsoft Learn: Microsoft Entra ID backup authentication system
• Microsoft Learn: Build resilience with continuous access evaluation
• AWS: Emergency access to the AWS Management Console
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• MITRE ATT&CK: Account Access Removal

Related NHI Mgmt Group resources: IAM and IdP Buyer's Guide · Break-Glass Account Guide · Identity Provider Tenant Compromise Playbook · Major IT Outage Lessons Guide · Identity Platform Migration