Entra ID break-glass accounts that work when nothing else does

A tenant can lock itself without any attacker. If every Global Administrator and Privileged Role Administrator assignment is eligible, activation requires approval and no approvers are selected, nobody can approve anything. Active administrators are the default approvers, and there are none. Two cloud-only break-glass accounts, set up and drilled in advance, are the way out.

When you will need them

Microsoft's emergency access guidance lists the cases. Federation is down because your identity provider host has failed. Every administrator registered only phone calls and text messages for MFA, and the mobile network is out. The last person with Global Administrator access leaves, and the account is disabled or deleted on-premises, which Entra ID does not stop.

Build the accounts

Create at least two accounts. Make them cloud-only on the *.onmicrosoft.com domain, not federated and not synchronised from on-premises. Assign each the Global Administrator role.

In Privileged Identity Management (PIM), make that assignment active permanent, not eligible. Everyday administrators should use just-in-time access, but these accounts cannot depend on an activation step, because that step may be exactly what is unavailable. PIM needs Microsoft Entra ID P2 or Entra ID Governance.

The sources do not cover tenants without PIM, so this part is our reasoning. The active-versus-eligible setting lives in PIM and does not apply there. The accounts still need a direct, standing Global Administrator assignment, for the same reason: nothing should have to be activated.

For authentication, choose a passwordless method that satisfies the MFA requirement:

• Passkey (FIDO2), which Microsoft recommends.
• Certificate-based authentication, if you already run a PKI.

Use a different method from your everyday administrators. If they use the Microsoft Authenticator app, give the emergency accounts a FIDO2 security key. Do not tie shared accounts to a person or to an employee-supplied device such as a phone. Microsoft also allows individual emergency accounts per administrator, which gives accountability and lets people use them from remote locations. Pick one model deliberately.

Store the keys in fireproof safes in secure, separate locations, available to the people authorised to use them. Use a designated secure workstation, such as a Privileged Access Workstation, whenever someone signs in with these accounts.

Exclude them from Conditional Access

An enforced policy that requires MFA, a compliant device or another control can make the account unusable during the emergency. The phishing-resistant credential is what protects the account, so exclude it from any policy that blocks or restricts sign-in. Conditional Access needs Entra ID P1.

Create a dedicated security group, for example EmergencyAccess, put both accounts in it and exclude the group from those policies. Report-only policies do not block access and need no exclusion.

A group alone is not enough, because new policies are written by people who may not remember these accounts exist. Open every enabled policy and check its Exclude section for the group. Check report-only policies again before anyone switches them on. Add "is EmergencyAccess excluded?" to the review checklist for every new policy, and test a sign-in after each significant change.

Alert on every sign-in

These accounts should sign in only for drills and real emergencies, so any sign-in deserves an alert. Microsoft's example uses Azure Monitor and needs your Entra sign-in logs sent to a Log Analytics workspace first.

1. In the Entra admin center, as at least a User Administrator, go to Entra ID > Users, open each emergency account and copy its Object ID.
2. In the Azure portal, as at least a Monitoring Contributor, open Monitor > Alerts and select + Create > Alert rule.
3. On the Scope tab, select your Log Analytics workspace.
4. On the Condition tab, choose Custom log search as the signal name and Aggregated logs as the query type.
5. Enter a query with both Object IDs:

SigninLogs
| where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee" or UserId == "11bb11bb-cc22-dd33-ee44-55ff55ff55ff"
| project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription

1. Under Measurement, select the measure, the aggregation type and the aggregation granularity. Under Split by dimensions, select the Resource ID column.
2. Under Alert logic, set the threshold type to Static, the operator to Greater than and the threshold value to 0. Set the evaluation frequency to how quickly you want to hear about it.
3. Route the alert to email and SMS for several administrators, not one.

Microsoft also shows a query by UserPrincipalName. We use the Object ID out of habit, since a query written around a name depends on that name staying as it is. For each extra account, add another or UserId == "ObjectGuid" clause.

If nobody on your team watches alerts out of hours, a managed monitoring service can take that part.

Test them and review every use

Validate the accounts at least every 90 days. A drill should cover the authorised-user list, a real sign-in with the security key, and an administrative task. It should confirm that the accounts still sign in under your current Conditional Access configuration, and that each key or certificate is present and has not expired or been removed by automated cleanup.

Each drill should trigger your alert. Repeat the test after any change to the workspace or the diagnostic settings that feed it. Keep a short log:

After any real use, hold a post-mortem. Decide whether the use was authorised and whether the actions taken were appropriate. Regulated organisations can show this record, with the logs and drill log, as evidence that emergency access is governed. If you want an outside check, our consulting team can review the setup.

Where to start

1. List your Global Administrators in the Entra admin center and check the count against Microsoft's guidance of fewer than five. Find out whether any account is already intended for emergencies.
2. Create two cloud-only .onmicrosoft.com accounts with a permanent active Global Administrator assignment, and register a different FIDO2 key for each.
3. Create the EmergencyAccess group and exclude it from every Conditional Access policy that blocks or restricts sign-in.
4. Send sign-in logs to Log Analytics and build the alert rule with a threshold greater than 0 on both Object IDs.
5. Put the keys in separate fireproof locations, name the authorised users, and check that no credential expires or sits in scope of automated cleanup.
6. Sign in with each account, confirm the alert fires, fill in the first drill log row and put the next drill in the calendar within 90 days.