Emergency access accounts in Entra ID deserve more care than they get

I've stopped counting the tenants I've seen where emergency access accounts were an afterthought. One overly strict Conditional Access policy is enough to lock everyone out. With mandatory Azure MFA announced for all tenants (more on that here), being unprepared carries more risk than it used to. If you haven't thought your break-glass process through properly, you're betting your organization's ability to recover from a lockout on luck.

A solid emergency access account follows a few simple principles

Microsoft's guidance on emergency access ("break-glass") accounts is pretty clear (docs). Over the years I've settled on a handful of principles that hold up in real environments. I use two cloud-only accounts in the onmicrosoft.com default tenant domain, each with Global Administrator rights. Neither account is ever tied to a personal mailbox, an individual identity or a phone number. The passwords are long and random, and they live in two physically separated places, company safes for example, with proper documentation and a rotation after every test. Phishing-resistant MFA with FIDO2 security keys is non-negotiable. It shuts down most attack vectors, and you aren't left relying on a password-only setup that is fast becoming obsolete.

Password-only emergency accounts are a bad idea at this point, and mandatory Azure MFA will make them useless soon enough. Even if your tenant doesn't (yet) require phishing-resistant or passwordless MFA for all users, now is the time to switch. The effort is small, and you gain a lot in both resilience and security.

Break-glass accounts belong in Conditional Access exclusions only where necessary

A common mistake is to exclude emergency access accounts from far too many Conditional Access policies. Yes, they have to work when things go wrong. That still doesn't justify stripping away every security check. My rule is simple. I exclude them only from policies that could block admin portal access or require MFA in a way that might lock you out, and every other protection stays in place. Requirements for phishing-resistant MFA in particular should never be relaxed. Microsoft's recommended Conditional Access policy for all users makes a good baseline (see here).

Review these exclusions on a regular basis. Whenever you create a new policy, handle the break-glass accounts explicitly. No amount of documentation helps if you discover during a crisis that a new policy blocks your only way in.

Sentinel and Log Analytics watch every break-glass sign-in

The technical setup is only half the job, because monitoring matters just as much. You want to know right away when one of these accounts is used. I usually create an Azure Sentinel alert rule on the Entra ID SigninLogs, which come in through the Log Analytics integration. The KQL snippet below filters all successful sign-ins for your break-glass accounts and works well as the basis for an alert:

SigninLogs
| where UserPrincipalName in ("[email protected]", "[email protected]")
| where ResultType == 0

Pro tip: Set up email and, if you like, Teams alerts for every emergency account sign-in, failed ones included, and review those events at least quarterly. Document your regular access tests. That's the only way to know nothing will fail when you actually need these accounts.

The lifecycle and the human factor decide whether the setup holds

An emergency account is not something you set up once and forget. I keep running into tenants where credentials were never rotated or the FIDO2 keys have disappeared. Without a clearly documented process, you may find out in the middle of a crisis that nobody knows how to get the backup key or where the passwords are kept. Access rights need regular review as well, and these accounts should never be used for day-to-day admin work.

What you need is a dependable routine with clear steps for creating the accounts, storing passwords and keys, testing, and running periodic reviews. Keep the documentation secure but accessible to the right people, and make sure everyone knows who is responsible for what. If you cut corners here, the technical setup was wasted effort.

A real emergency follows a predictable sequence

To make the process more concrete, here's a simple flowchart showing how emergency access, phishing-resistant MFA and monitoring work together:

flowchart TD
A["Emergency: No access"] --> B["Sign in with break-glass account"]
B --> C["Phishing-resistant MFA (FIDO2)"]
C --> D["Sign-in monitored (Sentinel)"]
D --> E["Alert & documentation"]
E --> F["Fix tenant issue"]

Figure: Emergency sign-in with a break-glass account, MFA and monitoring.

Emergency access leaves no room for improvisation

I think of emergency access accounts as the fire extinguisher for your tenant. You hope you never need them, and when you do, they have to work perfectly. In 2024 the requirements are stricter and clearer than they have ever been. Following best practices closes the big gaps and saves you from losing precious minutes to improvised troubleshooting during a real incident. The biggest risk isn't the technology. It's neglect, meaning skipped tests, secrets that never get rotated and documentation nobody keeps current. Give the topic the attention it needs and you'll sleep better, with more time for the more interesting work ahead.