Why do weak MFA deployments still lead to major breaches?

Why This Matters for Security Teams

Weak MFA is not just an authentication issue. It becomes a breach issue when attackers can ride the gap between secure design and messy enforcement. Prompt fatigue, token replay, code interception, and inconsistent application coverage all give adversaries a path around the factor without ever “breaking” it. That is why incidents tied to identity abuse often look like policy failures, not password failures.

NHIMG’s The 52 NHI breaches Report shows how often identity controls fail once real attacker pressure meets operational drift. The same pattern appears in broader identity research and in Anthropic’s report on AI-orchestrated cyber espionage, where automation amplifies credential abuse and speeds up abuse chains. MFA can still be part of a strong control stack, but only if it is enforced consistently across every access path, not just the primary login screen.

In practice, many security teams encounter the breach only after an attacker has already authenticated through an approved workflow that no one had tested end to end.

How It Works in Practice

Strong MFA should reduce the value of stolen credentials, but weak deployments often leave alternate paths open. The control may exist for employees while service accounts, legacy portals, mobile apps, VPNs, or administrative consoles remain on weaker exceptions. Attackers look for the least resilient path, not the most visible one, and they chain social engineering with session theft, push bombing, or OAuth consent abuse when needed.

The operational question is not whether MFA is enabled, but whether it resists real adversary behavior. Current guidance from NIST on digital identity and zero trust suggests that authentication should be paired with risk-based policy, phishing-resistant factors, and continuous evaluation of session trust. That means security teams should test for:

• Push fatigue and accidental approval under pressure
• SIM swap, OTP interception, and help desk reset abuse
• Exception paths for privileged users and third-party access
• Legacy protocols that bypass modern MFA entirely
• Session hijacking after the factor has already been satisfied

For NHI-heavy environments, the lesson is even sharper. Credentials used by machines, agents, and automation flows can be just as exposed as human logins, which is why NHIMG’s Ultimate Guide to NHIs stresses that identity security fails when controls are not matched to the real workload. Use phishing-resistant methods where possible, reduce standing access, and verify that each application enforces the same policy baseline. These controls tend to break down when organisations retain legacy authentication paths for privileged or third-party users because the exception becomes the easiest route for an attacker.

Common Variations and Edge Cases

Tighter MFA often increases friction, which forces organisations to balance user burden against the security gain. That tradeoff is real, especially in high-velocity environments where aggressive prompts can trigger workarounds, support calls, or approval fatigue. Best practice is evolving toward methods that are harder to misuse and easier to automate safely, rather than simply adding more prompts.

There is no universal standard for every deployment scenario, so teams should treat MFA design as a risk decision, not a checkbox. High-risk cases include help desk resets, break-glass accounts, executives with broad access, and any login flow that can be completed on a managed device without strong device assurance. For those environments, MFA should be paired with conditional access, device posture checks, short-lived sessions, and clear revocation paths. NHIMG’s analysis of the Microsoft Midnight Blizzard breach is a useful reminder that identity controls fail fastest where attackers can persist after initial access.

For teams measuring real resilience, the right question is not “Is MFA turned on?” but “Which paths still succeed when the attacker controls the workflow?” If that answer includes any exception, the deployment is weak enough to matter.

Related resources from NHI Mgmt Group

• Why do still-valid secrets matter after public disclosure?
• What are common vulnerabilities associated with service accounts in AI deployments?
• Why do MFA deployments still leave organisations exposed to identity risk?
• Why do legacy RADIUS deployments create access control risk?