Traditional MFA is failing when users repeatedly bypass it, complain about delays, or abandon it on important accounts. The report points to annoyance, time pressure, and weak adoption across some services as clear warning signs. If a control is easy to ignore, inconvenient to complete, or inconsistent across channels, it will not deliver reliable protection at scale.
When MFA stops being a security control and starts becoming a friction tax
Traditional MFA is not helping when people treat it as an obstacle to work rather than a normal part of access. Repeated pushbacks, help desk complaints, and workarounds usually mean the control is losing user trust. At that point, the organisation is paying for stronger authentication on paper but getting inconsistent protection in practice.
The clearest warning sign is behavioural: if users delay sign-in, approve prompts without attention, or try to avoid protected paths altogether, the control is no longer shaping risk the way it should.
That failure pattern is often worse than simple non-use because it creates a false sense of coverage while preserving the same weak access habits.
What the user experience is telling you about control quality
When MFA adds noticeable delay to high-frequency or time-sensitive workflows, users begin to look for the fastest path through it. If the same person sees different prompts across devices, channels, or applications, they learn that the control is inconsistent and therefore optional in practice.
Another sign is heavy dependence on exceptions: recovery bypasses, temporary exemptions, shared devices, or repeated “just this once” approvals. Those are not isolated usability issues, they are indicators that the authentication design is forcing users and support teams to route around the intended control.
In mature deployments, friction should be predictable and bounded. If the control feels arbitrary, people stop seeing it as a risk control and start seeing it as an interruption.
When bypass behaviour becomes a security signal
Traditional MFA is struggling when bypasses become normalised, because that usually means the environment has shifted from secure authentication to routine exception handling. Users may keep approving prompts out of habit, or they may abandon MFA altogether on the accounts that matter most, which is the opposite of the intended assurance model.
For a deeper look at how attackers exploit fatigue, weak adoption, and bypass opportunities, see the Uber Breach and Microsoft Midnight Blizzard breach. Both show how weak or inconsistent MFA handling can be turned into access.
The practical question is not whether MFA exists, but whether it still changes attacker effort. If it can be bypassed through fatigue, social engineering, or legacy access paths, then it is no longer the barrier the organisation thinks it is.
Risk and Threat Considerations
The main risk is control erosion. A visibly annoying MFA flow creates shadow exceptions, weak adoption, and user habituation, which lowers real assurance even when the policy still says MFA is enforced. Attackers benefit when defenders have trained users to accept prompts without scrutiny or to treat the control as negotiable.
Failure mechanism: Repeated prompts, inconsistent challenge patterns, and bypass-friendly recovery paths push users toward fast approval or alternate access routes, creating a reliable opening for fatigue attacks, social engineering, and legacy-account abuse.
Impact: The organisation keeps the cost and complexity of MFA but loses much of the protection value, especially on high-risk accounts, sensitive apps, and channels where users are most likely to circumvent the control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Addresses authenticator assurance and phishing-resistant sign-in friction. |
| Recommendation — Use phishing-resistant authenticators where MFA fatigue and bypass are recurring. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Directly governs user authentication strength and MFA enforcement for workforce access. |
| IA-5 — Authenticator Management | Covers lifecycle and handling issues that often drive weak MFA adoption or bypass. | |
| Recommendation — Enforce stronger authentication for user access paths with recurring bypass risk. Review authenticator handling and remove exception paths that undermine MFA. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Covers operational control of access methods and exception handling around authentication. |
| Recommendation — Tighten access exceptions and reduce bypass-friendly sign-in paths. | ||
| ISO/IEC 27001:2022 | A.5.17 — Authentication information | Applies to protection and management of authentication information behind MFA flows. |
| Recommendation — Protect authentication factors and remove weak handling that enables workarounds. | ||
Practitioner Guidance
What to verify: Look for accounts, applications, and channels where MFA is selectively bypassed or where challenge completion drops sharply under time pressure. Those are the places where the control is least trustworthy, even if compliance reporting still looks healthy.
Decision rule: If users are regularly abandoning MFA on important accounts, treat that as a control-design problem, not a training problem. The fix is usually to reduce unnecessary prompts, remove inconsistent recovery paths, and raise assurance only where the risk actually justifies the friction.
Practitioner takeaway: The warning sign is not that users dislike MFA, it is that they have found a reliable way to work around it. Once that happens, the control is no longer improving assurance in proportion to the friction it creates.
Related resources from NHI Mgmt Group
- What are the signs that an MFA deployment is creating usability and support problems?
- How should security teams replace traditional MFA without creating new access friction?
- What are the signs that password-based access is creating avoidable operational and security problems?
- What are the warning signs that MFA is creating too much friction?