Emergency access (break-glass) accounts in Microsoft Entra ID: set up, exclude and monitor

Every tenant needs a way back in when Conditional Access, federation or MFA goes wrong. Emergency access ("break-glass") accounts are that way back — as long as they don't share the failure you're recovering from, and nobody can use them quietly. In this post I'll set up two accounts the way Microsoft currently recommends, exclude them safely from Conditional Access, alert on every use and run the first test drill.

Prerequisites#

• Rights to create users and assign Global Administrator (Global Administrator, or User Administrator plus Privileged Role Administrator); Conditional Access Administrator and Authentication Policy Administrator for the policy work.
• FIDO2 security keys (device-bound passkeys) — at least one per account, ideally a spare each — or an existing PKI if you prefer certificate-based authentication (CBA).
• Two separate, secure storage locations such as fireproof safes, and a designated secure workstation (for example a Privileged Access Workstation) for using the accounts.
• A Log Analytics workspace for Microsoft Entra sign-in and audit logs. Exporting sign-in logs requires Microsoft Entra ID P1 or P2.

Step-by-step#

1. Create two cloud-only accounts#

Use the tenant's *.onmicrosoft.com domain so the accounts don't depend on a custom domain, federation or synchronisation. Don't associate them with a person, and give each a long random password that goes into the safe.

Connect-MgGraph -Scopes 'User.ReadWrite.All','RoleManagement.ReadWrite.Directory','Group.ReadWrite.All',
  'Policy.Read.All','UserAuthenticationMethod.Read.All'
$pp  = @{ Password = '<long random password>'; ForceChangePasswordNextSignIn = $false }
$ea1 = New-MgUser -DisplayName 'Emergency Access 01' -UserPrincipalName 'ea01@contoso.onmicrosoft.com' `
  -MailNickname 'ea01' -AccountEnabled -PasswordProfile $pp -PasswordPolicies 'DisablePasswordExpiration'
# Permanent, active Global Administrator assignment
New-MgRoleManagementDirectoryRoleAssignment -PrincipalId $ea1.Id -DirectoryScopeId '/' `
  -RoleDefinitionId '62e90394-69f5-4237-9190-012177145e10'

Repeat for the second account ($ea2). The assignment must be active and permanent, not eligible: if every Global Administrator assignment needs PIM activation and approval, losing your approvers or their MFA can lock the whole tenant.

2. Register a phishing-resistant method#

1. In Entra ID › Authentication methods › Policies, enable Passkey (FIDO2) for a group containing the accounts. If you restrict key models, allow the model you bought.
2. Issue each account a Temporary Access Pass (enabled in the same policy list) so it can register without a phone — see Temporary Access Pass onboarding.
3. On the secure workstation, sign in to Security info as the account and add the passkey on its security key. Label the keys, keep each account's keys separate, then delete the Temporary Access Pass.
4. Make sure no method points to a person: no Authenticator on someone's phone, and no personal phone number or email for MFA or self-service password reset.

Choose a method that differs from your everyday admin accounts: if admins use Authenticator, security keys give you an independent path.

3. Exclude them from Conditional Access — safely#

Microsoft's guidance is to exclude emergency access accounts from every Conditional Access policy that blocks or restricts sign-in; report-only policies don't need the exclusion. Use one group so the exclusion is consistent:

$g = New-MgGroup -DisplayName 'EmergencyAccess' -MailEnabled:$false -MailNickname 'EmergencyAccess' `
  -SecurityEnabled -IsAssignableToRole
$ea1, $ea2 | ForEach-Object { New-MgGroupMember -GroupId $g.Id -DirectoryObjectId $_.Id }

A role-assignable group can only have its membership changed by Privileged Role Administrators, Global Administrators and its owners (so give it none) — important, because anyone who can join this group bypasses your policies. Add the group to the exclusions of every enforced policy, including Microsoft-managed and risk-based ones, then check nothing was missed:

Get-MgIdentityConditionalAccessPolicy -All |
  Where-Object { $_.State -eq 'enabled' -and $_.Conditions.Users.ExcludeGroups -notcontains $g.Id } |
  Select-Object DisplayName

Any policy listed can lock the accounts out.

4. Alert on every sign-in and change#

1. In Entra ID › Monitoring & health › Diagnostic settings, send SignInLogs, NonInteractiveUserSignInLogs and AuditLogs to the workspace.
2. In the Azure portal, open Monitor › Alerts › Create › Alert rule. Scope it to the workspace, choose the Custom log search signal and the query below, with a threshold of greater than 0, severity 0 - Critical, and an action group that notifies several people.

let ea = dynamic(["<object ID 1>", "<object ID 2>"]);
union isfuzzy=true SigninLogs, AADNonInteractiveUserSignInLogs
| where UserId in (ea)
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, ResultType, ResultDescription

Add a second rule for changes to the accounts or the exclusion group, such as password resets, method changes and role or membership edits:

let watch = dynamic(["<object ID 1>", "<object ID 2>", "<EmergencyAccess group ID>"]);
AuditLogs
| where tostring(TargetResources) has_any (watch) or tostring(InitiatedBy) has_any (watch)
| project TimeGenerated, OperationName, Result, InitiatedBy, TargetResources

5. Run the first drill#

Microsoft recommends validating the accounts at least every 90 days, after IT staff changes and when your Microsoft Entra subscriptions change:

1. Tell your security operations team first, so the alert is expected.
2. Take a key from the safe and, on the secure workstation, sign in to https://entra.microsoft.com in a private browser window.
3. Perform a harmless admin task, such as reviewing Global Administrator assignments in Entra ID › Roles & admins.
4. Confirm the alert arrived, then review the list of authorised people, the written procedure and the safe combinations.

Verify#

• The drill's sign-in log entry shows the passkey under Authentication Details, and the Conditional Access tab shows no enforced policy applied.
• In Privileged Identity Management, both accounts appear under the Global Administrator Active assignments with a permanent end time.
• The step 3 check returns nothing, and each account has only the methods you registered:

Get-MgUserAuthenticationMethod -UserId 'ea01@contoso.onmicrosoft.com' |
  ForEach-Object { $_.AdditionalProperties['@odata.type'] }
# Expect only #microsoft.graph.passwordAuthenticationMethod and #microsoft.graph.fido2AuthenticationMethod

Tips & gotchas#

• Nothing may expire or be cleaned up. Keep the accounts out of inactive-account clean-ups, access reviews and lifecycle automation, and track certificate expiry if you use CBA.
• The password still matters. Outside Conditional Access, it can still be a usable first factor for apps that mandatory MFA doesn't cover, so keep it long, random and in the safe — and rely on the sign-in alert.
• Keep cloud and on-premises emergency access separate. The cloud accounts must not depend on AD FS, synchronisation or on-premises MFA.
• Investigate every alert: was it a drill, a real emergency or misuse? Preserve the logs and review what the account did.
• Prepare contingency policies. Disabled Conditional Access policies you can switch on during an outage reduce the need for these accounts — see a Conditional Access baseline.

References#

• Manage emergency access accounts in Microsoft Entra ID