MFA outage or bypass

Detection signals

• Surge in failed MFA challenges or 'code not received' support tickets
• SMS/push provider status page reporting degradation
• Logins completing without the expected second factor (bypass)
• Spike in use of recovery codes or the MFA-reset flow

Likely root causes

• Third-party SMS/push provider outage
• TOTP time-drift or a misconfigured secret
• A fallback or recovery path that skips MFA (bypass)
• Misconfigured policy that made MFA optional

Containment

1. 1Confirm whether this is an availability outage or an authorization bypass
2. 2For an outage: fail over to an alternate factor (TOTP, passkey, backup codes), never disable MFA globally
3. 3For a bypass: disable the vulnerable fallback/recovery path immediately and re-require MFA
4. 4Invalidate sessions created during a confirmed bypass window

Customer communication

• For an outage, post status and tell users which alternate factor to use
• For a bypass, notify affected users and force re-authentication
• Avoid instructions that train users to bypass MFA

Forensics & logging

• Capture which accounts authenticated during the incident window and how
• Preserve MFA challenge and policy-evaluation logs
• Determine whether any account completed login without a second factor

Post-incident hardening

• Offer multiple independent factors so one provider outage is not total
• Prefer passkeys, which do not depend on SMS/push delivery
• Review every recovery and fallback path for MFA-skip gaps

FAQ

Should I disable MFA during an MFA outage?

No, never globally. Fail over to an alternate factor (TOTP, passkey, backup codes) instead. Disabling MFA to fix an availability problem opens an authorization hole an attacker can walk through.

How do I tell an MFA outage from an MFA bypass?

An outage is an availability problem (users can't get codes); a bypass is an authorization problem (logins complete without the second factor). Triage which one you have first, they need opposite responses.