What are the warning signs that MFA is creating too much friction?

High prompt volumes, frequent approval times that look reflexive, rising help desk tickets, and users seeking workarounds all suggest the control is becoming counterproductive. If authentication is repeatedly interrupting low-risk sessions, teams should treat that as a design problem, not user resistance.

Why This Matters for Security Teams

MFA should reduce account takeover risk, but when it adds friction in routine, low-risk access paths, users start optimizing around it. That is not a user training problem alone. It is a signal that the control is being applied too broadly, too often, or at the wrong decision point. In NHI Management Group research, 97% of NHIs carry excessive privileges, which helps explain why strong authentication often becomes the wrong control to lean on when access design is already bloated.

The warning signs usually appear before a breach: more prompts, faster approval clicks, and a steady rise in exceptions. Teams that study incidents like the Microsoft Midnight Blizzard breach see the same pattern repeated: once access becomes cumbersome, people and automation both look for shortcuts. That shifts risk from controlled authentication into shadow workflows, shared sessions, and weaker fallback methods. The real issue is often not MFA itself, but whether it is tuned to session risk and business context.

In practice, many security teams discover mfa fatigue only after users have already normalized bypasses and workarounds.

How It Works in Practice

The most reliable way to judge MFA friction is to look for behaviour change, not just login metrics. If approval volume rises while high-risk events stay flat, the control may be over-triggering. If help desk tickets cluster around specific apps, device types, or user groups, the problem is likely in policy design, not in the users. Current guidance suggests treating MFA as part of an adaptive access model, where step-up challenges are reserved for sessions that genuinely need them.

Security teams should review four signals together:

• Prompt frequency per user and per application
• Average approval time and how often approvals are reflexive
• Exception requests, backup method use, and recovery events
• Workarounds such as shared devices, copied codes, or approval farming

Friction often falls when MFA is paired with better context signals: device posture, location, session risk, and privilege level. The goal is not to remove authentication, but to avoid repeating it when the session already has strong assurance. NIST SP 800-53 Rev 5 Security and Privacy Controls can help teams map that thinking into control design, especially where access review, session monitoring, and least privilege need to work together rather than separately.

For NHI-heavy environments, the same lesson applies to service identities. NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts, which means repeated authentication friction can hide a deeper identity design gap. The relevant question becomes whether the control is proving identity at the right layer, or merely interrupting workflow after access has already been over-granted. These controls tend to break down when every login is treated as equally risky, because users and systems stop distinguishing normal access from suspicious access.

Common Variations and Edge Cases

Tighter MFA often increases operational overhead, requiring organisations to balance stronger verification against user productivity and support load. That tradeoff is especially visible in high-frequency roles, shared operational stations, and incident response workflows where constant re-authentication can delay legitimate work. There is no universal standard for this yet, so best practice is evolving toward risk-based prompts rather than fixed prompt schedules.

Some environments need more aggressive MFA by design, such as privileged admin access, finance approvals, remote access from unmanaged devices, or recovery paths after credential reset. In those cases, friction is acceptable if the protected action is rare and high-impact. But if the same level of challenge is applied to every ordinary session, users begin to bypass it through copy-paste approvals, shared tokens, or repeated login retries. That creates a false sense of security while making true anomalies harder to spot.

Teams should also separate human experience from machine access. What feels like “too much MFA” for a person may signal that the organisation has not differentiated interactive access from automated access. For machine identities, repeated prompts are usually the wrong model altogether; short-lived credentials, workload identity, and policy-based authorisation are typically better suited than human-style challenges. The practical test is simple: if MFA is causing more exceptions than it is preventing risky access, the control is misaligned with the environment.

Related resources from NHI Mgmt Group

• How should small businesses implement MFA without creating too much user friction?
• How should teams implement customer MFA without creating too much login friction?
• How should security teams implement just-in-time access without creating too much friction?
• How should security teams implement context-aware authentication without creating too much user friction?