Microsoft Entra ID Break-Glass Accounts: A Setup Guide

Microsoft's own guidance is that every Entra ID tenant should have at least two emergency access accounts: cloud-only accounts on the default onmicrosoft.com domain, permanently assigned the Global Administrator role, excluded from Conditional Access policies, tied to no individual person, and tested on a schedule. They exist for the day your normal path into the tenant stops working — a Conditional Access policy applied too broadly, a federated identity provider outage, a directory sync failure, or the sudden departure of the one administrator who could approve anything.

Why the default admin path is not enough

The scenarios that lock an organization out of Entra ID are rarely dramatic. The most common is mundane: someone tightens a Conditional Access policy, scopes it to All users instead of a group, and every administrator — including the person who made the change — is now blocked from the portal by their own rule. There is no undo button on the far side of a lockout.

The second most common is a dependency you did not think of as a dependency. If your administrators sign in through an on-premises federation service or a third-party identity provider, then that system's availability is your tenant's availability. If your admin accounts are synced from on-premises Active Directory, a sync failure or an on-premises outage propagates straight into your cloud control plane. A break-glass account that is cloud-only and on the default domain sidesteps all of it, because it has no upstream to fail.

The configuration checklist

Setting these up correctly is mostly about removing dependencies:

1. Cloud-only, default domain. Create the accounts directly in Entra ID on the *.onmicrosoft.com domain. Do not sync them from on-premises and do not put them on a custom domain whose DNS or federation could fail.
2. Permanent Global Administrator. Assign the role permanently rather than through Privileged Identity Management. PIM activation is itself a dependency — if the thing you need to fix is blocking sign-in, you cannot activate a role to fix it.
3. Excluded from Conditional Access. At minimum one account must be excluded from every Conditional Access policy in the tenant. This is the exclusion that saves you from the lockout scenario above, and it needs to be re-checked whenever a new policy is created.
4. Phishing-resistant authentication. Bind the accounts to FIDO2 keys or certificate-based authentication rather than leaving them on a password alone. Excluding an account from policy is not a reason to weaken its credential.
5. No individual ownership. The account must not be registered to a specific person's phone, hardware token, or mailbox. People leave, lose devices, and go on holiday during incidents.
6. Monitored. Configure sign-in alerts so any use of a break-glass account raises an immediate, loud signal. These accounts should have a sign-in count of zero in normal operation, which makes them trivially easy to alert on.
7. Protected from automation. Exclude them from access reviews, dormant-account cleanup, and license reclamation. A well-maintained emergency account is indistinguishable from an abandoned one to a cleanup script.

The part most teams get wrong

Everything above is well documented, and most organizations that set up break-glass accounts get most of it right. The step that quietly fails is storage.

Once you have created an account that bypasses your Conditional Access policies and holds permanent Global Administrator, you have created a credential that can do anything in your tenant. Where it lives now matters more than how it was configured. Three storage failures recur:

• Circular dependency. The credential sits in a password manager or vault that authenticates through the same Entra ID tenant. The outage that requires the credential also blocks access to it.
• Key-person risk. One administrator holds it — in a personal vault, a sealed envelope in a drawer, or their own memory. When they are unreachable, so is the tenant.
• No accountability. The credential sits in a shared vault that a dozen people can open silently. It is available, but its use cannot be attributed, which fails the audit requirement that made you document the procedure in the first place.

The resolution to all three is the same shape: the credential should require more than one person to release, should be held somewhere with no dependency on the identity provider it recovers, and should produce a tamper-evident record when it is used. That is the quorum model — the credential is split so that no single holder can reconstruct it alone, and reassembly is logged. Our break-glass access solution is built around exactly that pattern, and the security architecture explains how the split happens in the browser so the plaintext never reaches a server.

Test it, or you do not have it

An untested break-glass account is a belief, not a control. Validate on a fixed cadence and after any change to Conditional Access, the admin roster, or the storage location. A test means actually signing in with the account, confirming it reaches the portal with the expected permissions, and confirming the alert fired — not just confirming the account still exists in the directory.

Record the result. Auditors under SOC 2, ISO 27001, DORA, and NIS2 increasingly want evidence that emergency access was exercised, not merely defined, and the test log is the cheapest evidence you will ever produce.

For the vendor-neutral version of these rules, see our guide to break-glass account best practices. If your concern is the identity provider going down rather than a policy locking you out, the IdP outage response checklist covers that path instead.

Glassbreak is available on a Free tier for individuals, with Team at $15 and Business at $39 per month; SSO is included from Business, and SCIM, BYOK, and BAA support are Enterprise features. Checkout is currently early access — see pricing for the current details.