The worst Conditional Access incident is not an attacker getting in. It is every administrator getting locked out because one policy was saved with the wrong setting. A properly built Conditional Access break glass account, plus a disciplined approach to naming and exclusions, is what turns that scenario from a multi-day outage into a ten-minute fix.
This article walks through how I set up emergency access accounts, how to structure exclusions so they don’t become a security hole, and a naming convention that makes your policy list readable at a glance.
How a tenant-wide lockout actually happens
Conditional Access is enforced after the first factor of sign-in, for every user and every app in scope. That is exactly what makes it effective, and also what makes mistakes so expensive. The lockouts I see usually come from one of these:
A “block all countries except ours” policy saved while the admin is traveling, or with the home country left off the list.
A “require compliant device” policy targeting All users and All resources before admin workstations are enrolled in Intune.
A policy requiring phishing-resistant MFA for admins before any admin has registered a passkey.
A federation or MFA service problem that stops every synced or federated account from completing sign-in.
In each case, the only way back in is an account that the broken policy doesn’t apply to, or a support ticket with Microsoft that requires proving tenant ownership. The emergency account is much faster.
Building a Conditional Access break glass account the right way
Microsoft’s guidance is to create two or more emergency access accounts. Here is the checklist I follow:
Cloud-only, on the onmicrosoft.com domain. Create the account on your tenant’s built-in onmicrosoft.com domain, not your custom domain. It must not be synced from on-premises Active Directory or federated, so it keeps working if either of those breaks.
Permanent Global Administrator. Assign the role permanently, not as an eligible Privileged Identity Management assignment that needs activation.
Phishing-resistant, passwordless sign-in. Register a passkey (FIDO2) on a hardware security key. Certificate-based authentication is the alternative if you already run a PKI. Both satisfy Microsoft’s mandatory MFA requirement for admin portals, which a password alone no longer does.
Two keys per account, stored separately. One in an office safe, one with a second trusted person or offsite location. Losing the only key means losing the account.
Not tied to a person. Don’t give it a mailbox or a license that implies someone uses it day to day. Give it a neutral name that doesn’t advertise what it is.
Excluded from every enforced Conditional Access policy that blocks or restricts sign-in. Report-only policies don’t need an exclusion because they don’t enforce anything.
Excluded from SSPR. If self-service password reset is scoped to all users, the account can be forced to register phone methods it should never have. Scope SSPR to a group that leaves the emergency accounts out.
Monitor every sign-in
An emergency account that nobody watches is just an unmonitored Global Administrator. Stream sign-in logs to a Log Analytics workspace and create an alert that fires on any successful or failed sign-in by either account. If you use Microsoft Sentinel or Defender XDR, an analytics rule on the account object IDs does the same job. Every alert should be investigated, even if the answer is “that was our quarterly test”.
Test it on a schedule
Sign in with each account once a quarter. Confirm the key still works, the role is still assigned, and the alert fired. Write the result down. An emergency account that fails when you need it is worse than none, because you planned around it.
Structuring exclusions without creating a back door
Every exclusion is a hole in a policy. The goal is to keep them few, visible and owned.
The pattern that works best is one exclusion group per policy, plus a shared group for emergency accounts:
Group
Members
Used in
Review
CA-Exclude-EmergencyAccess
The two break glass accounts only
Every enforced policy
Quarterly
CA001-Exclude
Temporary exceptions to legacy auth block
CA001 only
Monthly
CA006-Exclude
Users awaiting device enrollment
CA006 only
Monthly
CA-Exclude-SyncAccount
Directory sync service account
All-users policies
Quarterly
Why per-policy groups? Because when someone asks for an exception to the device policy, you add them to CA006-Exclude and nothing else. You never open the policy itself, so you never risk saving an accidental change. And when you review exclusions, each group tells you exactly what the person is exempt from.
Some rules I hold to:
Every exception gets a ticket, an owner and an end date.
Nobody is excluded from the MFA policy except emergency accounts. If someone “can’t do MFA”, fix the method, don’t remove the control.
Protect exclusion groups. Make them role-assignable or restrict who can manage their membership, so a helpdesk account can’t quietly add itself.
Turn on protected actions for Conditional Access changes, so editing or deleting a policy requires a fresh strong authentication.
A naming convention you can read at a glance
Microsoft’s planning guidance suggests that a policy name should show a sequence number, the cloud apps it applies to, the response, who it applies to and when it applies. A simple format:
CA###-[Users]-[Apps]-[Control]-[Condition]
Examples:
CA001-All-AllApps-BlockLegacyAuth
CA002-Admins-AllApps-PhishResistantMFA
CA006-All-Office365-RequireCompliant-WindowsMac
CA020-Guests-AllApps-RequireMFA
Number in blocks so related policies sort together: 001 to 019 for baseline, 020 to 039 for guests, 040 and up for app-specific. Name the matching exclusion group with the same prefix. When you look at a sign-in log and see CA006 failed, you know where to look and which group holds the exceptions.
Also note that Microsoft-managed Conditional Access policies appear in the same list with Microsoft shown as the creator. You can’t rename them, but you can and should add your emergency access exclusion to them.
A pre-change checklist for any Conditional Access edit
Is the emergency access group excluded?
Is the change going into report-only first?
Have I checked the policy impact view or the Insights and reporting workbook for who would be affected?
Am I still signed in in a second browser session in case my own sign-in breaks?
Is there a rollback, with the previous settings saved or the policy exported?
Does someone else know a change is happening?
If you’d like these controls set up properly as part of a broader program, our managed security service includes Conditional Access change control, exclusion reviews and emergency account monitoring. For a one-time review, the Microsoft 365 security assessment checks every policy and exclusion group. Our MFA enablement service handles passkey registration for admin and emergency accounts.
Should the break glass account be excluded from MFA entirely?
Exclude it from your Conditional Access policies, but don’t leave it with a password only. Register a passkey or certificate so the account itself is protected by phishing-resistant authentication. That satisfies Microsoft’s mandatory MFA enforcement for admin portals and keeps the account usable when your policies are broken.
How many emergency access accounts do we need?
Two is the practical minimum, each with its own credentials stored in different places. Larger organizations sometimes keep a third with a different authentication method so a single method failure can’t affect all of them.
Can an exclusion group replace a named location for trusted offices?
No. They solve different problems. Exclusion groups exempt specific accounts; named locations describe networks. Avoid using either to skip MFA for normal users, because both become paths an attacker can use.
Want a second set of eyes on your emergency access setup before you need it? Request a free Microsoft 365 security assessment and we’ll test your break glass accounts, review your exclusions and flag any policy that could lock you out.
The worst Conditional Access incident is not an attacker getting in. It is every administrator getting locked out because one policy was saved with the wrong setting. A properly built Conditional Access break glass account, plus a disciplined approach to naming and exclusions, is what turns that scenario from a multi-day outage into a ten-minute fix.
This article walks through how I set up emergency access accounts, how to structure exclusions so they don’t become a security hole, and a naming convention that makes your policy list readable at a glance.
How a tenant-wide lockout actually happens
Conditional Access is enforced after the first factor of sign-in, for every user and every app in scope. That is exactly what makes it effective, and also what makes mistakes so expensive. The lockouts I see usually come from one of these:
In each case, the only way back in is an account that the broken policy doesn’t apply to, or a support ticket with Microsoft that requires proving tenant ownership. The emergency account is much faster.
Building a Conditional Access break glass account the right way
Microsoft’s guidance is to create two or more emergency access accounts. Here is the checklist I follow:
Monitor every sign-in
An emergency account that nobody watches is just an unmonitored Global Administrator. Stream sign-in logs to a Log Analytics workspace and create an alert that fires on any successful or failed sign-in by either account. If you use Microsoft Sentinel or Defender XDR, an analytics rule on the account object IDs does the same job. Every alert should be investigated, even if the answer is “that was our quarterly test”.
Test it on a schedule
Sign in with each account once a quarter. Confirm the key still works, the role is still assigned, and the alert fired. Write the result down. An emergency account that fails when you need it is worse than none, because you planned around it.
Structuring exclusions without creating a back door
Every exclusion is a hole in a policy. The goal is to keep them few, visible and owned.
The pattern that works best is one exclusion group per policy, plus a shared group for emergency accounts:
Why per-policy groups? Because when someone asks for an exception to the device policy, you add them to
CA006-Excludeand nothing else. You never open the policy itself, so you never risk saving an accidental change. And when you review exclusions, each group tells you exactly what the person is exempt from.Some rules I hold to:
A naming convention you can read at a glance
Microsoft’s planning guidance suggests that a policy name should show a sequence number, the cloud apps it applies to, the response, who it applies to and when it applies. A simple format:
CA###-[Users]-[Apps]-[Control]-[Condition]Examples:
CA001-All-AllApps-BlockLegacyAuthCA002-Admins-AllApps-PhishResistantMFACA006-All-Office365-RequireCompliant-WindowsMacCA020-Guests-AllApps-RequireMFANumber in blocks so related policies sort together: 001 to 019 for baseline, 020 to 039 for guests, 040 and up for app-specific. Name the matching exclusion group with the same prefix. When you look at a sign-in log and see
CA006failed, you know where to look and which group holds the exceptions.Also note that Microsoft-managed Conditional Access policies appear in the same list with Microsoft shown as the creator. You can’t rename them, but you can and should add your emergency access exclusion to them.
A pre-change checklist for any Conditional Access edit
If you’d like these controls set up properly as part of a broader program, our managed security service includes Conditional Access change control, exclusion reviews and emergency account monitoring. For a one-time review, the Microsoft 365 security assessment checks every policy and exclusion group. Our MFA enablement service handles passkey registration for admin and emergency accounts.
Microsoft’s own article on managing emergency access accounts in Microsoft Entra ID is the reference to keep on file.
Frequently asked questions
Should the break glass account be excluded from MFA entirely?
Exclude it from your Conditional Access policies, but don’t leave it with a password only. Register a passkey or certificate so the account itself is protected by phishing-resistant authentication. That satisfies Microsoft’s mandatory MFA enforcement for admin portals and keeps the account usable when your policies are broken.
How many emergency access accounts do we need?
Two is the practical minimum, each with its own credentials stored in different places. Larger organizations sometimes keep a third with a different authentication method so a single method failure can’t affect all of them.
Can an exclusion group replace a named location for trusted offices?
No. They solve different problems. Exclusion groups exempt specific accounts; named locations describe networks. Avoid using either to skip MFA for normal users, because both become paths an attacker can use.
Want a second set of eyes on your emergency access setup before you need it? Request a free Microsoft 365 security assessment and we’ll test your break glass accounts, review your exclusions and flag any policy that could lock you out.