Conditional Access break-glass account design

Conditional Access policies are powerful and brittle. A configuration error can lock every admin out of the tenant simultaneously — including the admins who'd need to fix the policy. Break-glass accounts are the safety net: emergency-access accounts that survive any CA disaster and let you recover.

What a break-glass account is

A break-glass account:

Has Global Administrator role (permanent active, not PIM-eligible).
Is excluded from every Conditional Access policy.
Has a very strong unique password stored offline.
Is monitored for unusual sign-in activity.
Is rotated periodically.
Is used only in emergency.

The goal: when nothing else works, this account does.

Why you need at least two

A single break-glass account is one device-failure away from total lockout. Standard practice is at least two break-glass accounts:

Independent strong passwords stored separately.
Independent FIDO2 keys or other strong second factors.
Stored in different physical locations so one fire / theft doesn't destroy both.

For larger organisations, more — three to five break-glass accounts is common.

Excluding from Conditional Access

For every CA policy, the break-glass accounts should be in the excluded users / groups list. Easy to forget when creating new policies.

The standard pattern: create a security group Break-Glass Accounts containing the accounts. Every CA policy excludes this group. Adding a new break-glass account is one membership change rather than editing every policy.

Credential storage

Break-glass passwords need to be accessible in emergency but not accessible casually:

Physical safe in the IT director's office, written on paper.
Sealed envelopes with the credentials inside, opened only on documented emergency authorisation.
Two-person rule — opening requires two named people.
Backup copy in a separate location.

Most organisations document the procedure in a runbook stored separately from the credentials themselves.

MFA for break-glass accounts

A controversial design decision: should break-glass accounts require MFA?

Pro MFA — even break-glass should follow modern security practices.
Anti MFA — if the MFA mechanism itself is broken (Authenticator app service outage), MFA-enforced break-glass becomes the disaster you can't recover from.

Microsoft's recommendation has shifted over time. As of 2026, the typical pattern is FIDO2 hardware keys for break-glass — they're independent of Microsoft's online MFA service, work even when other auth methods fail, and provide strong second-factor protection.

Configure the FIDO2 keys, store them with the credentials, document the recovery procedure.

Monitoring

Break-glass sign-ins are abnormal by design. Every break-glass sign-in should trigger an alert:

Defender XDR alert on sign-in by break-glass account.
Email or Teams notification to the security team.
Documented incident response for unexplained break-glass use.

Configure these as part of the break-glass deployment. Without monitoring, a compromised break-glass account is a tenant-wide compromise.

Periodic rotation and testing

Rotate credentials at least annually — change passwords, replace FIDO2 keys.
Test sign-in quarterly — verify the procedure still works (documented test sign-in, not a real emergency).
Update documentation as the tenant evolves.

A break-glass that hasn't been tested in years probably doesn't work when needed.

Documentation

The break-glass runbook should include:

Account UPNs and where credentials are stored.
Authorisation procedure — who can decide to use them.
Sign-in procedure — exact steps, including dealing with edge cases.
Post-use procedure — credentials rotated, incident logged.
Recovery procedure — if break-glass itself is compromised.

For Microsoft 365 tenants with serious Conditional Access posture, well-designed break-glass accounts are insurance you hope never to use. The discipline of designing, deploying, and maintaining them is non-negotiable.