The whole point of a break-glass account is that it works when everything else does not. If a Conditional Access policy misfires, an identity provider goes down, or MFA becomes unavailable, the emergency account is how you get back in. Which is exactly why it is deliberately excluded from the policies that could otherwise lock it out — and why that exclusion, more than any other, has to be correct, owned, and reviewed.
This guide covers how to review the Conditional Access exclusions that protect break-glass accounts: confirming only the intended accounts are covered, checking group membership where a group is excluded, recording ownership and justification, and producing dated evidence — without changing any policy. For the general process across all exclusion types, see how to review Conditional Access exclusions.
What a break-glass or emergency-access account is
Microsoft's term is emergency access account; "break glass" is the scenario it is used for. Microsoft recommends creating "two or more emergency access accounts," used "only for emergency or 'break glass' scenarios where normal administrative accounts can't be used" (Microsoft Learn, checked 18 September 2026). The two terms are interchangeable in practice; this article uses both, because you will see both in your own documentation and in the portal.
These accounts are typically highly privileged (Microsoft's guidance uses the Global Administrator role), cloud-only on the .onmicrosoft.com domain, not federated or synchronised, and protected by phishing-resistant authentication that differs from normal admin accounts. Microsoft also advises against tying them to a single individual: "Don't associate emergency access accounts with any individual user in the organization." That property — deliberately not owned by one person — is what makes recorded ownership at the team level so important.
Why Conditional Access exclusions are relevant
An emergency account is only useful if it can sign in during the emergency. A Conditional Access policy that requires MFA, a compliant device, or another control could block the account "during the exact emergency scenarios it's designed for" (Microsoft Learn, checked 18 September 2026). Microsoft's instruction is direct: "Exclude emergency access accounts from Conditional Access policies that block or restrict sign-in."
This creates a deliberate tension. The account is your most privileged, and you are intentionally removing it from your controls. That is defensible only if the exclusion is precise, documented, owned, and monitored. Microsoft's deployment guidance lists emergency access or break-glass accounts as the first accounts to exclude "to prevent lockout due to policy misconfiguration" (Microsoft Learn, checked 18 September 2026) — and reviewing that exclusion is the control that keeps it honest.
Direct user exclusion versus a dedicated group
There are two ways to exclude an emergency account, and Microsoft has a clear preference.
- Direct user exclusion. The account is named on each policy's exclude list. Simple, but it has to be repeated on every relevant policy, and it is easy to add a new blocking policy later and forget to exclude the account.
- Dedicated exclusion group. Microsoft recommends: "Create a dedicated security group for your emergency access accounts, such as EmergencyAccess, and exclude this group from Conditional Access policies that block or restrict sign-in" (Microsoft Learn, checked 18 September 2026).
The dedicated group is the more robust pattern, but it introduces the classic group-exclusion risk: the exclusion follows the group's membership, not a fixed account. If the wrong account is added to that group, it silently inherits the exclusion from every policy the group is excluded from. If the emergency account is accidentally removed, it silently loses that protection. So whichever pattern you use, the review question differs: for a direct exclusion, confirm the account; for a group exclusion, confirm the group's membership.
What should be reviewed
A break-glass exclusion review is a focused version of a general exclusion review. The essentials:
| Check | What you are confirming |
|---|---|
| Coverage | Only the intended emergency accounts are excluded — no extra accounts have crept in |
| Group membership | If a group is excluded, its current members are exactly the emergency accounts |
| Scope | The exclusion is present on the policies that would otherwise block or restrict sign-in |
| Ownership | A named team owns these accounts and their exclusions |
| Justification | The operational reason and approver are recorded |
| Review date | When the exclusion was last confirmed, and when it is next due |
Verify only intended accounts are covered
The first and most important check is negative: confirm that nothing extra is excluded. An emergency-access exclusion is a powerful exemption, and it is tempting for an administrator under pressure to reuse the same exclusion group for a convenience case. Reconcile the excluded set against your known, intended list of emergency accounts, and treat anything else as a finding to investigate — not as an approved exclusion.
Because Microsoft recommends only two or more emergency accounts, the intended list is short and easy to hold in your head. That is an advantage: a break-glass exclusion covering five accounts, or an account you do not recognise, is immediately suspicious.
Check group membership where a group is excluded
If you followed Microsoft's recommended EmergencyAccess-style group pattern, the review becomes a membership check. Expand the excluded group to its effective membership — including any nested groups, since Conditional Access applies to nested users and groups (see how group and nested-membership exclusions work) — and confirm it contains exactly the emergency accounts and nothing else.
Two failure modes to look for:
- Extra members. Any non-emergency account in the group is excluded from every policy the group is excluded from. That is a real exposure, not a paperwork issue.
- Missing members. If an emergency account is not in the group, it is not protected by the group's exclusion, which defeats the pattern. During an outage, that is discovered at the worst possible moment.
Record who owns the group's membership. It is frequently a different person from whoever owns the Conditional Access policies, and that split is where mistakes hide.
Record owner and operational justification
Because Microsoft advises not tying emergency accounts to one individual, ownership must be recorded at the team or role level — the group responsible for the accounts and their exclusions, not a single person who might leave. Alongside the owner, record the operational justification in plain words: these accounts are excluded from blocking policies so they remain usable during a Conditional Access or authentication outage.
This matters for auditability. Microsoft notes that "organizations in regulated industries might need to demonstrate that the use of emergency access accounts is properly governed," and that monitoring and validation practices support that (Microsoft Learn, checked 18 September 2026). A recorded owner and justification is part of demonstrating governance — while remaining evidence, never a compliance certificate.
Record approver, reference and review date
An emergency-access exclusion should carry the same durable context as any other exclusion, plus a little more rigour given the privilege involved:
- Approver — who signed off that these accounts are excluded from blocking policies.
- Reference — the design decision, runbook, or change record that established the pattern.
- Review date and next-due date — when the exclusion was last confirmed against the intended account list.
Conditional Access stores none of this on the policy, so the review record is where it lives. Microsoft's own suggestion is to "maintain an out-of-band registry" mapping policies to a responsible team (Microsoft Learn, checked 18 September 2026); your break-glass exclusion record is part of that registry.
Review after Conditional Access changes
Point-in-time correctness is not enough, because new policies are added over time. Every time you create a policy that blocks or restricts sign-in, the break-glass accounts need to be excluded from it too — and it is easy to miss one. Microsoft builds this into its deployment checklist: "Before deploying any policy ... verify emergency access accounts are excluded from all policies" (Microsoft Learn, checked 18 September 2026).
Make an exclusion re-check part of your change process for any new blocking policy, and run a full break-glass exclusion review after any significant Conditional Access change, not only on the calendar. The dedicated-group pattern helps here: exclude the group once per policy, and adding a policy is the only step that needs the check.
Report-only policies and emergency access
Not every policy needs the exclusion. Microsoft is specific: "Report-only policies don't block access and don't require an exclusion" (Microsoft Learn, checked 18 September 2026). A report-only policy is evaluated but not enforced — "during sign-in, the system evaluates policies in report-only mode but doesn't enforce them" (Microsoft Learn, checked 18 September 2026) — so it cannot lock an account out.
For your review this means: focus the coverage check on enabled policies that block or restrict sign-in. A report-only policy that lacks the break-glass exclusion is not a gap, though many teams exclude the accounts there too for consistency, so the exclusion is already in place when the policy is switched on. Record the policy state either way, so the review shows you considered it deliberately.
Monitoring and periodic validation
Reviewing the exclusion is one half; Microsoft pairs it with monitoring and validation, which sit outside the exclusion review but belong in the same governance story:
- Monitor sign-ins. "Monitor all sign-in and audit log activity for emergency access accounts with alerts to detect unnecessary or unauthorized use." Any sign-in outside a drill or genuine emergency warrants a post-mortem.
- Validate regularly. "Validate account functionality at least every 90 days," and "regularly test (for example, every quarter) that emergency access accounts can sign in successfully with your current Conditional Access configuration" (Microsoft Learn, checked 18 September 2026).
That 90-day validation is a good anchor for the exclusion review too: when you test that the account can still sign in, confirm at the same time that its exclusions are still correct and still owned.
What CertPilot can inventory
CertPilot's free audit supports the review half of this work. You export your Conditional Access identity exclusions locally with a read-only PowerShell script, open the file in a browser workbench, and can review emergency-access exclusions against your intended account list — confirming coverage, expanding excluded group membership, and recording ownership, justification, approver, and review date as local approval information.
It produces deterministic findings and JSON, CSV, or PDF evidence, all in the browser tab. Nothing in the export is uploaded to CertPilot, nothing is saved automatically, and the browser does not connect to Microsoft. For evidence that belongs in a shared workspace, the follow-ups from this review fit naturally into CertPilot's Access Reviews register.
What CertPilot cannot prove about effective sign-in
The boundary is important, and doubly so for break-glass accounts, where a false sense of security is dangerous.
- It does not prove the account can sign in. An inventory shows the account is excluded from the policies you exported. It cannot prove the account will successfully sign in during an emergency — that requires an actual sign-in test, which Microsoft recommends performing regularly. Exclusion from one policy is not exemption from all; another policy can still apply.
- It is not a security assessment or a compliance certificate. It is a point-in-time identity-exclusion inventory and local approval reconciliation, not effective sign-in evaluation, a vulnerability scan, or certification.
- It does not change anything. No policy edits, no remediation, no score. Adding or removing an exclusion is a deliberate change made in Microsoft Entra.
- Its findings are offline-validated. They were validated against documented Microsoft Graph contracts and synthetic responses, not live Microsoft compatibility proof, and the exporter's read-only permission set is documentation-derived rather than independently verified against a live tenant.
Use the audit to keep the exclusion documented and reviewed; keep Microsoft's regular sign-in test to prove the account actually works.
Frequently Asked Questions
Should break-glass accounts be excluded from Conditional Access?
Yes, from policies that block or restrict sign-in. Microsoft explicitly recommends excluding emergency access (break-glass) accounts so a policy misconfiguration or an authentication outage cannot lock you out of the tenant. Report-only policies do not block access and do not require the exclusion.
Should an emergency account be excluded directly or through a group?
Microsoft recommends creating a dedicated security group (for example, EmergencyAccess) and excluding that group from blocking policies, rather than naming the account on each policy. The group pattern is more maintainable, but it moves the review question to the group's membership: confirm it contains exactly the intended emergency accounts and nothing else.
How often should emergency-access exclusions be reviewed?
Align the exclusion review with Microsoft's validation cadence for these accounts: at least every 90 days, with a sign-in test at least quarterly. Also re-check the exclusion whenever you add a new policy that blocks or restricts sign-in, because emergency accounts must be excluded from all such policies.
Does a break-glass exclusion mean the account can always sign in?
No. An exclusion removes the account from that policy, but effective sign-in depends on all applicable policies and on the account's own health — credentials, authentication methods, and licensing. Microsoft recommends regularly testing that the account can actually sign in with your current configuration; an exclusion inventory records the exclusion, it does not prove the sign-in works.