Skip to content
microsoftadmin.in

SOP: Set up emergency access (break-glass) accounts in Entra ID

Purpose

Section titled “Purpose”

Guarantee a way back into the tenant when normal admin access fails — a Conditional Access policy that blocks every admin, a federation or MFA outage, or the last Global Administrator leaving.

Prerequisites

Section titled “Prerequisites”
  • Two hardware FIDO2 security keys (or certificate-based authentication if you already run a PKI).
  • A Log Analytics workspace for sign-in log alerts.
  • A secure, separate storage location for each credential (for example, two safes in different offices).

Steps (portal)

Section titled “Steps (portal)”
  1. Create two cloud-only accounts on the *.onmicrosoft.com domain, for example ea-admin-01@contoso.onmicrosoft.com. Use neutral names that don’t advertise their purpose. Don’t sync them from on-premises AD.
  2. Assign Global Administrator as an active, permanent assignment — not eligible in PIM. Activation could depend on the very thing that’s broken.
  3. Register phishing-resistant authentication for each account: one FIDO2 key per account. Microsoft enforces MFA for the Azure portal, Entra admin center and Intune admin center, and recommends passkeys (FIDO2) or certificate-based authentication for emergency accounts.
  4. Exclude both accounts from Conditional Access policies using a dedicated, tightly controlled group (for example CA-Exclude-EmergencyAccess). Restrict who can change that group’s membership.
  5. Send sign-in logs to Log Analytics: Entra admin center → Monitoring & health → Diagnostic settings → add SignInLogs.
  6. Create an alert in Azure Monitor that fires on any sign-in by these accounts (query below), checking every 5 minutes and notifying the security team.
  7. Store the credentials separately, with documented access steps.

Steps (PowerShell / Graph)

Section titled “Steps (PowerShell / Graph)”

Alert query (KQL) — use the accounts’ object IDs so renames don’t break it:

SigninLogs
| where UserId in ("<object-id-1>", "<object-id-2>")
| project TimeGenerated, UserPrincipalName, ResultType, IPAddress, Location, AppDisplayName

Confirm the role assignment is active and permanent:

Terminal window
Connect-MgGraph -Scopes 'RoleManagement.Read.Directory' -NoWelcome
$ga = Get-MgRoleManagementDirectoryRoleDefinition -Filter "displayName eq 'Global Administrator'"
Get-MgRoleManagementDirectoryRoleAssignment -Filter "roleDefinitionId eq '$($ga.Id)'" |
  Select-Object PrincipalId, DirectoryScopeId

Verify

Section titled “Verify”
  • Sign in with each account from a clean browser; confirm access to the Entra admin center.
  • Confirm the alert fired for each test sign-in.
  • Use the What If tool to confirm no Conditional Access policy applies to the accounts.

Rollback

Section titled “Rollback”

These accounts are a safety net, not a change to user access. If you need to retire one, remove its Global Administrator role, delete the account, and create its replacement first — never drop below two.

Do’s

Section titled “Do’s”
  • Test every 90 days and after any change to the admin team.
  • Record each test in your change log.
  • Keep the exclusion group membership limited to these two accounts.

Don’ts

Section titled “Don’ts”
  • Don’t use these accounts for daily admin work.
  • Don’t tie them to a person’s phone or mailbox.
  • Don’t give one person custody of both credentials.

Common mistakes

Section titled “Common mistakes”
  • Only one emergency account.
  • Accounts synced from on-premises AD instead of cloud-only.
  • Global Administrator assigned as eligible in PIM.
  • No alerting, so misuse goes unnoticed.

Weekly · 5-minute read

The Identity Brief

Identity & Microsoft 365 changes that need action, one SOP, one script — every week. Verified against official Microsoft sources.

No spam. Unsubscribe anytime. Privacy