Emergency break-glass accounts: zero-trust architecture for absolute disaster recovery

Define the recovery boundary

Break-glass accounts provide an alternative administrative path, not absolute disaster recovery. NIST describes zero trust as protecting resources without implicit trust based on network location or asset ownership, with authentication and authorization performed before a resource session. Emergency access therefore needs explicit authentication and governance even when ordinary access controls become unavailable. As a design recommendation, document which failures the recovery path addresses and which dependencies remain; independence from a federated identity provider does not establish independence from every supporting service.

Microsoft recommends at least two cloud-only emergency accounts using the .onmicrosoft.com domain, neither federated nor synchronized from an on-premises environment. Assign Global Administrator as permanent active rather than eligible in Privileged Identity Management, avoiding dependence on role activation and unavailable approvers. Keep cloud and on-premises emergency access distinct. For implementation review, trace each account’s authentication and administrative-access dependencies, confirm its assignment, and verify that employee departures or changes to the federated directory cannot remove its recovery path.

Evidence: Manage emergency access accounts in Microsoft Entra ID, Zero Trust Architecture

Preserve strong authentication while removing blocking dependencies

Microsoft recommends phishing-resistant passwordless authentication: passkeys using FIDO2, or certificate-based authentication where the organization already has a public key infrastructure. These methods satisfy the documented mandatory multifactor authentication requirements; emergency access is not permission to abandon strong authentication. Use an authentication method different from ordinary administrative accounts and avoid employee-supplied devices. Microsoft also requires designated secure workstations. As an engineering recommendation, review credential custody, workstation availability, and any certificate infrastructure dependencies together before accepting the recovery design.

Microsoft directs organizations to exclude emergency accounts from Conditional Access policies that block or restrict sign-in, because those controls could prevent access during an emergency. Report-only policies do not block access and need no exclusion. A dedicated emergency-account security group is the documented approach for managing exclusions. Review membership and policy coverage after policy changes as an operational recommendation. Exclusion does not automatically make an account safe; retain phishing-resistant authentication, secure credential custody, restricted emergency use, and monitoring.

Evidence: Manage emergency access accounts in Microsoft Entra ID

Make every use visible and actionable

Microsoft recommends monitoring emergency-account sign-in and audit activity, configuring alerts for every use, and retaining logs for review. High-priority paging is an operational recommendation, not a documented automatic product behavior in the supplied evidence. Route these alerts to responders authorized to investigate privileged activity, and establish an acknowledgment and escalation procedure. Review whether the notification path shares dependencies with normal identity services. During validation, confirm that an actual test sign-in produces the expected alert and reaches the intended responder.

The response procedure should establish who accessed the credential, whether an emergency justified use, and which administrative actions followed. Microsoft calls for a post-mortem after any emergency-account use to assess authorization and appropriateness. As a practical recommendation, prepare responders for planned validation without suppressing the monitoring being tested, and document who must investigate unexplained activity. Treat a successful page as evidence that one notification path worked during that drill, not proof that all future incidents will be detected.

Evidence: Manage emergency access accounts in Microsoft Entra ID

Rotate credentials without sacrificing the fallback

The supplied Microsoft guidance requires credentials and devices not to expire or fall within automated cleanup for inactivity; it does not document an automatic safe-rotation mechanism. Recommended procedure: verify one emergency account remains usable before changing the other. Register and test the replacement credential from the designated secure workstation, confirm administrative functionality, and verify alert delivery before retiring the previous credential. If validation fails, stop the planned replacement and preserve the working recovery path rather than modifying both accounts together.

After successful validation, secure the replacement credential and update custody records before repeating the process for the second account. Microsoft recommends separate, secure, fireproof storage locations accessible to authorized administrators and account validation at least every 90 days. Use that review to check authorized users, account state, permanent active roles, authentication, Conditional Access exclusions, administrative tasks, and monitoring. As an additional operational recommendation, repeat relevant checks after configuration changes or emergency use; a completed checklist reduces uncertainty but cannot guarantee recovery.

Evidence: Manage emergency access accounts in Microsoft Entra ID