When does MFA create more confidence than it really should?

Why This Matters for Security Teams

MFA is meant to reduce account takeover risk, but it can create a misleading sense of assurance when teams equate “more factors” with “meaningful resistance.” A weak second factor, such as SMS, email, or poorly protected push approval, may still be bypassed through phishing, interception, or session theft. That matters because security programs often treat MFA as a checkbox, while attackers treat it as one layer to work around.

The practical lesson is that factor strength, enrollment assurance, and recovery paths matter as much as the presence of MFA itself. NIST’s guidance in the NIST Cybersecurity Framework 2.0 reinforces that identity controls should be implemented as part of a broader risk reduction strategy, not as a standalone guarantee. Real-world incidents such as the JetBrains GitHub plugin token exposure and the Microsoft Midnight Blizzard breach show how quickly access can be abused when trust in a single control outruns the actual threat model.

In practice, many security teams discover MFA weakness only after an account has already been phished, enrolled incorrectly, or used to pivot into higher-value systems, rather than through intentional testing.

How It Works in Practice

The first step is to separate “MFA is enabled” from “MFA is resistant to realistic attack paths.” That means examining how the second factor is issued, how it is approved, and how it can be recovered if a user loses access. SMS codes and email links are convenient, but they are not strongly phishing-resistant. Push-based MFA can also create false confidence if users are trained to approve prompts reflexively or if attackers trigger push fatigue. The State of Non-Human Identity Security is relevant here because it shows how often organisations underestimate identity risk when controls exist on paper but fail operationally.

Practitioners should evaluate MFA across three dimensions:

• Factor type: prefer phishing-resistant methods such as FIDO2/WebAuthn over OTPs where possible.
• Enrollment strength: verify how the factor is bound to the right user and device.
• Recovery workflow: review reset paths, help desk processes, and backup codes for bypass risk.

Good practice also includes conditional access, device posture checks, and logging that can detect impossible travel, anomalous sign-ins, and repeated factor prompts. The goal is to reduce the chance that a compromised password plus a weak second step becomes “good enough” for an attacker. Current guidance suggests that MFA should be treated as part of an identity assurance stack, not as proof that access is truly trusted. These controls tend to break down in environments with legacy protocols, shared accounts, or unsupported applications because the strongest factor is often bypassed for compatibility.

Common Variations and Edge Cases

Tighter MFA policy often increases user friction and support overhead, requiring organisations to balance stronger assurance against operational disruption. That tradeoff is especially visible in call centers, contractor-heavy environments, and third-party integrations where users may resist stronger prompts or where systems cannot easily support modern factors.

There is no universal standard for this yet, but current guidance increasingly treats phishing-resistant MFA as the baseline for high-risk access and privileged workflows. For lower-risk populations, organisations may still accept weaker factors temporarily, but they should do so with explicit compensating controls and a documented exit plan. A critical edge case is recovery: even strong MFA can be undermined if an attacker can reset the factor through weak verification channels, shared email access, or help desk social engineering.

This is why MFA should be tested against real attacker behavior, not only policy language. Mature programs measure the resistance of the entire authentication journey, including recovery, step-up prompts, and session reuse. Where account access is tied to sensitive data or administrative privilege, the safer question is not whether MFA exists, but whether it would still hold under phishing, token theft, or identity proofing failure.

Related resources from NHI Mgmt Group

• How should security teams handle app-specific passwords when they use passkeys or MFA?
• Why do strong passwords still need MFA for school and family accounts?
• Why do MFA controls fail against reverse-proxy phishing?
• Why do cloud IAM controls matter even when MFA is in place?