An emergency access account exists so that a tenant can still be administered when normal sign-in fails: a federation outage, a Conditional Access policy that locks everyone out, an administrator who leaves without handover. Microsoft's guidance is specific and public. At least two accounts, cloud-only, on the .onmicrosoft.com domain, permanently assigned the Global Administrator role, excluded from every Conditional Access policy, and authenticated with a FIDO2 security key or a long password held offline.
Setting that takes an afternoon. It is worth writing about only because of three assumptions it hides, and each of the three survives inspection.
Excluded from Conditional Access is not excluded from everything
Tenant-level enforcement of multifactor authentication for sign-in to the Azure portal and the Entra admin centre is not a Conditional Access policy. There is no exclusion for it, and it is applied before policy is evaluated. A break-glass account whose only credential is a password in a safe cannot reach the portal at all. In my prior role I watched an account that had passed its annual test the year before fail on the first attempt after enforcement reached that tenant. The recorded test result was true when it was written and false when it was needed. The Microsoft-managed Conditional Access policies are a separate mechanism, can be excluded from, and should be. This is why we register a FIDO2 key on every one of these accounts and do not rely on a password alone.
The circular dependency, including ours
The credential has to be reachable when the tenant is not. We found that fault in our own run book in February 2026, during the first rehearsal. The offline password was held in a password manager whose own sign-in federated to the tenant the account existed to recover. The on-call engineer reached the vault login page and stopped. I wrote that instruction and one other person reviewed it before it went into the run book. Neither of us saw it, because we had both read it as a document rather than followed it as an instruction.
The credentials now sit on two FIDO2 keys, each held by a different named person, each in a tamper-evident envelope with its serial number on the asset register. Neither key is stored behind a sign-in that depends on the tenant it recovers, and the recovery instruction names the holder to call.
The alert exists; the delivery is the part to test
Sign-in by one of these accounts should raise an alert within minutes. Sign-in logs go to a Log Analytics workspace, an analytics rule matches the account object identifiers, and an action group carries the result somewhere. In the second rehearsal, in June 2026, the rule fired and the mail arrived. The page did not, because the action group held one email action and no push action. We had proved the rule and never the route. A rule that has never fired in production is not evidence, and firing it in production means signing in with the account.
Inspection tells you the account exists. Only a sign-in tells you it works.
What we check, in this order:
- Two accounts, each with its own FIDO2 security key, each key held by a different named person
- A sign-in test each quarter, with the date and the result recorded against the account
- Credential storage that does not depend on the tenant being reachable, and a recovery instruction that names the holder
- An alert proved by the quarterly test reaching whoever is on call, not by reading the rule
- Exclusion from per-user multifactor authentication settings and from Microsoft-managed policies, with a written note that tenant-level enforcement cannot be excluded
The assumption worth naming is that break-glass is a configuration: set once, then left alone. Inspection tells you the account exists. A sign-in tells you it works, and it is the item on this list most likely to move to next quarter. Ours moved once already, and the second rehearsal is the one that found the delivery fault.