The February 2026 Microsoft 365 MFA Outage: Why Conditional Access Lockouts Happen and How Break-Glass Accounts Save You

The reported failure was isolated to the MFA challenge phase of the Entra ID authentication flow rather than a full outage of sign-in or directory services. Users could reach the authentication prompt, but the backend service responsible for verifying the second factor (push approval, TOTP code, or phone-based challenge) returned 504 Gateway Timeout errors instead of completing verification. Microsoft Entra sign-in logs during the incident window showed failed authentication attempts tied to MFA verification timeouts rather than to bad credentials or blocked risk signals. Conditional Access policies do not have a special case for 'the MFA service itself is unavailable, allow through anyway.' A policy requiring MFA evaluates whether MFA was successfully completed. If it cannot be completed, the policy denies the sign-in. This is deliberate: a Conditional Access engine that failed open (granted access whenever a check could not run) would turn every dependency outage into a trivial authentication bypass. Failing closed is the secure default, and it is also exactly why organizations without an excluded emergency access path had no way into their own tenant for the duration of the incident. The cost of that design choice falls entirely on identity teams that never built an exception for it.

Every Conditional Access policy that requires MFA, compliant devices, or specific network locations was, by definition, enforcing correctly during the outage. The only accounts that stayed usable were accounts explicitly excluded from those policies at the policy level: properly configured break-glass emergency access accounts. This is not a patch or a workaround Microsoft could ship mid-incident. It is a structural gap in the tenant's own configuration, present before the outage started and unaffected by anything Microsoft does to resolve the underlying service issue. Organizations that had never created break-glass accounts, or had created them but left them subject to the same MFA policy as everyone else, had no functional difference between 'admin account' and 'locked-out account' for the duration of the incident. If you have not set up excluded emergency access accounts yet, walk through the full process in our break-glass account setup guide before you need one during the next outage rather than during it.

The first five minutes of any authentication failure should be spent ruling out the two explanations that look identical from the sign-in screen but require completely different responses: a Microsoft-side service issue, or a local misconfiguration. Check Microsoft 365 Service Health (admin center > Health > Service health, or status.office365.com for the public-facing summary) for an active Entra ID or MFA advisory before assuming a local cause. During a genuine service incident, Microsoft posts an advisory identifying the affected service and, eventually, an incident ID and resolution timeline. Cross-reference with Entra ID sign-in logs (Entra admin center > Monitoring & health > Sign-in logs): a Microsoft-side MFA outage typically shows a spike in failure reason codes tied to strong authentication or MFA server timeouts across many users and multiple client applications simultaneously, not a single user or a single app. Compare this against the signature of a local issue: Smart Lockout (Entra ID's built-in brute-force protection) produces the distinct AADSTS50053 IdsLocked error and is scoped to individual accounts after repeated failed attempts, not a broad simultaneous failure. A Conditional Access policy you changed recently and did not fully test will show a specific, named policy blocking a specific, identifiable population, not a timeout error across the board. If failures are broad, simultaneous, span multiple client apps, and correlate with an active Microsoft advisory, treat it as a vendor-side outage and move to the break-glass procedure rather than spending the incident window auditing your own Conditional Access policies.

Once you have confirmed the outage is Microsoft-side, retrieve the break-glass credentials from their physical, offline storage location per your documented procedure. Sign in using the break-glass account through the Entra admin center directly rather than through a client application that may itself depend on the impaired MFA path. Because a correctly configured break-glass account is excluded from the Conditional Access policy that is failing, its sign-in should complete normally even while every other account in the tenant is blocked. Use the regained access to communicate status internally (the break-glass account itself is not a general-purpose admin account and should not be used to perform unrelated administrative work), monitor Entra ID sign-in logs for the scope of impact, and confirm whether any temporary, narrowly scoped Conditional Access adjustment is actually necessary for business continuity versus simply waiting out a Microsoft-side fix. Log out of the break-glass account as soon as the operational need is addressed, and treat the sign-in itself as the P1 alert it should already be configured to trigger: verify your security team received it, even though in this case the cause is known and expected.

The most damaging response to a Conditional Access lockout is disabling or broadly loosening Conditional Access policies tenant-wide in an attempt to restore access faster than the break-glass process allows. This removes MFA enforcement, device compliance requirements, and risk-based blocking for every user in the tenant, not just the administrators who need emergency access, and it does so at the exact moment threat actors are most likely to be probing for organizations with degraded identity controls following a widely reported outage. It also does not reliably solve the immediate problem: if the underlying issue is the MFA verification service itself timing out, and your policy still requires MFA for the newly un-excluded population, users attempting to authenticate through the broken path will still fail. The only accounts that need an exception during this kind of outage are the small number of break-glass accounts built for exactly this scenario. If your organization's instinct during the outage was to reach for a tenant-wide policy disable because there was no working break-glass path, that is the finding to act on afterward, not a justification for repeating it next time.

Break-glass accounts that have never been tested carry an unknown probability of failing exactly when needed. Test on a quarterly or, at minimum, annual cadence, using a documented, low-disruption procedure: notify your SOC of the exact test window and the break-glass account's UPN in advance so the resulting P1 alert is expected rather than triaged as a live incident. Retrieve the credential from physical storage, sign in through the Entra admin center only (not through downstream Microsoft 365 apps), confirm Global Administrator role membership is active and unaffected by any PIM-related change, and confirm the sign-in alert actually reached the security team through a channel that does not depend on Microsoft 365 connectivity, such as SMS or a paging system. Sign out immediately after confirming access; do not use the account for any administrative task beyond the verification itself. This validates the exact recovery path you will use during a real outage without weakening day-to-day security posture, because the account remains excluded from Conditional Access only for itself, not as a template for loosening policy elsewhere. Rotate the credential after every test and update the physical storage record to match.

Three failure patterns account for most break-glass accounts that turn out not to work during a real incident, and all three are detectable before an outage if you test for them specifically. First, the account was never actually excluded from every relevant Conditional Access policy: it may have been excluded from the original MFA policy at creation but missed when a new policy targeting 'All users' or 'All resources' was added later, since Conditional Access exclusions do not apply retroactively to policies created after the account existed. Second, credentials are shared informally, stored in a password manager connected to the corporate network, or known only to one departed administrator, meaning the account cannot actually be accessed the moment normal access methods (including that password manager, if it is cloud-hosted and behind the same identity provider) are unavailable. Third, and most common in tenants that added MFA requirements broadly without auditing exclusions afterward, the break-glass account itself is subject to an MFA requirement, either because it was swept into a new 'require MFA for all users' policy or because a security team enabled per-user MFA on it directly outside of Conditional Access, defeating its entire purpose as an account that must remain reachable when the MFA service itself is unavailable. Any of these three conditions means the account will fail at the exact moment it is needed, and none of them are visible without an actual test sign-in.

Open a Microsoft support case (Sev A / Sev B depending on your support agreement) when: Microsoft 365 Service Health does not yet show an advisory for symptoms affecting multiple users and multiple applications simultaneously, when the advisory exists but your organization's specific impact needs to be documented for internal reporting or SLA purposes, or when sign-in failures persist for your tenant specifically after Microsoft marks the broader incident resolved. Do not escalate to Microsoft when the underlying issue is that your break-glass account was not properly excluded from a policy, its credentials could not be located, or it turned out to require MFA. Those are internal configuration gaps that a support case cannot fix, since Microsoft's side of the system worked as designed. Treat any incident where your team is locked out purely because of a gap in your own break-glass process as an action item for your next internal review, not a vendor ticket: fix the exclusion, correct the credential storage, or remove the erroneous MFA requirement, then schedule a validation test to confirm it.