Why does MFA still fail in organisations that already use it widely?

Why This Matters for Security Teams

MFA is widely deployed, but wide deployment is not the same as resistant deployment. Attackers target the weakest enrolled method, the recovery path, or the application that never joined the policy in the first place. That is why organisations with “MFA on” still experience account takeover, especially when SMS OTP, push fatigue, or help desk resets remain available. NIST Cybersecurity Framework 2.0 treats access control as an ongoing operational discipline, not a one-time configuration choice.

For NHI Management Group, the failure pattern is familiar: the control exists, yet the identity journeys most exposed to abuse are left with exceptions. The Microsoft Midnight Blizzard breach showed how identity abuse can succeed even in mature environments, while the JetBrains GitHub plugin token exposure illustrates how one compromised pathway can cascade into broader access. In practice, many security teams discover MFA weakness only after a phishing kit, session theft, or help desk abuse has already converted a valid login into a breach.

How It Works in Practice

MFA fails when the assurance level does not match the threat. A phishable factor can still be bypassed by adversary-in-the-middle kits, token theft, or social engineering of recovery flows. A resilient programme therefore focuses on coverage, factor strength, and exception management together. Guidance from the NIST Cybersecurity Framework 2.0 supports this broader view: identity controls need to be measured across enrolment, authentication, and recovery, not just at sign-in.

Practically, mature teams reduce exposure by combining several measures:

• Prefer phishing-resistant methods such as FIDO2 or passkeys over SMS OTP and basic push approval.
• Apply MFA consistently to SaaS, VPN, admin consoles, and high-risk recovery paths.
• Remove silent exceptions for service desks, legacy apps, and “temporary” bypasses.
• Review session duration and token reuse so a successful MFA event does not become a long-lived foothold.
• Use risk-based prompts carefully, because inconsistent challenge logic can create predictable bypass paths.

NHIMG research on The State of Secrets in AppSec also shows the operational gap behind many access failures: organisations can invest heavily in controls while still struggling with fragmented enforcement and slow remediation. When attacker dwell time is shorter than policy change cycles, MFA becomes a speed bump rather than a barrier. These controls tend to break down when legacy apps and help desk workflows remain outside central enforcement because those paths become the easiest route around stronger authentication.

Common Variations and Edge Cases

Tighter MFA enforcement often increases user friction and support load, requiring organisations to balance phishing resistance against business continuity. That tradeoff is real, especially where frontline staff, contractors, or partner access depend on older systems. Best practice is evolving, but current guidance suggests that exceptions should be time-bound, approved, and monitored rather than treated as permanent policy variants.

Edge cases matter most in recovery and delegated access. If password reset, account unlock, or device re-enrolment uses weaker checks than primary authentication, attackers will simply shift to those workflows. The same problem appears with shared admin accounts, service accounts, and break-glass access, where MFA may be impossible or inconsistently applied. For that reason, many programmes pair MFA with stronger identity proofing, device posture checks, and privileged access management rather than relying on a single factor alone.

NHIMG’s research on DeepSeek breach underscores another edge case: when secrets or credentials are exposed, attackers move quickly, and MFA cannot compensate for already compromised trust material. Organisations should treat MFA as one layer in a broader identity resilience programme, not as proof that access is secure by default.

Related resources from NHI Mgmt Group

• Why do AiTM attacks still matter if organisations already use MFA?
• Why do smart cards still matter when organisations already use MFA?
• Should organisations still use one-time passwords for MFA?
• Why do passwordless rollouts still fail when organisations use temporary access passes?