Emergency access accounts: the control that stops MFA from locking you out

Most identity hardening projects work forwards: enforce multi-factor authentication, require compliant devices, tighten Conditional Access, reduce standing privilege. Each step reduces the chance an attacker signs in. Each step also adds one more thing that has to be working for you to sign in.

The failure this creates is quiet. Nothing breaks on the day the policy is deployed. It breaks months later, during an outage, when the people who need to fix the problem discover that the controls protecting the tenant are also the controls locking them out of it.

How administrative lockout actually happens

Microsoft's guidance on emergency access accounts lists the situations that lock an organization out of its own tenant. They are worth reading carefully, because none of them involve an attacker.[1]

• Accounts are federated and the identity provider is unavailable, so sign-in redirects to a service that cannot answer.
• Administrators registered for MFA using methods that depend on a mobile network, and that network is unavailable.
• The person holding the most recent Global Administrator access leaves. Entra ID prevents deletion of the last Global Administrator, but it does not prevent that account being disabled on-premises.
• A natural disaster makes phones or networks unreachable.
• Every Global Administrator assignment is eligible rather than active, activation requires approval, and no valid approver remains in the directory.

That last one deserves attention. It is a pure configuration deadlock: a tenant can be fully healthy, with no outage anywhere, and still be administratively unreachable because the approval chain points at nobody.

Emergency access accounts are the standard answer

Microsoft's recommendation is to maintain at least two emergency access accounts, sometimes called break-glass accounts, and to treat them as infrastructure rather than as user accounts.[1]

The configuration requirements matter more than the concept:

• Cloud-only, on the .onmicrosoft.com domain. No federation, no directory synchronisation. An account that depends on the on-premises environment cannot rescue you from an on-premises failure.
• Phishing-resistant authentication that differs from normal admin accounts. Microsoft recommends passkeys (FIDO2) or certificate-based authentication. If daily administration uses the Authenticator app, the emergency account should not.
• Not tied to an individual. Credentials belong in a known secure location available to several members of the administration team, not on an employee's phone.
• Permanently active, not eligible. In Privileged Identity Management, the Global Administrator assignment must be active permanent. An eligible assignment reintroduces the approval dependency the account exists to bypass.
• Credentials and devices must not expire or fall within automated cleanup for inactivity. Accounts designed to sit unused are exactly the ones lifecycle automation tends to remove.

The Conditional Access exclusion is the part people get wrong

Microsoft is explicit: exclude emergency access accounts from Conditional Access policies that block or restrict sign-in. An emergency account subject to a policy requiring MFA or a compliant device may be unusable during precisely the scenario it exists for.[1]

Two details commonly get missed.

First, report-only policies do not need an exclusion, because they do not block access. Excluding them anyway adds noise without adding safety.

Second, an exclusion is not a free pass. The protection has moved to the authentication method — which is why the phishing-resistant credential requirement is not optional. An excluded account with a password and no strong second factor is not an emergency measure; it is a standing risk with a justification attached.

The practical approach is a dedicated security group, conventionally named something like EmergencyAccess, excluded from blocking policies. Using a group rather than naming accounts individually means a new policy written next year inherits the exclusion by design rather than by memory.

An untested emergency account is an assumption

This is the recurring theme in our work on recovery evidence, and identity is no exception. Microsoft recommends validating emergency access accounts at least every 90 days, and testing quarterly that they can still sign in under the current Conditional Access configuration.[1]

The reason is drift. Conditional Access policies accumulate. Someone writes a new policy scoped to "All users" without knowing the exclusion convention. A credential expires. A device is decommissioned. None of these produce an alert, and all of them are invisible until the account is needed.

A validation drill should confirm three things, not one:

1. The account can sign in.
2. The account can perform an administrative task once signed in.
3. The list of people authorised to use it is still correct.

Microsoft's "What If" evaluation tool is useful here: run it against an emergency account and confirm that only the intended policies apply. Anything unexpected in that result is a finding.

Detection has to compensate for the exclusion

An account excluded from your strongest preventive controls needs proportionate detective controls. Microsoft's guidance is to alert on every sign-in by an emergency access account and to review both sign-in and audit logs.

The signal quality here is unusually good. A correctly managed emergency account should sign in roughly four times a year, during scheduled validation. Any other sign-in is either a genuine emergency or an incident. Few alerts in an identity estate have that little ambiguity, which makes this one worth configuring properly and routing somewhere a human will actually see it.

Microsoft also recommends a post-mortem after any use: was it authorised, and were the actions taken appropriate? That review is what separates a governed control from an unmonitored back door.

Where this fits in a wider MFA rollout

The Canadian Centre for Cyber Security recommends MFA wherever possible to protect high-value business services and data,[2] and publishes specific guidance on deploying it effectively.[3] Its advice includes a consideration directly relevant here: if a user misplaces a token, they lose account access.[2]

That risk applies to the whole organisation, not just administrators. A complete rollout plan should answer what happens when a factor is lost, at three levels:

• Standard users need a documented, identity-verified reset path that does not depend on the lost factor.
• Administrators need a second registered method that does not share a dependency with the first — not two methods that both require the same phone.
• The tenant itself needs emergency access accounts, for the case where the administrative path fails entirely.

Most organisations we see have thought about the first level, occasionally the second, and rarely the third.

Keep cloud and on-premises emergency access separate

Where Active Directory Federation Services or a similar identity provider is in use, Microsoft's guidance is to keep emergency access for on-premises systems and for cloud services distinct, with no dependency between them.[1] Sourcing authentication for a privileged emergency account from another system adds risk if that system is the one having the outage.

The same reasoning extends beyond Microsoft's estate. Network devices, hypervisors, backup systems and cloud provider consoles each have their own lockout modes. An organisation that has solved emergency access for Entra ID alone has solved one of several. The privileged access review worksheet is a reasonable way to enumerate the rest.

A reasonable starting point

If none of this is currently in place, the sequence that produces the most risk reduction per unit of effort is:

1. Create two cloud-only emergency access accounts with phishing-resistant credentials.
2. Create a dedicated security group and exclude it from blocking Conditional Access policies.
3. Make the Global Administrator assignment permanently active, not eligible.
4. Configure alerting on any sign-in by those accounts.
5. Store the credentials in separate secure physical locations, with a documented list of who may use them.
6. Schedule a validation drill every 90 days and record the result.

None of this is expensive. It takes an afternoon to configure and a recurring calendar entry to maintain. What makes it valuable is that it is one of the few controls whose absence is invisible until the worst possible moment.

If you want this reviewed against your actual tenant configuration rather than against a checklist, that is the kind of bounded work our cybersecurity assessments cover, and the approach page explains how the engagement runs.