How to create a break-glass account in Entra ID

A break-glass account in Entra ID is a cloud-only Global Administrator with a permanent role assignment, excluded from every Conditional Access policy, protected by FIDO2 keys in a safe, and watched by an alert that fires the moment anyone signs in with it. It exists for the day MFA, federation, Conditional Access, or the person who holds Global Admin is unavailable — which in a tenant that runs a tight Conditional Access baseline is a question of when, not if.

The design reasoning — why cloud-only, why not PIM, what "excluded from everything" really means — is in Conditional Access break-glass account design. This page is the build.

Prerequisites

Global Administrator to create the account and assign the role.
Two FIDO2 security keys (hardware) per account, and FIDO2 enabled in Entra → Protection → Authentication methods → Policies → FIDO2 security key for the break-glass group.
Somewhere physical to keep credentials: a safe, or two safes in different offices. A password manager shared with the whole IT team is not it.
A log destination that can alert: Microsoft Sentinel, a Log Analytics workspace with an alert rule, or at minimum Defender XDR custom detection. See Microsoft 365 monitoring and alerts.

Steps

Progress 0/6

1.Create the accounts↓
2.Assign Global Administrator permanently↓
3.Register FIDO2 keys↓
4.Create the exclusion group and exclude it everywhere↓
5.Add the one policy that does apply to them↓
6.Alert on every sign-in↓

Progress is saved in this browser only.

1. Create the accounts

Entra admin center → Users → New user. Use the tenant's .onmicrosoft.com domain, not a federated or synced domain — a federation outage must not affect the account. Pick a name that does not announce itself in a directory listing (svc-recovery-01 beats breakglass-admin). Usage location set; no licence needed for Global Admin, though a licence does no harm. Cloud-only, never synced from AD.

Generate a long random password (30+ characters). Print it, split it if your policy calls for it, and put it in the safe. Do not store it in the browser.

2. Assign Global Administrator permanently

Entra → Roles and administrators → Global Administrator → Add assignments. If PIM is in use, choose Active assignment type with Permanently assigned — not Eligible. Put a justification in the ticket, not just the PIM prompt.

3. Register FIDO2 keys

Sign in as the break-glass account (from a clean admin workstation) to My Security Info and add both security keys. Set a PIN on each key; record the PIN with the password. Register no phone number, no Authenticator, no email — every additional method is an attack surface for the most powerful account in the tenant.

4. Create the exclusion group and exclude it everywhere

Create a security group CA-Exclude-BreakGlass with both accounts as members, assignable-to-role protected if you like. Add it to Exclude on every existing Conditional Access policy, including report-only ones, and make it the first line of your policy template so new policies get it by default. Also exclude the group from Intune compliance requirements — a device-compliance grant is a Conditional Access policy like any other.

5. Add the one policy that does apply to them

New policy: users = CA-Exclude-BreakGlass only, all cloud apps, grant Require authentication strength → Phishing-resistant MFA. This is the only policy the accounts are subject to, and it guarantees the password alone is never enough. If the FIDO2 infrastructure itself is what broke, you switch this policy off with the other account — which is the reason there are two.

In Sentinel or Log Analytics with SigninLogs (and AADNonInteractiveUserSignInLogs) connected:

KQL

SigninLogs
| where UserPrincipalName in~ ("svc-recovery-01@contoso.onmicrosoft.com","svc-recovery-02@contoso.onmicrosoft.com")
| project TimeGenerated, UserPrincipalName, IPAddress, ResultType, AppDisplayName

Alert on any row, severity High, to a channel that reaches the security lead's phone. A break-glass sign-in that nobody planned is a compromise until proven otherwise. The KQL primer covers the syntax if this is new.

Verify

From a fresh browser, sign in with account one using password + FIDO2 key; confirm you land in the Entra admin center with Global Administrator, and that the alert fired.
Run the Conditional Access What If tool for the account against a few apps: the only policy that should apply is the phishing-resistant one.
Repeat for account two. Record the test date; repeat quarterly and after any Conditional Access change.

Roll back

If a key is lost, sign in with the other key (or account), remove the lost key under Authentication methods, register a replacement, and update the safe contents. If an account is suspected compromised, treat it exactly like any compromised account using the other break-glass account to do it — and rotate both.

Frequently asked questions

How many break-glass accounts should a tenant have?

Two. One is a single point of failure — if its key is in a safe in an office you cannot reach, you are locked out. Two accounts, with credentials stored in different physical locations and held by different people, is Microsoft's guidance and the practical minimum.

Should break-glass accounts have MFA?

Yes, but not phone-based MFA. Microsoft's current guidance is phishing-resistant methods — FIDO2 security keys or certificate-based authentication — registered on keys stored with the credentials. Exclude the accounts from every ordinary Conditional Access policy, then create one dedicated policy that applies only to them and requires phishing-resistant authentication strength. Do not rely on Authenticator on someone's personal phone.

Should the break-glass account be eligible in PIM or a permanent Global Administrator?

Permanent active assignment. The point of the account is to work when PIM, Conditional Access, MFA, or federation is broken; an eligible assignment that needs activation through PIM defeats the purpose. Accept the standing privilege and control it with alerting on every sign-in.