Break-Glass Accounts in Microsoft 365

Break-glass accounts exist for the day your normal admin path fails. That could be a Conditional Access mistake, a federation issue, a strong-auth outage, or a role-activation problem at exactly the wrong moment.

What they are not is a licence to keep spare high-privilege accounts lying around "just in case". The worst emergency accounts are the ones people quietly use for daily work because they are easier.

A good emergency access design is deliberate. A bad one is just a hidden backdoor with a polite label.

Design rules

Microsoft recommends two or more emergency access accounts, and that baseline still makes sense.

The practical rules are:

1. Keep at least two accounts.
2. Make them cloud-only.
3. Assign only the privilege needed for emergency recovery, which in practice is commonly Global Administrator.
4. Exclude them only from the policies that could prevent recovery.
5. Protect them with strong credentials and a strong sign-in method that is separate from normal admin dependencies.
6. Monitor every sign-in and every credential change.
7. Test them on a schedule.
8. Keep them out of day-to-day admin use.

Why two accounts

One account can fail for a boring reason. A stored credential can be inaccessible. A token method can be unavailable. An account can be accidentally changed. Two accounts give you resilience without turning emergency access into a crowd.

Account	Purpose	Monitoring
BreakGlass-01	Primary emergency access	Alert on any sign-in
BreakGlass-02	Secondary emergency access	Alert on any sign-in

What to avoid

Avoid these common mistakes:

• using the accounts for daily admin jobs
• excluding them from more policies than necessary
• protecting them with the exact same dependency chain that could fail normal admin access
• storing credentials casually
• letting vendors or general support staff treat them as spare admin accounts

The dependency point is important. Microsoft specifically calls out using strong authentication methods that differ from your normal administrator accounts where practical. If all of your admin access relies on one method and that method becomes the problem, you need a different way back in.

Monitoring is part of the design

Emergency accounts should be noisy.

If one is used, somebody should know fast. The same goes for password resets, authentication method changes, and role changes. Silence is the wrong default here.

The evidence pack does not need to be fancy, but it should exist:

Evidence	Why
Account list	Shows how many emergency accounts exist
Role assignment	Shows privilege scope
Conditional Access exclusions	Shows why exclusions exist
Alerting record	Shows sign-ins are monitored
Test log	Proves the accounts actually work

Test without normalising casual use

This is the awkward balance. You need to test the accounts so they are not theoretical, but you do not want testing to become an excuse for routine use.

Quarterly or otherwise scheduled validation is usually enough for smaller teams:

• confirm sign-in still works
• confirm alerting still fires
• confirm exclusions are still correct
• confirm stored credential access is still controlled

Done properly, break-glass accounts reduce operational risk. Done lazily, they create a second, quieter problem that sits unnoticed until someone misuses it.

The standard worth aiming for

You want emergency access to be boring, documented, and slightly inconvenient. That is healthy.

If the account is easy, familiar, and commonly used, it is no longer an emergency control. It is just shadow admin access.

References

• Manage emergency access accounts in Microsoft Entra ID
• Conditional Access: Users, groups, and workload identities
• Microsoft Entra sign-in logs