azure
Root cause
Multi-factor authentication is the security control most organizations rely on to protect sign-in. It is also, by design, a hard gate: if the second factor cannot be verified, you do not get in. That property is exactly what makes an MFA outage so brutal. On November 19, 2018, the Azure MFA service failed, and because so many tenants require a second factor at sign-in, users worldwide were locked out of Microsoft 365, the Azure portal, and Azure AD-backed apps.
The root cause was not one bug but three interacting ones. Microsoft's analysis described a latency issue and a race condition in the MFA request path that degraded the service under load. What made the incident so long and so difficult was that a further defect surfaced when the initial fix was applied. Instead of a clean rollback, engineers were peeling apart a layered failure where fixing one problem exposed the next. Impact began around 04:39 UTC.
Recovery was correspondingly slow. Microsoft worked the problems one at a time, reducing load on the MFA service and applying targeted fixes as each defect was understood. MFA success rates climbed step by step rather than in one jump, and the service was not declared fully healthy until roughly 18:39 UTC, about fourteen hours of impact. This event sits alongside the March 2021 Azure AD outage as a pair of identity-plane failures with the same user symptom, being unable to sign in, but different underlying mechanisms.
Business impact
An MFA outage has a cruel property: the very control you added to be more secure becomes the thing that locks you out.
MFA is a hard, all-or-nothing gate. Unlike a degraded service that runs slowly, a failed second factor produces a binary result: you cannot complete sign-in, full stop. For organizations that enforce MFA on everything, which is most security-conscious ones, this meant a near-total access freeze for the affected window. There is a genuine tension here, because turning off MFA to restore access would trade an availability problem for a security one, and that is rarely acceptable.
Redundancy inside your subscription did not help. As with every identity-plane event, running highly available workloads across regions did nothing, because the failure was in the shared authentication path, not in your compute. This is the same lesson the January 2023 network outage taught about the fabric beneath your architecture: some layers are simply not something you can fail over from inside your own tenant.
Existing sessions masked the true blast radius. Users who already held valid tokens often kept working until they needed to re-authenticate, while anyone starting a fresh sign-in was blocked. That split produced the familiar, maddening experience of a service that appeared up for some people and down for others, which slowed help-desk triage and made the outage harder to reason about.
Prevention and lessons
You cannot fix Microsoft's MFA service. You can make sure a second-factor outage does not become a total lockout of your own organization.
- Maintain break-glass accounts excluded from MFA and conditional access. Every mature Azure tenant should have a small number of emergency access accounts that can sign in even when MFA is unavailable. Guard them heavily, credentials stored offline, tightly monitored, used only in a real emergency, but have them. They are the single most important defense against an MFA outage.
- Understand your conditional-access failure behavior. Know, before an incident, what happens when the MFA challenge cannot complete under your policies. Test it. The moment to discover your emergency access path is broken is not during a fourteen-hour outage.
- Consider diverse authentication methods. Reliance on a single MFA mechanism concentrates risk. Where appropriate, support multiple factors (authenticator app, FIDO2 keys, and others) so that a problem confined to one path does not lock out everyone. Document the choices in your business-continuity plan.
- Monitor authentication and MFA success as first-class signals. Region status pages under-report identity-plane failures. Track sign-in and MFA success rates directly, correlate them with a live status board, and alert independently of any single application so you learn about a second-factor failure from your metrics, not from a flood of locked-out users.
If an MFA-driven sign-in failure crossed your monthly SLA thresholds, quantify the window with the Azure SLA credit calculator, then package the claim using the Azure credit-claim playbook. For continuous, service-level monitoring that flags identity and MFA failures the instant they begin, Next Signal watches the authentication path so a broken second factor is not the first thing you hear about from your users.