Every guide to Conditional Access, MFA and identity hardening opens with the same instruction: set up break-glass accounts first. Then it moves on, as if the accounts themselves were the easy part. They are not. A break-glass account done carelessly is worse than none at all, because it gives you the comfort of a safety net while quietly being a hole in the floor. This is the unglamorous detail of getting them right.
A break-glass account, sometimes called an emergency access account, exists for one moment: the day everything else locks you out. A Conditional Access policy goes wrong and nobody can sign in. Your federated identity provider falls over and takes SSO with it. MFA infrastructure has an outage and every normal login is stuck at the second factor. In each case you need a way back into the tenant that doesn’t depend on the thing that broke. That is the entire job. The account earns its existence maybe once in its life, and on that day it is the most important account you own.
Why the obvious version is wrong
The instinct is to make an admin account, give it a strong password, and call it your break-glass. That misses the point in a few ways at once, and each one is a way the account fails you at exactly the wrong moment.
If it depends on MFA and your MFA is what’s broken, it’s useless the day you need it. If it’s tied to a named person, it’s unusable when that person has left or is unreachable at 3am. If it’s subject to the same Conditional Access policies as everyone else, the policy that locked out the tenant locks it out too, which defeats the whole purpose. And if it’s an everyday admin account you also use for real work, it accumulates the same risk exposure as any other account while being held to less scrutiny.
Getting break-glass right is really about deliberately breaking each of those dependencies.
What does a proper break-glass account look like?
Cloud only. The account should be created directly in Entra ID, not synced from on-premises Active Directory. If it came from on-prem and your sync or your domain controllers are what failed, the account fails with them. Cloud-native means it survives an on-prem outage, and stays clear of the identity seam in a hybrid setup.
Not tied to a person. It belongs to the organisation, not to Alan or to whoever holds the admin role this quarter. No personal email in its recovery, nothing that walks out the door when someone resigns. Two accounts, not one, so a problem with either still leaves you a way in.
Excluded from Conditional Access. Every policy you create should carve these accounts out. This is the part people forget, and it is the part that matters most, because the entire scenario you are guarding against is a Conditional Access policy gone wrong. An account still subject to that policy goes down with the ship.
A very long passphrase, stored offline. Because the account has to work when your normal MFA might not, its password is doing more of the security work than usual, so it should be long, random, and genuinely secret. Split it if you like, half known to one trusted person and half to another, so no single individual can use it alone. Store it somewhere physical and secure, a sealed envelope in a safe is not old-fashioned here, it’s appropriate. It must be retrievable in a crisis without depending on the systems that might be down.
Global Administrator, and nothing less. This is the one account where you do want the top role, because the emergencies it exists for often require fixing tenant-wide configuration. It’s the deliberate exception to least privilege, justified precisely because it’s otherwise so tightly controlled and so heavily watched. Every other admin role belongs behind just-in-time activation (coming soon).
The exclusion from MFA is where people get nervous
There’s an obvious tension. You exclude the account from Conditional Access and you’re cautious about MFA dependencies, but an unprotected Global Admin account is exactly what every attacker dreams of. Both things are true, and the resolution is to compensate with a different control rather than protect the account the normal way: watch it like nothing else in your tenant.
Microsoft has settled part of that tension. Since mandatory MFA arrived for the Azure, Entra, Intune and Microsoft 365 admin portals, emergency accounts must complete MFA too, and there’s no exclusion. So give each one a FIDO2 security key, or certificate-based authentication, that no other admin account uses. Store the key physically with the credentials. It survives the outages you’re guarding against, it satisfies the enforcement, and it still keeps the account out of your Conditional Access policies. The principle holds: the account’s protection must not depend on the systems it exists to rescue you from.
Watching them is the actual security control
An account that bypasses your policies is only safe if any use of it is impossible to miss. So the compensating control for all that deliberate exposure is alerting. Every single sign-in to a break-glass account should raise an immediate, loud, high-priority alert to whoever runs security, because in normal operation these accounts are never used. A break-glass sign-in is, by definition, either a real emergency or an intruder, and both demand that someone looks right now.
This is straightforward to build. In Sentinel, an analytics rule watching SigninLogs for those specific account names, set to fire on any successful sign-in, gets you there. Because the expected rate of use is zero, you don’t need a clever threshold. One sign-in is the signal.
SigninLogs
| where UserPrincipalName in ("breakglass1@yourtenant.onmicrosoft.com",
"breakglass2@yourtenant.onmicrosoft.com")
| where ResultType == "0"
| project TimeGenerated, UserPrincipalName, IPAddress,
Location = tostring(LocationDetails.city), AppDisplayName
Wire that to notify immediately, not to batch into a daily digest. The whole value is in the speed of the response.
Test them, or you don’t really have them
Here is the part almost everyone skips. An emergency access account you have never signed into is a theory, not a control. You do not want the first time you use it to be during the actual crisis, discovering then that the password in the safe is wrong, or the account expired, or the alert never fired. Test them on a schedule, quarterly is reasonable. Retrieve the credentials the proper way, sign in, confirm the account works and has its access, confirm your alert fired, then reset the password and put it back. That drill turns a hopeful arrangement into one you can actually rely on.
None of this is difficult. It’s a handful of accounts and an afternoon of care. But it’s the kind of care that’s easy to defer forever because the payoff is invisible right up until the one day it’s the only thing that saves you. When an identity lockout does come, the organisations that get through it calmly are the ones that set these up properly and then checked that they worked. Clever tooling has very little to do with it.
I write about security, Azure, data, and the practical side of running things. If this was useful, connect with me on LinkedIn.
Originally published at alanconlon.com, where I post practical security, Azure and data write-ups every other Tuesday.
