A break-glass account, also called an emergency access account, is a highly privileged Microsoft 365 administrator account that stays sealed until your normal path to administrative access fails. Microsoft recommends that every tenant maintain at least two.
Most executives learn the term “break-glass account” during an incident review, which, to be clear, is the worst possible moment to learn it. Somebody asks whether anyone can still sign in as a Global Administrator. The answer comes back yes, obviously, and then the room discovers that “yes” depends on a multifactor prompt going to a phone belonging to a person currently sitting on a beach in Sorrento.
If you use Microsoft Entra ID/Microsoft 365 and have Conditional Access or other controls that could prevent normal administrators from signing in, then the answer is yes. You need a break-glass account, and in fact Microsoft recommends at least two. That’s two carefully controlled accounts, a documented procedure, monitoring, and a test schedule.
Why an Emergency Access Account Exists
Modern Microsoft 365 security works by narrowing the conditions under which anyone is allowed to log in. Conditional Access is where that narrowing happens. Sign in from a managed device. From an approved country. With a registered second factor. Every condition you add closes an avenue to an attacker, but every condition you add also closes an avenue to you. Stack enough of them and you have built a tenant capable of locking out its own administrators.
The usual cause has nothing to do with an attacker. It’s an administrator saving a Conditional Access policy at six o’clock on a Friday with a scope slightly wider than intended, and the “require compliant device” rule landing on the one group of people who could have rolled it back.
A Microsoft emergency access account is the deliberate exception to all of that. It’s an identity that survives the failure of the systems designed to govern access, held in reserve for the day those systems fail.
When a Break-Glass Account Actually Gets Used
The realistic triggers are boring, which is part of the point. A Conditional Access change locks out every administrator at once. Let’s say your MFA provider has an outage (and Microsoft’s own MFA service has had them). Federation to your on-premises directory breaks because a certificate expired on a server nobody has patched since the last CIO, and every synced identity in the tenant becomes unusable while a cloud-only account keeps working. Your sole Global Administrator resigns on a Tuesday and hands back a laptop with no handover notes. Or you’re in the middle of an incident, you believe your administrative credentials are in someone else’s hands, and you need one clean identity to revoke sessions and start resetting everything else.
Outside of those conditions, the account does nothing. That’s the whole design.
Why the Account is Protected Differently From Everything Else
The account should be cloud-only, created on your .onmicrosoft.com domain, never synchronized from on-premises Active Directory and never federated. If it depends on your directory sync, it will fail on the day your directory sync does. It should hold a permanent Global Administrator assignment rather than an eligible one through Privileged Identity Management, because activating a role through PIM assumes the identity plumbing you may be trying to repair is still working.
It should be excluded from the Conditional Access policies that could block it, which is the one place where “excluded from your security controls” is the correct answer. Older guidance stopped there and left the account with a password alone. Current Microsoft guidance recommends pairing the exclusion with a phishing-resistant authentication method, preferably a FIDO2 passkey or security key, rather than leaving the account protected only by a password.
Microsoft recommends maintaining at least two of these accounts, using different authentication methods, stored in different places, so that they don’t share the same failure point and a single misplaced safe or vendor outage doesn’t take out both. The credentials should be long, random, and stored securely, with access divided among authorized people according to your organization’s emergency-access procedures. The account should not depend on any individual employee’s phone, mailbox, device, or other personal credential. And the account needs to be excluded from automated password rotation and from the housekeeping scripts that disable stale accounts. That last exclusion catches more companies than any other. An account that never signs in can look exactly like an abandoned account to a tidy-up script.
One more thing: the emergency account shouldn’t be used from just any laptop. Microsoft recommends that people using emergency access accounts do so from a designated secure workstation or privileged access workstation. The point is simple: if you’re using the account because you suspect your normal administrative environment has been compromised, you don’t want the emergency credential passing through that same environment.
Who Should Know the Account Exists
Keep the list short. Every additional person who knows the credential exists is another person who can leak it, misuse it, or mention it in a meeting with the wrong contractor in the room.
Be honest about what secrecy is buying you, though. Any insider with directory read access can list your Global Administrators in about four seconds, so obscurity really only buys you delay. (And of course, naming the account something like breakglass01@ removes even that!) The stronger reason for a short list is accountability. When five people know, you can determine who opened the envelope. When forty do, the audit trail is practically hopeless.
There’s a failure mode on the other side too. Secrecy that outlives the people keeping it turns into its own outage, so the roles that hold the credential need to be documented somewhere that survives a resignation.
How to Monitor a Break-Glass Account
Every sign-in to the account should generate a high-severity alert that reaches a human being within minutes. In practice that means streaming Entra sign-in logs to a Log Analytics workspace and building an alert rule, or handling it through Microsoft Sentinel or your Defender alert policies. The alert should reach a phone. A message that sits unread in a shared inbox until Monday isn’t a control.
Alert on changes to the account as well as on use of it: password resets, changes to authentication methods, new role assignments, and additions to groups. An attacker who reaches this account will do those things before doing anything else.
If your managed provider tells you the account is “monitored,” ask them what happens at two in the morning on a Sunday, and ask who specifically is expected to answer.
Why Can’t It Become an Everyday Administrator Account?
This is where good implementations go to die, and it happens by degrees. An engineer uses the emergency administrator account once because their own PIM activation was taking too long during a Friday deployment. It works, and it’s easier, so they use it again during a migration weekend. Six months later the credential is saved in two browsers and a shared vault, half the IT team knows it by heart, and someone muted the sign-in alert because it fired every single day.
At that point you have converted your emergency exit into a hallway. The alerting is off, so a real intrusion arrives silently. The audit log records the account rather than the person, so when something alarming happens you can’t tell who did it. And you’re left with a permanently privileged identity, exempt from your Conditional Access policies, whose password is known to a dozen people. There is no better target in your tenant.
When and How to Test Break-Glass Accounts
Test quarterly at minimum, and additionally after any significant change to Conditional Access or your identity architecture, and whenever someone holding part of the credential leaves the company.
A real test confirms four things. The credential still works. The account still holds the role it’s supposed to hold. The alert fired. And a named human actually received that alert and knew what it meant. Most organizations that test discover the first two are fine. The third is where the surprises live.
Then reset the password, reseal it, log the test, and note the date. Test the physical process too, because the credential is worthless if the safe is in an office that’s locked on weekends and the person with the key is the person you’re trying to work around.