What this check looks at
Looks for cloud-only Global Administrator accounts excluded from Conditional Access, which is the standard break-glass pattern.
An emergency access (break-glass) account is a cloud-only account on the tenant’s onmicrosoft.com domain that holds Global Administrator permanently and is left out of every Conditional Access policy. It is never used for daily work. Its only job is to get someone back into the tenant when normal administrator sign-in fails: a Conditional Access policy that blocks everyone, an MFA or federation outage, or the other Global Administrators leaving or losing their phones. Microsoft 365 does not create one.
This check looks for Global Administrators that are user accounts, not synchronised from on-premises, and excluded by name from at least one Conditional Access policy, which is how emergency access accounts are recognised. It is not applicable when the tenant has no Conditional Access policies. The check fails when no such account exists and warns when only one does; Microsoft recommends two, kept separately.
Without them, one mistake in a Conditional Access policy (block all users, require a compliant device before any device is compliant, a location rule with the wrong IP range) can lock every administrator out at once. The way back is then a Microsoft support case to prove ownership of the tenant, during which nobody can fix the policy. Because Microsoft now enforces MFA on its admin portals, emergency accounts also need a method that does not depend on one person’s phone, such as a FIDO2 security key.
Why it matters
A Conditional Access misconfiguration, a federation outage or an expired MFA provider can lock every administrator out of the tenant at once. Break-glass accounts are the documented way back in; without them recovery means a support ticket and hours of downtime.
A realistic failure: an engineer creates a policy requiring a compliant device for all users and all resources and switches it straight to On, forgetting that their own laptop is not compliant. Every administrator is blocked, including the MSP’s. Without an excluded emergency account the organisation waits days on Microsoft support while staff on unmanaged devices cannot work; with one, the policy is corrected in five minutes.
The accounts must be watched as well as created: nobody should ever use them, so any sign-in by one is either a real emergency or a sign of compromise, and should alert the security contacts at once.
CIS Microsoft 365 Foundations Benchmark 1.1.2 asks for two emergency access accounts. ISO 27001 A.5.29 (information security during disruption) and A.8.2, the NCSC CAF resilience preparation outcome and the NCSC 10 Steps identity and access management guidance all expect a tested way to recover administrative access.
How to fix it
Where: Entra admin centre → Identity → Users
Before you start
- Use two cloud-only accounts on the tenant.onmicrosoft.com domain, with long random passwords or FIDO2 keys stored securely and separately.
- Exclude both from every Conditional Access policy, and set up an alert on any sign-in by them.
Step by step
- Create two cloud-only accounts. In the Microsoft 365 admin centre, go to Users > Active users > Add a user and create two accounts on the onmicrosoft.com domain, for example emergency1@contoso.onmicrosoft.com and emergency2@contoso.onmicrosoft.com. Assign no licence. Give each a random password of at least 20 characters from your password manager and untick the option to email it.
- Make both permanent Global Administrators. In the Microsoft Entra admin centre, Entra ID > Roles & admins > Roles & admins > Global Administrator > Add assignments, add both accounts. If PIM is in use, make the assignments Active and Permanent, not Eligible, so they still work if PIM itself is the problem.
- Register a security key on each account. Make sure Passkey (FIDO2) is enabled for these accounts under Entra ID > Authentication methods > Policies. Sign in to each account at https://aka.ms/mysecurityinfo (with a Temporary Access Pass if asked) and register a FIDO2 security key, ideally two keys per account, so the account can satisfy the MFA Microsoft enforces on its admin portals without anyone’s phone.
- Store the credentials separately and offline. Write each password down, seal it with that account’s security key, and keep the two accounts’ credentials in two separate secure places (for example the office safe and a director’s safe), not in a password vault that itself needs Microsoft 365 sign-in. Record who can open them.
- Exclude both accounts from every Conditional Access policy. In Entra ID > Conditional Access > Policies, open each policy, including report-only ones, and under Users > Exclude > Users and groups select both accounts by name. Excluding them through a group also works for Conditional Access, but this check only recognises emergency accounts excluded directly. Add the exclusion to your checklist for new policies.
- Alert on any sign-in by them. Send sign-in logs to a Log Analytics workspace (Entra ID > Monitoring & health > Diagnostic settings > Add diagnostic setting, tick SignInLogs) and create an Azure Monitor log alert rule on SigninLogs where UserPrincipalName is either emergency account, emailing and texting the security contacts. Where the tenant has Microsoft Defender for Cloud Apps, an activity policy on these accounts’ sign-ins does the same.
- Test the accounts and record the test. Sign in with each account once, in a private browser window, to the Microsoft Entra admin centre. Check the sign-in works with the security key, the alert fires, and the sign-in log’s Conditional Access tab shows no policy applied. Record the date and repeat every 90 days and after major Conditional Access changes. The finding clears at the next assessment.
What users will notice
None. The accounts are for emergencies only.
How to confirm it worked
Sign in with each account once to test it (then record the test), and confirm the sign-in alert fired.
Frameworks and controls
This check maps to controls in 11 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.
| Framework | Control |
|---|---|
| NCSC CAF | B5.a Resilience preparation |
| DSPT | Standard 7: Continuity planning |
| DORA | Art. 11 Response and recovery |
| NIS2 | Art. 21(2)(c) Business continuity and crisis management |
| Microsoft Cloud Security Benchmark | PA-5 Set up emergency access |
| Zero Trust | Identities |
| SOC 2 | CC6.1 Logical access security software, infrastructure and architectures |
| ISO 27001:2022 | A.5.29 Information security during disruptionA.8.2 Privileged access rights |
| CIS M365 | 1.1.2 Ensure two emergency access accounts have been defined |
| NIST CSF 2.0 | PR.IR-03: Mechanisms are implemented to achieve resilience requirements in normal and adverse situations |
| NCSC 10 Steps | Identity and access management |
The framework mappings were last checked against the published standards in October 2026.
Microsoft’s documentation
- Manage emergency access accounts (Microsoft Learn)