Two accounts, in two safes, tested every ninety days. Otherwise your tenant has a single point of failure with a person attached to it.
Microsoft guidance is specific: create two or more cloud-only emergency access accounts on the onmicrosoft.com domain, register a passkey or certificate-based authentication, exclude them from Conditional Access policies that block sign-in, alert on every use, and validate that they still work at least every ninety days.
- 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, and almost every tenant we look at fails at least two.
Cloud-only, on the onmicrosoft.com domain
Microsoft states these should be cloud-only accounts using the onmicrosoft.com domain, not federated and not synchronised from on-premises. That is not a preference. If federation is unavailable because an identity provider is down, an account that depends on it is unusable during precisely the outage it exists to survive.
A passkey or certificate-based authentication, and nothing weaker
The published choice is a passkey, which is recommended, or certificate-based authentication where a public key infrastructure already exists. Both satisfy the mandatory multifactor authentication requirements. The old pattern of a very long password with MFA excluded is no longer the guidance, and it has not been for some time.
A different method from your normal administrative accounts
Microsoft is explicit: use strong authentication that does not use the same authentication methods as your other administrative accounts, giving the example that if your normal admin account uses Authenticator, the emergency account should use a FIDO2 security key. Shared method equals shared failure, which defeats the point of the account entirely.
Excluded from Conditional Access policies that block sign-in
The published warning is direct: an emergency access account subject to a policy requiring MFA, a compliant device or another control might be unusable during the exact emergency scenarios it is designed for. Microsoft also notes report-only policies do not block access and do not require an exclusion, which is a useful distinction when auditing.
Credentials in fireproof safes, in separate locations
Stored in a known secure location available to multiple members of the administration team, not associated with any individual, and not connected to employee-supplied devices such as phones. Microsoft specifies secure, fireproof safes in secure, separate locations, and says to change safe combinations regularly and after anyone with access leaves.
An alert on every use, at critical severity
Microsoft documents the pattern: send Entra sign-in logs to Azure Monitor, take the object identifiers of the accounts, and create a log alert querying SigninLogs filtered by those identifiers with a static threshold greater than zero. The published severity to use is critical, wired to an action group that reaches administrators by email, SMS, push or voice.
Validated at least every ninety days, as a drill
Not a paperwork exercise. The published validation includes confirming the accounts can sign in and perform administrative tasks, that monitoring and alerting actually trigger, that the authorised user list is current, that the break-glass process is documented, and that nobody registered MFA or self-service password reset to an individual device or personal details.
Everyone is eligible, approval is required, and there is nobody left to approve.
Microsoft lists five scenarios where an organisation cannot administer its own tenant. The fifth is the one that catches mature organisations rather than careless ones.
- Quoted: all Global Administrator and Privileged Role Administrator role assignments are eligible rather than active, activation requires approval, and no approvers are selected, or all selected approvers were removed from the directory.
- Active Global Administrators and Privileged Role Administrators are the default approvers when none are selected. But because none are active, nobody can approve an activation, and Microsoft states that tenant administration is effectively locked.
- That is a deadlock produced by doing privileged access management well and then losing the people. It is not a configuration error anyone would spot in a review, and it is exactly why Microsoft says emergency access accounts should be permanent active in Privileged Identity Management rather than eligible.
- The other four scenarios are more familiar: an identity provider outage breaking federated sign-in, MFA devices or the MFA service being unavailable, the last Global Administrator leaving and their account being disabled on-premises, and a natural disaster taking out mobile networks.
Four things that separate a real break-glass account from a comforting one.
We sign in during the assessment, not just look at the configuration
The only meaningful test of a break-glass account is using it. Microsoft published validation includes confirming the account can sign in and perform administrative tasks, and confirming that the alerting fires. Reading the configuration tells you what should happen. Signing in tells you what does, and the two differ more often than people expect.
We audit the Conditional Access exclusions against every policy
Not just the policies that existed when the account was created. Policies accumulate, and a new one requiring a compliant device is precisely the sort of change that quietly removes your last route into the tenant. Microsoft also distinguishes report-only policies, which do not block and do not require an exclusion, and that distinction saves unnecessary exclusions.
We check the PIM assignment type, which people get wrong
Microsoft is explicit that the Global Administrator role assignment on an emergency access account should be permanent active rather than eligible. An eligible assignment requires activation, activation can require approval, and the published deadlock scenario is exactly what happens when no approver remains. Eligible break-glass is not break-glass.
We separate cloud break-glass from on-premises break-glass
Microsoft federation guidance says to keep emergency access for on-premises systems and for cloud services distinct, with no dependency of one on the other, because sourcing authentication for emergency accounts from other systems adds unnecessary risk during an outage. Organisations that run Active Directory Federation Services frequently have exactly that dependency.
Six UAE situations where the break-glass position gets tested.
A federated organisation whose identity provider goes down
Microsoft names this first: user accounts are federated and federation is unavailable because of a cell-network break or identity-provider outage, so users cannot sign in when Entra redirects to their identity provider. A cloud-only emergency account on the onmicrosoft.com domain is the only thing that still works, which is precisely why the requirement exists.
An organisation where administrators lost their MFA devices
The published scenario is administrators registered through Entra multifactor authentication whose individual devices are unavailable or where the service is unavailable, with the example of a cell network outage preventing phone calls and text messages, the only two methods they registered. That is a mundane failure with a total consequence.
A business where the last Global Administrator has left
Microsoft notes that Entra prevents the last Global Administrator account from being deleted, but does not prevent the account being deleted or disabled on-premises, and either situation might make the organisation unable to recover the account. In a group where a departure is processed by HR through the on-premises directory, this is not a hypothetical.
An operator hit by a natural disaster or major outage
Named directly in the published list: unforeseen circumstances such as a natural disaster emergency, during which mobile phone or other networks might be unavailable. This is also why the validation drill checks that any registered device can communicate through at least two network paths that do not share a common failure mode.
A regulated organisation that must evidence emergency procedures
Microsoft publishes guidance mapping emergency access accounts to HIPAA emergency access procedure requirements, and the same shape of requirement appears in many frameworks. Sign-in and audit log monitoring, a post-mortem review after every use, and validation drills at least every ninety days together produce the evidence an auditor wants.
A group that has just implemented Privileged Identity Management well
The most modern failure mode. All Global Administrator and Privileged Role Administrator assignments made eligible, activation requiring approval, and then the approvers leave the directory. Microsoft states tenant administration is effectively locked. A permanent active emergency account is the only thing that resolves it without opening a support case.
How UAE organisations 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 | What it prevents | |
|---|---|---|
| Maintain at least two emergency access accounts | A single credential, a single safe or a single registered device becoming the point of failure | |
| Cloud-only accounts on the onmicrosoft.com domain | The account being unusable during exactly the federation or sync outage it exists for | |
| Phishing-resistant methods, different from normal admin accounts | A shared method meaning a shared outage, and a shared compromise | |
| Credentials and devices do not expire or get auto-cleaned | An account that quietly stopped working months before anybody needed it | |
| Permanent active in PIM, not eligible | The activation deadlock where no approver remains to approve anything | |
| A designated secure workstation for use | The highest privilege in the tenant being exercised from a compromised laptop | |
| Credentials in separate secure fireproof locations | One fire, one flood or one person removing the only copy | |
| Excluded from blocking Conditional Access policies | The policy that protects the tenant also locking you out of fixing it | |
| Monitor all sign-in and audit activity with alerts | A break-glass account being used quietly by somebody who should not have it | |
| Validate functionality at least every 90 days | Discovering during a real outage that the credential no longer works |
Five steps, and it is a short engagement with a large consequence.
- 1
Assess what exists and try to use it
Finding existing emergency access accounts, checking whether they are cloud-only, what method is registered, whether they are excluded from every blocking Conditional Access policy, whether the PIM assignment is permanent active, and then actually signing in. That last step is the assessment, and it frequently ends the discussion about whether work is needed.
- 2
Create or remediate to the published requirements
Two or more cloud-only accounts on the onmicrosoft.com domain with the Global Administrator role, registered with a passkey or certificate-based authentication, using a different method from your normal administrative accounts, with credentials and devices that do not expire or fall into automated cleanup.
- 3
Fix the Conditional Access position
A dedicated security group, the published example being EmergencyAccess, excluded from every policy that blocks or restricts sign-in. Report-only policies are left alone, since they do not block and do not need exclusion. Contingency policies that can be enabled during an outage to restore access for critical users are designed at the same time.
- 4
Wire the monitoring and store the credentials
Entra sign-in logs to Azure Monitor, object identifiers captured, a log alert on SigninLogs filtered to those accounts with a static threshold above zero at critical severity, and an action group reaching administrators by more than one channel. Credentials then split across secure, fireproof, separate locations with a documented access list.
- 5
Run the first drill and schedule the next
Security monitoring told in advance, sign-in performed, an administrative task performed, the alert confirmed to have fired, and the post-mortem team walked through the review they would conduct. Then the ninety day cadence booked, plus triggers for staff changes and subscription changes.
What organisations 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 authorised 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
Where the eligible versus active distinction lives, and the deadlock this account resolves.
Conditional Access
The policies these accounts must be excluded from, and the contingency policies worth having.
Phishing-resistant MFA
The methods the current guidance recommends registering on these accounts.
Sign in to your break-glass account today. If you cannot, you did not have one.
That is the entire assessment, and it takes ten minutes. In most tenants we look at the account exists, the credential is somewhere, and nobody has verified it works since the day it was created.
Related Services
Explore more solutions that work great with this service
Tabletop Exercise
Test the decisions, not the documentation
Privileged Access Audit
Every privileged path, not just the admin list
Privileged Identity Management
Just-in-time admin access, approval, and audit history you can download
Entra Conditional Access
The control that decides who reaches your data
Phishing-Resistant MFA
The three methods that actually resist relay attacks
Entra ID Governance
Joiner mover leaver, access packages and guests that expire on their own
Active Directory Audit
Privilege paths, service accounts and local admin passwords
Disaster Recovery & BC
Business continuity and disaster recovery planning