Why does MFA sometimes fail to protect accounts even when it is enabled?

Why This Matters for Security Teams

MFA is often treated as a finish line, but it only reduces risk if the factor resists phishing, replay, and approval fatigue. SMS codes, basic OTP apps, and push prompts can still be captured, proxied, or socially engineered. NIST guidance consistently pushes organisations toward stronger access controls, and the NIST Cybersecurity Framework 2.0 frames identity assurance as part of a broader protection strategy, not a single safeguard.

The practical failure is usually not that MFA is absent. It is that the backend trust model still relies on a reusable secret, a weak recovery path, or a session that can be stolen after login. In real environments, that means attackers can bypass MFA by targeting help desks, token sync workflows, or legacy protocols that sit outside the MFA policy. NHIMG research on Microsoft Midnight Blizzard breach shows how identity compromise often moves through weak trust boundaries rather than direct password guessing. In practice, many security teams discover MFA gaps only after an account has already been used for lateral movement, not during the policy rollout itself.

How It Works in Practice

Effective MFA depends on three layers: the factor itself, the login flow, and the account recovery path. If any one of those layers is weak, the overall control can fail. Phishable factors such as SMS one-time codes or push approvals are vulnerable because the attacker can relay the challenge in real time. Even stronger factors can be undermined if the authenticated session token is stolen, if a legacy protocol bypasses MFA entirely, or if recovery options allow the attacker to reset the factor through email or support workflows.

Security teams should therefore design for phishing-resistant authentication and reduce the number of places where a reusable secret still exists. Current best practice is to pair MFA with:

• FIDO2 or passkey-based authentication for high-value accounts
• Conditional access tied to device posture, location, and risk signals
• Restricted legacy authentication and token-based protocol exemptions
• Strong help desk verification for resets and factor changes
• Short session lifetimes and reauthentication for sensitive actions

Controls like this align with the intent of NIST SP 800-53 Rev 5 Security and Privacy Controls, which treats authentication as part of a wider access control and session management discipline. NHIMG coverage of the DeepSeek breach underscores a related lesson: once credentials or tokens are exposed, policy strength matters less than how quickly the attacker can reuse them. These controls tend to break down in organisations that still allow legacy auth, shared admin recovery, or broad exception handling because MFA enforcement becomes inconsistent across the stack.

Common Variations and Edge Cases

Tighter authentication often increases user friction and support overhead, requiring organisations to balance security gain against operational continuity. That tradeoff matters because not every account warrants the same MFA design. Privileged users, finance teams, and remote admins need stronger factors and stricter recovery than low-risk internal users, but over-restricting access can drive insecure workarounds.

There is no universal standard for this yet, but current guidance suggests treating MFA as a control family with different assurance levels rather than a binary enabled or disabled state. A push-based factor may be acceptable for low-risk collaboration tools, while it is too weak for admin consoles or cloud control planes. Risk also changes when mobile devices are enrolled in MDM, when sign-in occurs from trusted hardware, or when session tokens can be protected with hardware-backed key storage.

One common edge case is shared or service accounts. MFA may be impractical there, so the better control is to remove human use entirely and replace it with managed, non-shared credentials or workload identity. Another edge case is step-up authentication for sensitive actions, where the initial login is not enough and a second, stronger check is required before payment release, privilege elevation, or factor reset. The hardest failures appear in environments with legacy protocols, outsourced support desks, or fragmented identity stacks because MFA coverage becomes uneven and attackers target the weakest exception path.

Related resources from NHI Mgmt Group

• Why do MFA implementations still fail even when a second factor is enabled?
• What breaks when organisations leave stale service accounts enabled?
• Why does partial MFA coverage still leave organisations exposed even when sensitive apps are protected?
• What breaks when organisations fail to remove dormant SaaS accounts after an acquisition?