Reviewing emergency access (break-glass) accounts
On this page
Emergency access (break-glass) review
Scenario 6, and the gate on every other scenario. Sources: benchmark guidance / 2.2.1 (distilled in
) and Microsoft's own guidance
(). Where they differ, see
§5 — the checklist below is the
combined, stricter position.
The five scenarios these accounts exist for
Useful when a customer needs convincing. Microsoft names them:
- Accounts are federated and federation is unavailable — IdP outage or network break.
- Admins registered Entra MFA and all their devices, or the service, are unavailable —
e.g. a carrier outage where phone call and SMS were the only registered methods.
- The last person with Global Administrator access leaves. Entra prevents deleting the
last GA in the cloud, but not deleting or disabling it on-premises.
- Natural disaster — mobile and other networks unavailable.
- **All GA and Privileged Role Administrator assignments are eligible, activation requires
approval, and no approvers are selected** (or the selected approvers left the directory).
Active GAs are the default approvers; with none active, **nobody can approve activation
and tenant administration is locked** — with no policy misconfiguration at all.
Scenario 5 is a PIM configuration trap. Test for it whenever a customer describes a
fully-eligible admin model.
Review checklist
Work every item. Report each as Pass / Fail / Not stated — "not stated" is a distinct
result and must never be silently scored as a pass.
Accounts
| # | Check | Required state | Severity if failed |
|---|---|---|---|
| 1 | Count | Two | Critical |
| 2 | Naming | Does not identify any individual | Medium |
| 3 | Domain | Default .onmicrosoft.com, not a custom domain | High |
| 4 | Directory type | Cloud-only, not synced from on-premises | Critical |
| 5 | Licensing | Unlicensed | Medium |
| 6 | Sign-in state | Enabled — not blocked, not disabled | Critical |
| 7 | Role | Global Administrator, permanently assigned | Critical |
| 8 | Role assignment style | Permanent, not PIM-eligible | Critical |
On #3: custom domains can expire, be mis-transferred, or have DNS broken. The
.onmicrosoft.com domain cannot fail the same way, so the recovery account stays reachable
during exactly the failure it exists for.
On #8: a PIM-eligible break-glass account is not a break-glass account. If PIM or the
activation path is unavailable, the account cannot be used. benchmark guidance permits permanent
Assigned state specifically and only for up to two break-glass Global Administrators
(5.3.1).
Authentication
| # | Check | Required state | Severity if failed |
|---|---|---|---|
| 9 | MFA present | Yes — mandatory for all accounts since 15 Oct 2024, break-glass included | Critical |
| 10 | Method type | Passkey (FIDO2) or certificate-based authentication | High |
| 11 | Method independence | Does not depend on a phone, carrier, or the Authenticator push service | High |
| 12 | Password strength | ≥ 16 characters, randomly generated | High |
| 13 | Password custody | Split into parts held by different people, or equivalent dual control | Medium |
| 14 | Physical custody | FIDO2 keys in a secure, separate, fireproof location | Medium |
| 14a | Method differs from normal admin accounts | If regular admins use Authenticator, break-glass uses FIDO2 | High |
| 14b | Credential/device does not expire | Not subject to automated cleanup for lack of use | High |
| 14c | Not tied to any employee-supplied device | No personal phones | High |
On #11 — the failure mode people miss: if both accounts use Authenticator push and the
outage you are recovering from is an MFA service outage or a carrier failure, neither
account works. The methods must not share a dependency with the thing most likely to fail.
Conditional Access
| # | Check | Required state | Severity if failed |
|---|---|---|---|
| 15 | Exclusion coverage | At least one account excluded from every CA policy | Critical |
| 16 | Exclusion mechanism | Direct user exclusion, or a role-assignable / PIM-managed group | Critical |
| 17 | New-policy discipline | A documented step requiring the exclusion on every new policy | High |
| 18 | Exclusion verification | Confirmed policy-by-policy, not assumed | High |
On #16 — the highest-value finding in this whole review. If the exclusion group is an
ordinary security group, anyone holding Group Administrator can add themselves to it
and bypass Conditional Access entirely, and can also remove the break-glass account without
detection. It must be a role-assignable group or managed through PIM for Groups (licensed).
On #15 — the trade-off to present honestly rather than resolve: benchmark guidance requires at least one
account excluded from all policies. Excluding both maximises recoverability but doubles the
unprotected surface. Excluding one keeps a hardened spare but risks the protected account
being caught by the same failure. State the trade-off and let the customer choose.
Monitoring
| # | Check | Required state | Severity if failed |
|---|---|---|---|
| 19 | Sign-in alerting | Alert on every sign-in, to a monitored destination | High |
| 20 | Alert priority | High severity, treated as an incident | Medium |
| 21 | Alert routing | Goes to people who will actually see it out of hours | High |
| 22 | Alert tested | Verified by an actual test sign-in | High |
| 23 | Audit log alerting | Changes to the accounts also alert | Medium |
Implementation options — benchmark guidance accepts any method that covers all break-glass activity:
- Defender for Cloud Apps activity policy (the benchmark guidance prescribed route): High
severity, category Privileged accounts, single activity, filters Activity type = Log on
and User Name = <account>.
- Azure Monitor / Log Analytics with an alert rule on sign-in logs — the route for
tenants without Defender for Cloud Apps. Requires an Azure subscription.
- Microsoft Sentinel analytics rule.
Do not present the Defender route as the only compliant one.
Governance
| # | Check | Required state | Severity if failed |
|---|---|---|---|
| 24 | Written procedure | Authorised and distributed by senior management | High |
| 25 | Usage authorisation | Defined — who may authorise use, and when | Medium |
| 26 | Test frequency | At least every 90 days (Microsoft), plus a quarterly test that the accounts still sign in under current CA config | High |
| 26a | Retest on trigger events | On IT staff change (termination or role change) and on subscription change | Medium |
| 26b | Secure workstation | A PAW or designated secure client environment is used when accessing these accounts | Medium |
| 26c | Two independent network paths | If a device is involved, it can reach the internet via two paths with no common failure mode (e.g. facility Wi-Fi and cellular) | High |
| 26d | On-prem / cloud separation | Emergency access for on-premises and for cloud are distinct, with no dependency either way | High |
| 27 | Last test | Documented, with the result | High |
| 28 | Credential rotation | After every use, and on a schedule | Medium |
| 29 | Access review | Accounts covered by a recurring access review | Medium |
| 30 | Restricted management AU | Accounts placed in a restricted management administrative unit | Medium |
| 31 | Leaver process | Anyone holding a credential fragment is covered by offboarding | High |
On #26 — untested break-glass is the most common real-world failure. Accounts sit for three
years, then during an actual incident the password is wrong, the FIDO2 key is
unregistered, the account was caught by a CA policy added last year, or the safe key is
missing. The test must be an actual successful sign-in, and it must confirm the alert
fired.
Output shape
- Summary — how many of the 31 checks pass, fail, or were not stated.
- Critical gaps — each with the mechanism by which it causes tenant loss.
- Full checklist table — Pass / Fail / Not stated, with a note per row.
- Remediation plan — in execution order.
- Test procedure — a concrete script for the next scheduled test.
- What needs tenant verification — the checks that cannot be answered in conversation.
Test procedure the agent should hand over
- Schedule the test and notify the security team, so the alert is expected.
- Sign in with break-glass account 1 from a clean browser session.
- Confirm sign-in succeeds and record the method used.
- Confirm the alert fired and reached the intended recipients.
- Confirm the sign-in log shows the account excluded from the CA policies, not merely
passing them.
- Perform a trivial, reversible privileged read to confirm the role is active.
- Sign out; clear the session.
- Repeat for account 2.
- Rotate credentials if the procedure requires it.
- Record: date, tester, result, issues found, remediation, next test date.
Common findings
| Finding | Why it matters |
|---|---|
| Only one break-glass account | No redundancy — one lost credential is total loss |
| Account on the custom domain | Domain failure takes the recovery path with it |
| Account is PIM-eligible | Unusable if the activation path is what failed |
| Both accounts share an MFA dependency | Both fail together in the outage they exist for |
| Exclusion by ordinary security group | Group Administrators can bypass CA or silently remove the exclusion |
| Never tested | Discovered broken during the incident |
| Licensed with a mailbox | Unnecessary attack surface |
| Alerting configured but never verified | Silent failure — nobody learns until it matters |
| Password in the same vault as everything else | Vault compromise takes the recovery path too |
| No documented authorisation procedure | Use is indistinguishable from compromise |