Keep two protected emergency access accounts

Description

The tenant has exactly two emergency access ("break-glass") accounts, listed in {{ emergency_access_accounts }}. Each account:

• is cloud-only, with a user principal name on the *.onmicrosoft.com domain, and is not tied to a person;
• holds the Global Administrator role as a permanent active assignment, directly (not through a group and not as eligible in Privileged Identity Management);
• authenticates with a phishing-resistant method (FIDO2 security key or certificate) that is independent of the administrators' usual methods and devices;
• is excluded from every Conditional Access policy, except at most one policy that only requires phishing-resistant MFA for these accounts;
• has its credentials (security keys, password if any) stored in sealed form in a safe, in two separate locations, under a documented custody procedure;
• is tested at least every 90 days and its sign-ins raise an alert (CB-M365-AUDIT-009).

Other controls of this standard (Conditional Access, PIM, Global Administrator count) refer to these accounts by the parameter. A FIDO2 key per account, kept in a safe, is the simplest method that meets the admin portal MFA requirement.

Rationale

Conditional Access policies, MFA services, federation and Privileged Identity Management can all fail or be misconfigured, and the result is that no administrator can sign in. Two independent accounts that do not depend on these mechanisms are the only way to recover the tenant. Since Microsoft enforces MFA on admin portals, emergency accounts need a phishing-resistant method that works without the usual devices. Two accounts avoid a single point of failure.

Impact

The accounts are permanent Global Administrators, so their credentials must be guarded like the most sensitive secret of the organization. Every Conditional Access policy must exclude them, which adds a step to each new policy. Physical custody and regular tests cost some operational time.

Parameters

The value used is your override (tailoring file), else the profile's, else the one of the profile it extends, else the default. Bounds limit what an override may set.

Audit

1. Sign in to the Microsoft Entra admin center (https://entra.microsoft.com) as at least a Global Reader (Security Reader for Conditional Access).
2. Browse to Entra ID > Roles & admins > Global Administrator > Assignments: both accounts of {{ emergency_access_accounts }} appear as Active, with no end date, assigned directly.
3. Open each account: On-premises sync enabled is No, the user principal name ends with .onmicrosoft.com, and Authentication methods shows a FIDO2 security key or a certificate.
4. Browse to Entra ID > Conditional Access > Policies and open each policy: both accounts (or their group) are in Users > Exclude, except a single policy that only requires phishing-resistant MFA for them.
5. Check the custody register: storage of the credentials and date of the last test (90 days or less).
6. Read-only PowerShell alternative (Microsoft Graph, scope Policy.Read.All):

   Get-MgIdentityConditionalAccessPolicy -All |
     Select-Object DisplayName, State, @{n='ExcludedUsers';e={$_.Conditions.Users.ExcludeUsers -join ','}}
   

7. Fail if there are fewer or more than two accounts, if one is synchronized, eligible only, without a phishing-resistant method, included in a policy that could block it, or not tested in the last 90 days.

Remediation

1. With a Global Administrator, create two users in Entra ID > Users > New user, on the *.onmicrosoft.com domain, with neutral names and no license.
2. Assign each one the Global Administrator role as Active, Permanent, in Roles & admins (with PIM: Assignment type Active, Permanently assigned).
3. Register a FIDO2 security key (or a certificate) on each account; keep the keys and any password in sealed envelopes in two separate safes.
4. Add both accounts to a dedicated group and exclude that group from every Conditional Access policy. Set the parameter to their user principal names.
5. Create the sign-in alert (CB-M365-AUDIT-009) and schedule a test sign-in every 90 days.

Rollback

Not applicable: removing the emergency accounts removes the recovery path.

References

• Manage emergency access admin accounts in Microsoft Entra ID Microsoft, vendor-doc, accessed 2026-10-24
• Protect your Microsoft 365 global administrator accounts Microsoft, vendor-doc, accessed 2026-10-24
• ASD's Blueprint for Secure Cloud, break glass accounts Australian Signals Directorate, guide, accessed 2026-10-24

Mappings

How this control relates to the other framework's: equivalent, stricter, looser, partial or related.

Related controls

• related CB-M365-ADMIN-003 Keep between two and four Global Administrators
• related CB-M365-ADMIN-006 Grant highly privileged roles just in time through Privileged Identity Management
• related CB-M365-AUTH-034 Keep Conditional Access policies free of broken references and unprotected exclusions
• related CB-M365-AUTH-030 Block or force secure remediation for users at high risk
• related CB-M365-AUTH-031 Require MFA for risky sign-ins and block sign-ins at the highest risk levels
• related CB-M365-AUTH-033 Block sign-ins from outside the approved countries
• related CB-M365-AUTH-001 Block legacy authentication with Conditional Access
• related CB-M365-AUTH-003 Require MFA for all users on all resources
• related CB-M365-AUTH-005 Require phishing-resistant MFA for all users
• related CB-M365-AUTH-019 Protect security information registration with a managed device or MFA
• related CB-M365-AUTH-020 Require a compliant or hybrid joined device to access resources
• related CB-M365-AUTH-021 Block unknown or unsupported device platforms
• related CB-M365-AUTH-022 Block device code flow
• related CB-M365-AUTH-023 Block authentication transfer
• related CB-M365-AUTH-024 Limit administrator sessions with sign-in frequency and non-persistent browsers
• related CB-M365-AUDIT-009 Alert on every use of emergency access accounts
• related CB-M365-DEVICE-009 Require MFA to register or join devices through Conditional Access
• related CB-M365-AUTH-004 Require phishing-resistant MFA for administrative roles

People and lifecycle