Break-glass accounts in Microsoft Entra ID: design, governance, and what mandatory MFA changes
A Conditional Access policy gets pushed with the wrong scope, or federation goes down, or a PIM dependency breaks at the worst possible time. When that happens, the break-glass account is the last key to the building. Its value is exactly proportional to how well it was designed and how rarely it gets used. This article covers how to build one that actually works, what mandatory MFA enforcement changed for these accounts specifically, and how to run a governance process that does not just sit in a drawer.
Two common failure modes
Most environments land in one of two states. Either there are no break-glass accounts at all, or there are accounts that exist on paper but are not fit for purpose.
The second case is the dangerous one, because it looks solved. The account is PIM-eligible instead of permanently active, so it cannot activate its role when PIM is the thing that broke. Or it uses Authenticator push, which depends on a phone and a network that may be exactly what is down. Or it was never excluded from Conditional Access, so a bad policy takes it out along with everyone else. Or nobody monitors it, so a sign-in by that account would go unnoticed.
Recognize your own tenant in either of those, and the rest of this article is the fix.
Design principles
These are the decisions that make a break-glass account dependable. Each one prevents a specific way the account fails when you need it.
| Principle | Why it matters | The mistake it prevents |
|---|---|---|
| Cloud-only account, no federated identity | The account must not depend on on-premises infrastructure or an external IdP | A federation outage locks out the account meant to recover from outages |
| Permanent active Global Administrator role, not PIM-eligible | The role must be usable without activation | If PIM is broken, a PIM-eligible account cannot activate and is useless |
| FIDO2 security key as the auth method | Phishing-resistant, no dependency on a phone number or push service | SMS and voice can be ported or spoofed; push depends on a working network and device |
| Excluded from all CA policies via a dedicated group | A misconfigured policy must not take out the recovery path | A blanket CA block with no exclusion locks out the entire tenant, including the fix |
| Excluded from any MFA registration campaign | The account should not be forced into a different method mid-emergency | A campaign overwrites or interferes with the FIDO2 method the account depends on |
| A second strong method registered (second FIDO2 key or certificate-based auth), stored separately | A backup way in if the primary FIDO2 key is lost or unreachable, without falling back to a weaker method | A single point of failure if only one method exists, or a quiet downgrade to phone-based MFA in an emergency |
| Two accounts minimum, credentials in different locations | No single physical or digital location holds complete access | One safe, one person, or one compromised store takes out all emergency access |
| Clear naming convention | The accounts are recognizable in sign-in logs at a glance | Generic names make a real break-glass sign-in indistinguishable from noise during an incident |
Microsoft's current guidance is a FIDO2 security key as a physical device, stored securely, not a software passkey on a phone (source: learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access). The phone dependency is the whole point of avoiding it.
The SG-BreakGlass-Exclude group with both Emergency Access accounts as members.
What mandatory MFA enforcement means for break-glass accounts
This is the part of the design that changed, and it is the one most people have not fully worked through.
Microsoft's mandatory MFA enforcement is complete. The gradual rollout began in October 2024, covering the Azure portal, Entra admin center, and Intune admin center, and rolled out to tenants worldwide through 2025. Phase 2 began October 1, 2025 and covered Azure CLI, PowerShell, the Azure mobile app, IaC tools, and REST API control plane endpoints, where create, update, and delete operations require MFA and read-only operations are exempt. Microsoft 365 admin center enforcement began February 2025.
Break-glass accounts are in scope. There is no exception. The Microsoft Learn page states it directly: the system enforcement applies to all user accounts, regardless if they are a break-glass account. (source: learn.microsoft.com/en-us/entra/identity/authentication/concept-mandatory-multifactor-authentication)
The part that’s easy to overlook: a Conditional Access exclusion does not exempt a break-glass account from this. The enforcement happens at the client application level, independent of how Conditional Access evaluates. Excluding the account from every CA policy still leaves it subject to mandatory MFA.
The practical consequence is sharp. If a break-glass account has only a password registered and no FIDO2 or certificate-based authentication, it cannot sign in to the Azure portal, the Entra admin center, or the Intune admin center. The account fails at the exact moment it is needed. Microsoft's recommendation is to register a FIDO2 passkey or configure certificate-based authentication on these accounts so they satisfy the requirement. If your break-glass accounts predate this enforcement and were set up with password-only access, that is the first thing to fix.
Both Emergency Access accounts hold Global Administrator as a permanent active assignment, shown under Active assignments in PIM rather than Eligible.A lab finding worth borrowing
In my lab, the exclusion group sits across all 11 Conditional Access policies, CA002 through CA012, with both Emergency Access accounts as members.
The reason that matters showed up while building the baseline.
One policy, CA005, started with zero client-apps conditions. With nothing scoped under client apps, it evaluated as a blanket all-traffic block. If that policy had carried no break-glass exclusion, the accounts I was using to troubleshoot would have been caught in the same block I was trying to fix. The exclusion group is what kept the recovery path open while the policy that caused the problem was still live. That is the difference between an exclusion group as good hygiene and an exclusion group as the thing that saves the tenant.
Governance is ongoing, not a one-time build
A break-glass account is not a configuration artifact you set once. It is a live operational control, and it decays. The FIDO2 key gets misplaced, role assignments drift, a sign-in goes unreviewed. Four activities keep it real, each on a cadence.
Sign-in log monitoring. Alert on any sign-in by either account. Outside a planned test, that number should be near zero, so any sign-in is worth a look. Review monthly at minimum.
Credential verification. Confirm the FIDO2 key still works and the account can actually complete a sign-in. Test quarterly and document the result. A key that fails during an incident is the same as no key.
Access review. Confirm the accounts still hold only Global Administrator and no other roles have been added. Quarterly.
Physical credential audit. Confirm the FIDO2 keys are where they are supposed to be and reachable by the people who would need them. Annual at minimum.
What these accounts are not
A break-glass account is not a shared admin login for routine work, and it is not a convenient fallback for everyday role elevation. Either of those turns the account into a liability instead of a safeguard. A sign-in outside a genuine emergency should trigger an incident review, every time.
Questions about which path fits your environment are welcome. Please feel free to reach out.
