How can organisations tell whether MFA fatigue is becoming a control problem?

Look for repeated push prompts, approval rates that rise after multiple challenges, and privileged users receiving the same friction as low-risk users. Those signals show the authentication experience is conditioning unsafe behaviour. The control is failing when volume, not context, drives approval.

Why This Matters for Security Teams

mfa fatigue is not just an authentication nuisance. It is a signal that the control is being trained into submission. When users are repeatedly challenged, they begin to approve prompts reflexively, and that behaviour can turn a defensive layer into a predictable bypass path. NIST Cybersecurity Framework 2.0 treats identity assurance and access control as ongoing risk functions, not one-time setup tasks, which is why prompt volume and user response patterns matter as much as policy design.

For NHI Management Group, the same pattern that weakens human MFA also shows up when organisations over-rely on static controls for dynamic risk. In breach writeups like the Microsoft Midnight Blizzard breach and the Uber Breach, the common failure is not simply that authentication existed, but that attackers could exploit behavioural weakness, alert fatigue, or approval habits once trust signals were exhausted.

Security teams should treat repeated push traffic, rising approval rates, and complaints from privileged users as control telemetry, not just user-experience noise. In practice, many security teams encounter MFA fatigue only after an attacker has already learned which accounts will approve under pressure.

How It Works in Practice

The first step is to measure whether MFA is functioning as a contextual control or just a repeated interruption. A healthy control should show prompts tied to specific risk events, such as new device use, unusual geo-location, impossible travel, or privileged actions. A failing control shows high prompt volume without corresponding risk, and approval rates that increase as challenges repeat.

Practitioners should segment by user type and access level. Privileged users, admins, and helpdesk operators should not receive the same friction profile as low-risk users if the organisation has stronger policy signals available. This is where identity governance, conditional access, and real-time risk evaluation need to work together. The NIST Cybersecurity Framework 2.0 supports that approach by emphasising continuous monitoring, protective controls, and response adjustment based on observed behaviour.

Useful indicators include:

• Repeated push notifications to the same user in a short window
• Approval spikes after a burst of denied or ignored prompts
• Privileged users approving prompts outside business hours without incident review
• Helpdesk resets or exception requests that rise after MFA friction increases
• Users who begin approving before verifying the session context

For identity-heavy environments, the lesson from NHI governance is familiar: control quality depends on lifecycle discipline. The Ultimate Guide to NHIs — Standards is useful here because it frames identity risk as a matter of visibility, rotation, and revocation, not just initial enrollment. The same operational mindset helps teams see MFA fatigue as an exposure trend, not a usability complaint.

When the approval rate rises because the person is tired, distracted, or conditioned to comply, the control is no longer verifying intent. These controls tend to break down when organisations use uniform MFA policies for all users and all sessions because the signal becomes too noisy to separate malicious prompting from normal work.

Common Variations and Edge Cases

Tighter MFA enforcement often increases user friction, requiring organisations to balance stronger assurance against productivity and support load. That tradeoff is real, and current guidance suggests the answer is not simply “more prompts,” but better context and fewer unnecessary challenges.

One common exception is legacy access paths. VPNs, shared workstations, and older SaaS integrations can produce repeated prompts that look like fatigue but are really architecture problems. Another edge case is high-volume operational roles, where users legitimately authenticate many times per day. In those environments, approval rates alone are not enough; the control must be evaluated against session risk, device trust, and privilege level.

There is also no universal standard for what constitutes an unsafe MFA fatigue threshold. Best practice is evolving toward combining user behaviour analytics, conditional access, and phishing-resistant methods for sensitive accounts. Where possible, organisations should reduce reliance on push approvals for privileged access and move to stronger factors or step-up controls tied to session context.

The practical test is simple: if an attacker can predict when users will approve without scrutiny, the control is already losing. Teams should use the issue as a trigger to reassess alerting, enrollment, and escalation paths before the behaviour becomes normalised.

Related resources from NHI Mgmt Group

• How can organisations tell whether support automation is still under human control?
• How can organisations tell whether MFA enforcement is actually consistent across identities?
• How can organisations tell whether their MFA programme is actually strong enough?
• How can organisations tell whether MFA recovery is too permissive?