Break-glass accounts and Conditional Access without locking yourself out

Conditional Access is the most powerful control in Microsoft Entra ID, and the one most able to lock every administrator out of the tenant with a single misconfigured policy: require a compliant device for all users before any device is compliant, block a country that includes your own office, require MFA through an identity provider that's down. Microsoft's answer is procedural rather than technical: keep emergency access accounts that no policy can block, prove every policy in report-only mode before it's enforced, and rehearse. This guide is that procedure, with the settings that make the accounts safe rather than a back door.

Why the accounts exist

An emergency access account is for the day normal administration can't happen: the federated identity provider is down so nobody can sign in; every admin's MFA device is unreachable; the last Global Administrator has left and the account is gone or disabled on-premises; a network outage stops phones; or every privileged role is eligible in PIM with an approval step and no approver left to approve. Microsoft says to keep two or more, used only in an emergency or a drill, and monitored so any other use is noticed at once.

Mandatory MFA applies to them too. That's why the credential has to be one that works without a phone, a person or a network you don't control.

Create the break-glass accounts

Some organisations instead give each administrator a personal emergency account; it adds accountability at the cost of more accounts to protect. Either way, keep the cloud and on-premises emergency access separate, with no dependency between them.

Exclude them, and the right service accounts

Put the accounts in a dedicated security group, for example EmergencyAccess, and exclude that group from every Conditional Access policy that blocks or restricts sign-in. Report-only policies don't block, so they need no exclusion. A policy that requires MFA, a compliant device or a named location can stop the account working during the exact emergency it exists for; the passkey is what protects it instead.

Microsoft's standard exclusion list has two entries, and the second is widely misunderstood:

• Emergency access accounts, as above.
• Service accounts and service principals. Conditional Access policies scoped to users don't apply to service principals and managed identities at all, so "excluding" them from a user policy changes nothing; but a user account used as a service account is in scope and will break. Replace those with managed identities (our mandatory MFA guide walks through it), and govern real service principals with Conditional Access for workload identities, a separate policy type that needs a Workload Identities Premium licence and can block single-tenant service principals by location or risk.

When you create a policy, Entra warns if you're about to include yourself with no exclusion. Heed it: exclude at least one administrator from any new blocking policy until it's proven, and keep the break-glass group excluded for good. If the worst happens, Microsoft's "What to do if you're locked out" guidance starts with these accounts.

Test every policy before you enforce it

1. Create it in report-only mode. The policy is evaluated at every sign-in and the result is logged, but nothing is enforced or prompted. The sign-in log's Report-only tab shows, per sign-in, whether the policy would have succeeded, failed, needed user action (an MFA prompt), or not applied. One caveat: report-only policies that require a compliant device can prompt macOS, iOS and Android users to pick a device certificate; exclude those platforms from report-only compliance checks.
2. Read the impact. The policy impact view on the policy (Security Reader or above) shows a snapshot over 24 hours, 7 days or a month with sample sign-ins; the Conditional Access insights and reporting workbook (Entra ID P1 and a Log Analytics workspace receiving sign-in logs) shows report-only and enforced results side by side for a time range, apps and users. Change an enforced policy the same way: clone it to report-only with the change, compare, then apply.
3. Run the What If tool (Conditional Access > Policies > What If) for the cases that matter: a break-glass account from an unknown location, a service principal, a guest, your own admin account from a personal device. It lists which policies would apply, which wouldn't and why, including policies in report-only mode. Give it the specific app ID and all the sign-in conditions; the current API evaluates exactly what you provide, so an app group such as "Microsoft Admin Portals" doesn't match, and unspecified conditions aren't assumed.
4. Enforce by switching the toggle from Report-only to On, to a pilot group first, then everyone. Conditional Access has no A/B testing; a phased rollout is a small included group that grows.

Alert on every sign-in, and drill quarterly

Alert. Send Entra sign-in logs to a Log Analytics workspace, then create an alert rule in Azure Monitor with a custom log search for the accounts' object IDs, threshold greater than 0, severity 0, with an action group that emails and texts the administrators:

SigninLogs
| where UserId == "<object id of break-glass 1>" or UserId == "<object id of break-glass 2>"
| project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription

Any firing means one of three things, and each needs a short written review afterwards: a planned drill, a real emergency, or misuse.

Drill, at least every 90 days and after any staff change: confirm the authorised list and the written procedure; sign in with each account on the current Conditional Access configuration and perform an administrative task; check no MFA or password-reset method points at an individual's device; check the device or key can reach the internet over two independent networks; and, after someone with access leaves, change the safe combinations. Regulated organisations can use the alert, the review and the drill records as the audit evidence that emergency access is governed.

Keep a contingency policy ready. A disabled Conditional Access policy that restores access for critical users during an identity-provider outage, written and tested in advance, is faster and safer than editing live policies under pressure.

Sources

• Manage emergency access accounts in Microsoft Entra ID, Microsoft Learn (requirements, Conditional Access considerations, the alert rule, validation)
• Plan a Conditional Access deployment, Microsoft Learn (user exclusions)
• Conditional Access: users, groups, agents and workload identities, Microsoft Learn ("Don't lock yourself out")
• Analyze Conditional Access policy impact (report-only mode), Microsoft Learn
• Troubleshoot Conditional Access policies with the What If tool, Microsoft Learn
• Conditional Access for workload identities, Microsoft Learn
• Mandatory multifactor authentication for Azure and admin portals, Microsoft Learn (break-glass accounts are in scope; passkeys satisfy it)