Microsoft 365, Entra and Intune
Break glass account Entra setup: the fire extinguisher you never test
The password is in a Teams message from 2023. The message is in a chat with somebody who has left. Nobody has signed into the account since it was created, so nobody knows whether it still works, and the one circumstance in which anybody will find out is the circumstance where nothing else does.
A break glass account entra tenants need is not complicated to create. What makes it useful is the four things around it that nobody does: the exclusions, the storage, the monitoring, and the test.
Why a break glass account entra setup matters more when you are alone
In a tenant with six administrators, a Conditional Access policy that locks everybody out is embarrassing. Somebody else fixes it.
In a tenant with one, it is an outage with no internal resolution path. Your options are a Microsoft support case, which means proving you are who you say you are while unable to log in, or waiting. Both take hours, during which nobody in the company can access email.
That asymmetry is the entire argument. The break-glass account is not protection against an attacker. It is protection against yourself, on an afternoon when you were confident about a policy change.
What the accounts look like
Two of them. One is a single point of failure, and the failure mode you are guarding against includes "this specific account has a problem".
Cloud-only. No synchronisation from on-premises Active Directory, because a break-glass account that depends on a sync running is not a break-glass account. No dependency on anything that could be part of the failure.
Named so their purpose is obvious. Something like
emergency-access-01@yourdomain.com. Not a name that looks like a person,
because in six months somebody reviewing accounts needs to not delete it, and
"who is emergency.access" is a conversation that ends badly.
No licences. They need no mailbox and no Teams. A licence is an attack surface and a cost with no purpose here.
Permanently assigned Global Administrator. This is the one place where standing privilege is correct, and it is worth being explicit about because it contradicts everything in the PIM note. An eligible role you have to activate is no use if the thing that is broken is the mechanism that activates it.
Excluded from everything
Every Conditional Access policy excludes these accounts. Not most. Every one, including the ones you add later, which is why the exclusion should be a group rather than two named accounts.
Microsoft's emergency access account guidance sets this out, and the reasoning is worth internalising rather than just following: the account has to work when the policy engine is the thing that is wrong. A break-glass account subject to a policy is protected by the system it exists to rescue you from.
That does mean these accounts are not protected by MFA policy. The protection comes from somewhere else, and it has to be real.
Where the password lives
Not in Teams. Not in email. Not in the password manager you sign into with the account that is currently locked out, which is the circular dependency people build without noticing.
The options that work, roughly in order of practicality for a small company:
Split the credential between two people. Half each, sealed, written down. Two people have to be present to use it, which is also an access control. This sounds antiquated and it works, because paper does not have a dependency on your identity provider.
A physical safe, with the sealed envelope and a log of when it was opened.
A separate password manager, on a different identity provider entirely, with its own MFA on a device that is not the one you are trying to recover.
The test for any of these: if Entra ID is completely unavailable, can you still get the password. If the answer involves signing into anything in the tenant, start again.
Store the recovery method for the second factor alongside it. A password you can retrieve and a hardware key you cannot find is not a working credential.
Monitoring for any use
These accounts should never sign in. So any sign-in is either an emergency or an incident, and both want you to know within minutes.
That is one of the easiest high-value detections to write, because the baseline is zero:
SigninLogs
| where TimeGenerated > ago(1h)
| where UserPrincipalName has "emergency-access"
| project TimeGenerated, UserPrincipalName, IPAddress, Location,
AppDisplayName, ResultType, ResultDescription
| order by TimeGenerated desc
Set it to alert at High severity with no threshold. There is no acceptable number of sign-ins per day, so there is no rate to tune, which makes this one of the few rules that will never need adjusting. Validate that it can run, for the reasons in the detection validation note, because a rule watching your last resort is a poor choice of rule to leave untested.
If you do not run Sentinel, an Entra sign-in alert or a scheduled Graph query emailing you is adequate. The mechanism matters less than the fact that something is watching.
Testing, which is the part everyone skips
A fire extinguisher nobody has checked is a red cylinder.
Quarterly, sign in with one of them. Confirm the credential works, confirm the alert fires, confirm the account still holds Global Administrator, and write down the date. Fifteen minutes.
The two failures this catches are both common. The credential has drifted, because somebody rotated it and updated one copy. And the alert never worked, usually because the rule was written against a table that is not being ingested, which you would otherwise discover during the outage.
Rotate the credentials annually and when anybody who had access to them leaves. The record of those tests is also the evidence an auditor will ask for, because this sits under access control and business continuity at once, and the book covers what that evidence needs to look like.
The thing to do this week
If you take one action from this: check whether your break-glass account is excluded from your Conditional Access policies, and check whether you can actually retrieve its password right now, without signing into anything.
Most people discover one of those two answers is no, and it takes twenty minutes to fix on a quiet afternoon rather than during the incident where it matters.