Two accounts, held in two separate safes, tested every ninety days. Without that, your tenant has a single point of failure and a named human standing at it.
The guidance leaves little to interpretation. Build two or more cloud-only emergency access accounts on the onmicrosoft.com domain. Register a passkey against them, or certificate-based authentication. Keep them outside any Conditional Access policy capable of blocking sign-in. Alert whenever one is used. And prove at least every ninety days that they still work.
- Two or moreThe published minimum, for redundancy
- Cloud-onlyNo federation, no directory sync
- Every 90 daysMinimum validation interval
- Alert on useSeverity critical, every single sign-in
Seven requirements. Nearly every tenant we examine misses at least two of them.
Cloud-only, on the onmicrosoft.com domain
These have to be cloud-only accounts on the onmicrosoft.com domain, neither federated nor synchronized from anything on-premises. That is a requirement rather than a suggestion. Should federation be unavailable because an identity provider has gone down, an account depending on it becomes useless during exactly the outage it was created to survive.
A passkey or certificate-based authentication, and nothing weaker
You have two documented options: a passkey, which carries the recommendation, or certificate-based authentication where you already run a public key infrastructure. Either satisfies the mandatory multifactor requirements. If you remember the old pattern of an extremely long password with MFA deliberately excluded, that guidance changed a considerable while ago.
A different method from your normal administrative accounts
The instruction is explicit. Use strong authentication, and use a different method from the one your other administrative accounts rely on. The example given is that where your normal admin account uses Authenticator, the emergency account should use a FIDO2 security key. Share the method and you share the failure, which removes the entire reason the account exists.
Excluded from Conditional Access policies that block sign-in
The warning is blunt. An emergency access account left inside a policy that demands MFA, a compliant device or some other control may well be unusable in precisely the emergency it was built for. One useful nuance when auditing: report-only policies do not block access, so they need no exclusion.
Credentials in fireproof safes, in separate locations
Credentials go somewhere secure that several members of the administration team can reach, tied to no individual person, and never bound to employee-owned equipment such as a personal phone. The guidance calls for fireproof safes in secure, physically separate locations, with the combinations changed on a regular basis and again whenever somebody with access leaves the business.
An alert on every use, at critical severity
The pattern is documented end to end. Route Entra sign-in logs into Azure Monitor, take the object identifiers of the two accounts, then build a log alert querying SigninLogs filtered on those identifiers with a static threshold above zero. Set the severity to critical and wire it to an action group that reaches your administrators by email, text, push notification or a phone call.
Validated at least every ninety days, as a drill
This is not a form-filling exercise. The documented validation asks you to confirm the accounts can genuinely sign in and carry out administrative work, that the monitoring and alerting actually fire, that the list of authorized users is still accurate, that the break-glass process exists in writing, and that nobody has quietly registered MFA or self-service password reset against a personal device or personal details.
Everybody is eligible, every activation needs approving, and there is nobody left who can approve it.
Five scenarios are listed in which a business finds itself unable to administer its own tenant. It is the fifth that catches out well run organizations rather than careless ones.
- The wording runs like this: every Global Administrator and Privileged Role Administrator assignment is eligible rather than active, activation requires an approval, and either no approvers were ever selected or all of the selected approvers have since been removed from the directory.
- When no approvers are chosen, the default approvers become the active Global Administrators and Privileged Role Administrators. But in this scenario none of them are active, so nobody exists who can approve an activation, and administration of the tenant is effectively locked.
- What you have there is a deadlock created by doing privileged access management properly and then losing the people who made it work. No review would flag it as a misconfiguration, because it is not one. It is also the precise reason the guidance says emergency access accounts must be permanent active in Privileged Identity Management rather than eligible.
- The remaining four are more familiar territory. An identity provider outage that breaks federated sign-in. MFA devices or the MFA service itself being unavailable. The last Global Administrator leaving and their account being disabled on-premises. And a natural disaster that takes the mobile networks down with it.
Four things that separate a genuine break-glass account from one that merely feels reassuring.
During the assessment we sign in rather than reading the configuration and moving on
There is exactly one meaningful test of a break-glass account, which is using it. The published validation asks you to confirm the account can sign in, can carry out administrative work, and that the alerting genuinely fires. Reading a configuration screen tells you what ought to happen. Signing in tells you what does happen, and those two answers diverge far more often than anybody expects.
We audit the Conditional Access exclusions against every policy
Not merely the policies that were in place the day the account was created. Policies pile up over time, and a new one requiring a compliant device is exactly the sort of change that silently closes your last way into the tenant. Report-only policies are treated separately, since they neither block nor need an exclusion, and knowing that saves you from writing exclusions nobody needed.
The PIM assignment type gets checked, because it is routinely set wrong
The guidance is unambiguous that a Global Administrator assignment on an emergency access account must be permanent active, never eligible. An eligible assignment has to be activated, activation can demand an approval, and the documented deadlock is precisely what occurs when no approver is left standing. An eligible break-glass account is not a break-glass account.
Cloud break-glass and on-premises break-glass are kept apart from each other
The federation guidance asks you to hold emergency access for on-premises systems entirely separate from emergency access for cloud services, with neither depending on the other, on the grounds that sourcing authentication for an emergency account from another system adds risk at exactly the wrong moment. Businesses running Active Directory Federation Services very often have precisely that dependency without realizing it.
Six US situations where the break-glass position gets tested.
A federated organization whose identity provider goes down
This one heads the published list. User accounts are federated, federation becomes unavailable through a cell network failure or an identity provider outage, and so nobody can sign in once Entra redirects them to that provider. The only credential still functioning is a cloud-only emergency account on the onmicrosoft.com domain, which is exactly why that requirement is written the way it is.
An organization where administrators lost their MFA devices
The documented case involves administrators registered through Entra multifactor authentication whose personal devices are unavailable, or where the MFA service itself is down. The example given is a cell network outage stopping both phone calls and text messages, which happened to be the only two methods those administrators ever registered. An entirely mundane failure with a total consequence.
A business where the last Global Administrator has left
Entra will stop you deleting the last Global Administrator account, but it has no say over that account being deleted or disabled on-premises, and either outcome can leave the business unable to recover it. Anywhere a departure gets processed by HR through the on-premises directory, this stops being hypothetical rather quickly.
A business caught by a natural disaster or a large-scale outage
This appears in the published list as unforeseen circumstances such as a natural disaster, during which mobile networks or other networks may simply not be available. For a great many American businesses that is not abstract: hurricane season along the Gulf Coast and wildfire season across the West make it concrete every year. It is also the reason our validation drill checks that any registered device can reach the outside world through at least two network paths that do not share a failure mode.
A regulated organization that must evidence emergency procedures
There is published guidance mapping emergency access accounts onto the HIPAA emergency access procedure requirements, which makes this directly relevant to covered entities and business associates alike. A requirement of much the same shape turns up in the SOC 2 availability criteria and in insurance questionnaires. Three things together produce the evidence an auditor is looking for: monitoring of sign-in and audit logs, a post-mortem review after every single use, and validation drills at intervals no longer than ninety days.
A company that has just implemented Privileged Identity Management well
This is the newest way to lose your tenant. Every Global Administrator and Privileged Role Administrator assignment is made eligible, activation is set to require approval, and then the approvers leave the directory. At that point administration is effectively locked. Nothing resolves it short of a support case, unless you hold a permanent active emergency account.
How US organizations handle break-glass access.
| Feature | Configured to guidance | An account exists somewhere | No break-glass account |
|---|---|---|---|
At least two accounts | Yes | Usually one | None |
Cloud-only and unfederated | Yes | Sometimes | Not applicable |
Phishing-resistant authentication | Yes | Rarely | Not applicable |
Different method from normal admin accounts | Yes | No | Not applicable |
Excluded from blocking policies | Yes | Unverified | Not applicable |
Permanent active in PIM | Yes | Unknown | Not applicable |
Credentials split across secure locations | Yes | One envelope | None |
Alert on every use | Yes | No | No |
Validated on a schedule | Every 90 days | Never | Not applicable |
Position during a real outage | Recoverable | Unknown | Locked out |
Ten published requirements, and why each one exists.
Requirement
Maintain at least two emergency access accounts
- What it prevents
- One credential, one safe or one registered device turning into the thing that fails
Requirement
Cloud-only accounts on the onmicrosoft.com domain
- What it prevents
- The account being useless during the very federation or sync outage it was built for
Requirement
Phishing-resistant methods, different from normal admin accounts
- What it prevents
- One shared method producing one shared outage, and one shared compromise
Requirement
Credentials and devices that quietly expire or get tidied away by automation
- What it prevents
- An account that stopped working months earlier without anybody being aware
Requirement
Permanent active in PIM, not eligible
- What it prevents
- The deadlock where an activation needs approving and no approver is left
Requirement
A designated secure workstation for use
- What it prevents
- Your highest privilege being used from a laptop somebody else controls
Requirement
Credentials in separate secure fireproof locations
- What it prevents
- A single fire, a single flood, or one person walking off with the only copy
Requirement
Excluded from blocking Conditional Access policies
- What it prevents
- The very policy protecting the tenant preventing you from repairing it
Requirement
Monitor all sign-in and audit activity with alerts
- What it prevents
- Somebody who should not have the account using it without anyone noticing
Requirement
Validate functionality at least every 90 days
- What it prevents
- Finding out mid-outage that the credential stopped working some time ago
Five steps. A short engagement, with consequences out of all proportion to its length.
- 1
Assess what exists and try to use it
We locate whatever emergency access accounts already exist, establish whether they are genuinely cloud-only, see what authentication method is registered against them, confirm they sit outside every Conditional Access policy capable of blocking sign-in, check the PIM assignment is permanent active, and then sign in. That final step is the assessment. It usually settles any remaining debate about whether work is needed.
- 2
Create or remediate to the published requirements
At least two cloud-only accounts on the onmicrosoft.com domain holding the Global Administrator role, each registered with a passkey or with certificate-based authentication, and deliberately using a different method from the one your normal administrative accounts rely on. Their credentials and devices are configured so that nothing expires and nothing gets swept up by automated cleanup.
- 3
Fix the Conditional Access position
The accounts go into a dedicated security group, with EmergencyAccess given as the published example, and that group is excluded from every policy able to block or restrict sign-in. Report-only policies stay untouched, since they block nothing and require no exclusion. At the same time we design the contingency policies you can switch on during an outage to restore access for the users who genuinely need it.
- 4
Wire the monitoring and store the credentials
Sign-in logs get routed into Azure Monitor, the object identifiers are captured, and a log alert runs against SigninLogs filtered to those accounts with a static threshold above zero at critical severity. Behind it sits an action group that reaches administrators through more than one channel. Credentials are then divided across fireproof safes in separate locations, with a written list of who can open them.
- 5
Run the first drill and schedule the next
Security monitoring is warned beforehand, somebody signs in, somebody performs a real administrative task, the alert is confirmed to have fired, and the post-mortem team walks through the review they would run for real. After that the ninety day cadence goes into the calendar, along with triggers for staff changes and for changes to your subscriptions.
What US organizations ask about emergency access accounts.
Fifteen checks to run every ninety days.
Does it still work
- Can each account sign in?Actually sign in, not check the account exists.
- Can it perform an administrative task?Sign-in alone is not the test.
- Did the alert fire?The drill also tests the monitoring.
- Was security monitoring told first?Microsoft says to make them aware.
- Does the current Conditional Access config still permit it?Test quarterly, per guidance.
Is it still configured correctly
- Still cloud-only and unfederated?Directory changes can alter this.
- Still permanent active in PIM?Not eligible, per the guidance.
- Has the credential expired or been cleaned up?It must not be in scope of auto-cleanup.
- Any MFA or SSPR registered to a personal device?Explicitly checked in the published steps.
- Can any registered device reach two independent networks?No shared failure mode.
Do the people and process still work
- Is the authorized user list current?Reviewed at every validation.
- Is the break-glass process documented and current?And findable during an outage.
- Are the relevant people trained on it?Administrators and security officers.
- Have safe combinations been changed?Regularly, and after anyone leaves.
- Is the post-mortem team defined?Before it is needed, not after.
The pages around this one.
Privileged Identity Management
The home of the eligible versus active distinction, and of the deadlock this account exists to break.
Conditional Access
Which policies these accounts have to sit outside, and which contingency policies are worth preparing.
Phishing-resistant MFA
The authentication methods current guidance says to register against these accounts.
Try signing in to your break-glass account this afternoon. If it fails, you never had one.
That is the whole assessment and it takes about ten minutes. In most tenants we examine, the account is present, the credential is somewhere in the building, and nobody has confirmed it works since the day somebody created it.
Related Services
Explore more solutions that work great with this service
Privileged Access Audit
Privileged access audits for US organizations: enumeration of every
Learn moreMicrosoft Entra Privileged Identity Management
Privileged Identity Management deployment for US organizations:
Learn moreMicrosoft Entra Conditional Access Design
Conditional Access design and review for US organizations:
Learn morePhishing-Resistant MFA
Phishing-resistant multifactor authentication for US organizations:
Learn moreMicrosoft Entra ID Governance
Entra ID Governance implementation for US organizations: automating
Learn moreMicrosoft Entra
Identity and access management solutions
Learn more