A Conditional Access policy requiring a compliant device, scoped to All Users, saved at 4:40 p.m. on a Friday. Nothing breaks. The administrator who saved it is already signed in, and the tenant looks fine all evening. On Monday morning the help desk cannot sign in. Neither can the identity lead. Neither can the person who wrote the policy. The servers that enroll devices into Intune are reachable only by an administrator, and every administrator is now on the wrong side of a control they created.
This is the most common self-inflicted outage in Microsoft Entra ID, and it has a fixed remedy — an emergency access account that meets three conditions:
- It was created before the incident.
- It was excluded from the policy before the incident.
- It was tested before the incident.
All three have to be true in advance. There is no way to establish any of them afterward.
Why the lockout is delayed, and why that matters
Conditional Access evaluates at sign-in. An administrator holding a session established before the policy existed keeps working normally, because the token in hand was issued under the old rules. The policy asserts itself when that session needs to be re-established — a new sign-in, a token refresh, a different client. That delay is what makes the failure so consistent. The person best placed to notice the mistake is the person least likely to be prompted by it, and by the time anyone hits the wall, the session that could have undone the change is gone.
Microsoft's Conditional Access deployment guidance does provide a rollback path. A deleted policy can be restored within a 30-day soft-delete window, and a policy can be disabled rather than deleted. Both operations require an administrator who can sign in. The recovery mechanism and the thing it recovers from share a single dependency, which is precisely why the emergency access account exists outside that chain.
How many accounts, and how they must differ
Microsoft recommends a minimum of two emergency access accounts. Two, not one, for redundancy — a single account can be caught by a credential problem, an expired key, or a safe nobody can open. The accounts must be cloud-only, on the tenant's own onmicrosoft.com domain, with no dependency on a federated identity provider. That is not a stylistic preference. A federated or synchronized account routes authentication through infrastructure that can be down for exactly the same reason the tenant is inaccessible. Microsoft's guidance is explicit that emergency access for on-premises systems and emergency access for cloud services should be kept distinct, with no dependency of one on the other.
The accounts must also not belong to anybody. The documentation states it plainly: do not associate emergency access accounts with any individual user in the organization, and do not connect these accounts with any employee-supplied devices, such as phones. An account whose second factor lives on the identity lead's personal handset is not an emergency access account. It is the identity lead's account with a different name, and it fails when the identity lead leaves, loses the phone, or is unreachable at 2 a.m.
Inside Privileged Identity Management, the Global Administrator assignment on these accounts should be active and permanent rather than eligible. Eligible assignments require an activation step, and activation is one more control that can fail during the emergency.
The 2026 change that invalidates the old playbook
For years the standard advice was to make break-glass accounts password-only and exclude them from everything, on the theory that every additional control is another way to be locked out. That advice is now wrong, and holding to it will produce the outage it was meant to prevent.
Microsoft's mandatory multifactor authentication enforcement applies at the platform level, not through your Conditional Access policies. Phase 1 covered the Azure portal, the Microsoft Entra admin center, the Microsoft Intune admin center, and the Microsoft 365 admin center. Phase 2 began rolling out on October 1, 2025 and extends the requirement to Azure resource management through the command line, PowerShell, the mobile app, REST APIs, client libraries, and infrastructure-as-code tools, for create, update, and delete operations. Read operations are not affected. Workload identities, meaning managed identities and service principals, are not affected by either phase.
Emergency access accounts are affected. Microsoft's documentation is direct about it: break glass or emergency access accounts are also required to sign in with MFA once enforcement begins. Excluding an account from every Conditional Access policy in the tenant does not exempt it, because this enforcement does not run through Conditional Access. The tenant-level postponement option that let organizations defer Phase 2 closed on July 1, 2026.
The supported answer is to give these accounts a phishing-resistant method that satisfies the requirement without tying it to a person. Microsoft names two: a passkey, or certificate-based authentication where the organization already runs a PKI. Both satisfy mandatory MFA. Microsoft further advises that the emergency accounts should not use the same authentication methods as your other administrative accounts, so that a compromise or outage affecting the normal admin method does not take the emergency path with it.
Custody and physical storage
Microsoft's instruction on storage is short: keep credentials in a known secure location available to multiple members of the administration team. Where security keys or smartcards are used, the guidance is to store them in secure, fireproof safes in secure, separate locations. Separate locations, plural — one fire or one flood should not take both accounts.
Note what that phrasing does and does not require. It requires that more than one person can retrieve the credential. It does not, in Microsoft's current text, prescribe splitting a password into halves held by different people. Split custody is a real control and a reasonable one, but it trades availability for oversight: every additional custodian is another person who must be reachable during an outage that may well be happening at 3 a.m. on a holiday. If you adopt it, the number of people who can assemble the credential should be larger than the number you expect to reach on the worst night of the year.
Whatever the arrangement, it needs written procedure and named people. Microsoft's validation checklist includes reviewing and updating the list of individuals authorized to use the credentials, confirming the process is documented and current, and confirming that the administrators and security officers who might need to perform those steps have been trained on them. Safe combinations should be rotated after staff changes.
Monitoring, because the exclusion removes your protection
An account excluded from Conditional Access is, by definition, unprotected by the controls you rely on for everyone else. No device compliance requirement. No location restriction. No sign-in frequency limit. The only compensating control left is detection, and it has to be loud.
Microsoft's security operations guidance for privileged accounts sets the expectation clearly: send a high-priority alert every time an emergency access account is used or changed. Because these accounts are only used in an emergency, monitoring should discover no account activity at all, which makes them unusually easy to alert on. The events worth watching are few:
- Sign-in.
- Account password change.
- Account permission or roles changed.
- Credential or authentication method added or changed.
The implementation pattern in Microsoft's emergency access documentation routes sign-in logs into a Log Analytics workspace and builds an alert rule on the accounts' object IDs, with a static threshold set to greater than zero and a severity of critical. Object ID rather than user principal name, because a rename should not silently break the alert. Zero rather than a rate, because one sign-in is the entire signal. Audit logs matter alongside sign-in logs: an attacker who adds a new authentication method to a dormant break-glass account has done something significant without ever signing in successfully.
Microsoft also expects a review after the fact. After any use of an emergency access account, determine whether the use was authorized and whether the actions taken were appropriate.
The trap: testing the policy is not testing the exclusion
Report-only mode and the What If tool are the two instruments most teams reach for, and neither one proves what administrators believe it proves.
Report-only mode evaluates policies without enforcing them. Grant controls and session controls are not applied, and users are not prompted for multifactor authentication or blocked. That is the point of the feature, and it is also the limit. A report-only result showing your break-glass account as not applied tells you the exclusion logic parsed correctly. It does not tell you the account can complete a sign-in, because nothing was ever required of it. Microsoft's own emergency access guidance draws the line: report-only policies do not block access and do not need to exclude emergency accounts.
The What If tool has sharper edges. It evaluates the parameters you type in, and Microsoft warns that it expects all sign-in parameters to be defined for the evaluation to be accurate. If your policies have conditions and you do not supply the matching sign-in details, those conditions cannot be evaluated. It does not account for Conditional Access service dependencies, so a result for one application can miss a policy that applies to a service it depends on. And for application targeting it wants a specific application ID: groups of apps such as Office 365 or the admin portals do not result in a match. An administrator confirming a break-glass exclusion against an app group is reading a non-result as a pass.
The deeper failure is compositional. Microsoft's deployment guidance says to test the exclusion criteria of a policy directly, because the combination of other policies can still require MFA for users you excluded from one of them. Exclusions are per-policy. Coverage is cumulative. Excluding an account from the compliant-device policy accomplishes nothing if a second policy requiring phishing-resistant MFA from a managed device still catches it.
The group nobody maintains
Most tenants implement the exclusion as a security group rather than by naming accounts, which is the right structure and the most common place it quietly breaks. A group is a pointer. It is correct only as long as somebody maintains what it points at. Accounts get removed during a cleanup of stale objects. A new break-glass account is created after a tenant migration and never added. The group is renamed and a scripted policy deployment recreates a different, empty one.
Dynamic membership makes it worse. Microsoft's guidance on dynamic groups warns that if a dynamic group controls access to sensitive resources, applications, or Conditional Access policies, the security of that access is only as strong as the write controls on the attributes in the rule, because anyone who can edit the attribute can change who is in the group. Microsoft notes that role-assignable groups already prevent this risk by requiring assigned rather than dynamic membership. For a break-glass exclusion, assigned membership on a role-assignable group is the correct shape, and the membership belongs in the same quarterly check as everything else.
An account that has never been tested is a guess
Microsoft's validation cadence is at least every 90 days, plus two event triggers: whenever there is a recent change in IT staff, such as a termination or position change, and whenever the organization's Microsoft Entra subscriptions change. The subscription trigger catches a real failure mode, since licensing changes can alter which features and policies apply.
The test is a sign-in, not an inspection. Validate that the accounts can actually sign in and perform administrative tasks under the Conditional Access configuration currently in force. Tell the security monitoring staff first, so the critical alert you built is understood as a drill rather than an incident, and so you learn whether the alert fires at all, which is the second thing the exercise proves. Confirm that no multifactor or self-service password reset registration has been attached to an individual's device or personal details. Where a device is required for sign-in or role activation, confirm that it is accessible to every administrator who might need it, and that it can communicate over at least two network paths that do not share a common failure mode.
Ninety days is not an arbitrary interval. It is short enough that a tenant's configuration drift stays within the range a single test can characterize. Conditional Access policies get added continuously, often by people who have never heard of the exclusion group, and every one of them is a chance to re-cover the account you deliberately uncovered. The quarterly sign-in is the only thing that closes that gap, and it fails safe: a break-glass test that fails on a Tuesday afternoon costs an hour of remediation, while the same failure discovered during a real lockout costs a support case and a day the business does not have.
