Emergency access accounts, usually called break glass accounts, exist for the day the normal way in stops working. Microsoft lists the situations: a federation or identity provider outage, administrators' MFA devices or the MFA service unavailable, the last Global Administrator leaving (Entra ID prevents deleting the last Global Administrator account, but not disabling or deleting it on-premises), a natural disaster, or a PIM lockout where every Global Administrator and Privileged Role Administrator assignment is eligible, approval is required, and no active approver exists. Most tenants have two of these accounts. Fewer have accounts that would work under those conditions. Here is the checklist, then the detail behind each item.
The 12-item checklist
Print this, work through it once, and re-check it every quarter.
- Two or more accounts, created directly in Entra ID, not synchronized or federated.
- Named on the tenant's
.onmicrosoft.comdomain, with no person's name in the UPN or display name. - Global Administrator assigned as permanent active, never PIM eligible.
- A passwordless, phishing-resistant method registered: a FIDO2 passkey, or certificate-based authentication if you already run a PKI.
- A different authentication method from the one your daily administrators use.
- Keys and credentials stored in fireproof safes in separate secure locations, known only to authorized people.
- Excluded, through a dedicated group such as EmergencyAccess, from every Conditional Access policy that blocks or restricts sign-in.
- The exclusion proven with a query, not assumed from memory.
- Credentials and devices set never to expire and kept out of inactive-account cleanup.
- An alert on every sign-in and every audit event, delivered on a channel that works during an outage.
- Sign-in tested at least every 90 days, after any IT staff change, and against the current Conditional Access configuration.
- A one-page runbook that says who may use the accounts, from which workstation, and what happens afterward.
Create the accounts: cloud-only, generic, two or more
Microsoft recommends two or more emergency access accounts; its roles best-practice page phrases it as two cloud-only accounts permanently assigned the Global Administrator role. Create them directly in Entra ID on the .onmicrosoft.com domain, never synchronized from on-premises Active Directory and never on a federated domain, so they still work when the identity provider, the sync server, or the corporate network does not.
The accounts should not be associated with any individual user. Use neutral names and keep the list of authorized users outside the tenant. If auditors want per-person accountability, Microsoft's alternative is one emergency account per administrator. Keep emergency access for cloud services separate from emergency access for on-premises systems, with no dependency in either direction. For how many privileged accounts a tenant should carry in total, see how many Global Administrators a Microsoft 365 tenant should have.
Assign Global Administrator as permanent active, not eligible
If you use Privileged Identity Management for daily administrators, do not treat the emergency accounts the same way. Microsoft says their Global Administrator assignment should be permanent active, not eligible. The PIM lockout scenario above is exactly where an eligible break glass account fails: nobody with an active assignment is left to approve the activation. The permanent assignment is also why the storage and alerting controls below matter. See PIM eligible assignment for the distinction, and Entra PIM without P2 if you run without a P2 license.
Register FIDO2 keys and store them apart
Microsoft directs organizations to choose a passwordless, phishing-resistant method for these accounts: a passkey on a FIDO2 security key is the recommended option, and certificate-based authentication is the alternative when a PKI already exists. Both satisfy the mandatory MFA requirement, so there is no reason to create an MFA exemption.
The method must differ from what regular administrators use. If daily admins sign in with Microsoft Authenticator, the emergency accounts use FIDO2 keys, so an outage or compromise of the Authenticator path does not take the emergency path with it. A sensible pattern is two keys per account, stored in secure, fireproof safes in separate, secure locations, known only to authorized individuals, with the runbook recording where each key lives and who can open each safe. The credential must never expire and must be kept out of any inactivity cleanup. Anyone using a key should do it from a designated secure workstation or a Privileged Access Workstation.
Exclude them from Conditional Access, then prove it
Emergency access accounts should be excluded from Conditional Access policies that block or restrict sign-in; report-only policies do not need an exclusion. Microsoft suggests a dedicated security group such as EmergencyAccess, excluded as a group rather than user by user. The group is also what makes the exclusion checkable.
The usual failure is drift: someone creates a policy that requires a compliant device or blocks a legacy protocol and forgets the group. Run this after every policy change and in the quarterly test. It lists every policy, its state, and whether the group or both accounts are excluded. Replace the placeholders with object IDs from your tenant.
Connect-MgGraph -Scopes "Policy.Read.All"
$group = "EMERGENCYACCESS-GROUP-OBJECT-ID"
$accounts = @("ACCOUNT-1-OBJECT-ID", "ACCOUNT-2-OBJECT-ID")
Get-MgIdentityConditionalAccessPolicy -All | ForEach-Object {
$users = $_.Conditions.Users
$byGroup = $users.ExcludeGroups -contains $group
$byUser = @($accounts | Where-Object { $users.ExcludeUsers -contains $_ }).Count -eq $accounts.Count
[pscustomobject]@{
Policy = $_.DisplayName
State = $_.State
Excluded = ($byGroup -or $byUser)
}
} | Sort-Object Excluded, Policy | Format-Table -AutoSizeEvery enabled policy that blocks or restricts sign-in should show Excluded: True; report-only rows may show False. File the output with the quarterly test record so you can show an auditor or insurer that the exclusion was in place on a given date.
Keep the credentials from expiring
Microsoft's guidance is that the device or credential for an emergency access account must not expire or fall within automated cleanup for inactivity. That means three checks: any password that exists alongside the passkey is set to never expire; any script or governance rule that disables or deletes accounts with no recent sign-in skips the EmergencyAccess group; and any device compliance requirement is one the accounts are excluded from, which the query above confirms. A break glass account that a stale-account job quietly disabled months ago is a failure you discover on the day you need it.
Alert on every sign-in without Sentinel
Microsoft says to monitor all sign-in and audit log activity for these accounts and configure alerts for every use, so each sign-in can be confirmed as a test or a real emergency. It names Azure Monitor and Microsoft Sentinel as options, but you do not need a SIEM. A Log Analytics workspace with the tenant's sign-in logs routed to it through Entra diagnostic settings is enough. Create a log alert rule on this query, keyed to object IDs rather than display names so a rename cannot silence it:
SigninLogs
| where UserId in ("ACCOUNT-1-OBJECT-ID", "ACCOUNT-2-OBJECT-ID")
| project TimeGenerated, UserPrincipalName, ResultType, IPAddress,
AppDisplayName, ConditionalAccessStatus, AuthenticationRequirementFire when the result count is greater than zero, use a short evaluation window, and point the action group at more than one person on more than one channel, including one that does not depend on Microsoft 365 being available, since a Microsoft outage is one reason the account would be used. Add a second rule on AuditLogs filtered to the same object IDs as the initiating user, so you also see what the account changed. With no workspace yet, the fallback is an alert policy in the Microsoft Defender portal scoped to sign-in activity by the two accounts, and the floor is a weekly manual review of the sign-in log filtered to their UPNs.
Test at least every 90 days
Microsoft says to validate emergency access account functionality at least every 90 days and after IT staff changes such as a termination or a change of position, and to test sign-in against the current Conditional Access configuration at least quarterly. Put the test on a calendar with a named owner.
- Record the date, the tester, the account and key under test, and who retrieved the key from which safe.
- From the designated secure workstation, sign in to the Microsoft Entra admin center with the account and its FIDO2 key. Note every prompt; a Conditional Access block or a request to register another method is a finding.
- Open Roles and administrators and confirm the account still holds an active Global Administrator assignment.
- Confirm the sign-in alert fired and reached every intended recipient on every channel.
- Sign out, return the key, and log the return.
- Repeat for the second account and its key, ideally from the second location.
- Run the Conditional Access exclusion query and attach the output.
- Record findings, fixes made, and the next test date.
Because the alert should fire during the test, the test also proves the monitoring. Because it uses a real key from a real safe, it also proves the storage procedure.
The one-page runbook for the day you need it
Write it before you need it, keep a printed copy with each key, and keep a copy outside the tenant.
- When to use. The scenarios at the top of this page. Never for routine work, and never because it is faster than a PIM activation.
- Who decides. Two roles (not two named people) who can authorize use, and how they confirm it when normal channels are down.
- Where the keys are. Location, safe, and who holds the combination.
- How to sign in. From the designated secure workstation or Privileged Access Workstation only: the UPN, the method, and the prompts to expect.
- What to do. The minimum change that restores normal administration: re-enable a locked-out administrator, fix the Conditional Access policy that locked everyone out, or restore the sync or federation path. Then sign out.
- Afterward. Microsoft says to conduct a post-mortem review after any use to determine whether the use was authorized and the actions appropriate. Confirm the alert fired, review the audit log for everything the account touched, return the key, and re-run the checklist.
If you reached for the break glass account because an administrator was compromised rather than because of an outage, the containment steps are in what to do when an Entra admin account is compromised.
Where Orbitra fits
A break glass account is the one identity you never want a response tool to touch by accident. In Approve mode, Orbitra recommends from an allowlisted catalog of more than two dozen governed response actions, your team reviews the target identity and its blast radius, and a named person signs off before Orbitra executes. That review is where you confirm the target is not an emergency access account. Orbitra tells you which steps are permanent before you approve them, and independently re-reads Microsoft after supported response actions to verify the final state, so the evidence receipt for each supported change to a privileged identity shows who approved it and what Microsoft reported afterward. See how it works.
Related reading
Sources
- Manage emergency access admin accounts in Microsoft Entra ID (Microsoft Learn, checked September 2026)
- Best practices for Microsoft Entra roles (Microsoft Learn, checked September 2026)
Frequently asked questions
How many break glass accounts does Microsoft recommend?
Two or more. Microsoft's roles best-practice page phrases it as two cloud-only emergency access accounts permanently assigned the Global Administrator role. They should be created directly in Entra ID on the .onmicrosoft.com domain, not synchronized from on-premises or placed on a federated domain.
Should break glass accounts be excluded from Conditional Access?
Yes, from every policy that blocks or restricts sign-in. Report-only policies do not need an exclusion. Microsoft suggests a dedicated security group such as EmergencyAccess for the exclusion, which also makes it possible to prove the exclusion with a query rather than checking each policy by hand.
Should break glass accounts be PIM eligible?
No. Microsoft says the Global Administrator assignment for emergency access accounts should be permanent active, not eligible. One of the scenarios these accounts exist for is a PIM lockout where every Global Administrator and Privileged Role Administrator assignment is eligible, approval is required, and no active approver exists.
Do break glass accounts need MFA?
Yes. Microsoft directs organizations to register a passwordless, phishing-resistant method: a FIDO2 passkey is the recommended option, with certificate-based authentication as the alternative when a PKI already exists. Both satisfy the mandatory MFA requirement. The method must differ from the one regular administrators use.
How often should break glass accounts be tested?
At least every 90 days, and also after IT staff changes such as a termination or a change of position. Microsoft also suggests testing sign-in against the current Conditional Access configuration at least quarterly. After any real use, conduct a post-mortem review of whether the use was authorized and the actions appropriate.