How can teams tell whether MFA is causing approval fatigue?

Why This Matters for Security Teams

approval fatigue is not just a user experience problem. When MFA prompts become too frequent, too repetitive, or poorly timed, people start approving out of habit rather than scrutiny. That creates an opening for prompt bombing, token theft, and social engineering that bypasses the very control meant to reduce account compromise. The risk is especially visible in environments with broad NHI exposure, where identities and secrets already sit under pressure, as described in the Ultimate Guide to NHIs.

Security teams should watch for control friction that is measurable, not anecdotal. A spike in prompts is not automatically a failure, but repeated denials followed by eventual approvals is a strong sign that users are learning the path of least resistance. Guidance from the NIST Cybersecurity Framework 2.0 still points toward reducing avoidable authentication burden while preserving assurance.

In practice, many security teams encounter approval fatigue only after users have already normalised risky tapping behaviour rather than through intentional control testing.

How It Works in Practice

Teams can tell MFA is causing approval fatigue by combining behavioural telemetry with help desk signals. The question is not only whether users are authenticating, but whether the control is forcing repeated decisions that they can no longer evaluate carefully. Current guidance suggests treating the prompt itself as a risk signal when frequency, context, and user response patterns all deteriorate together.

Useful indicators include:

• high prompt volume for the same user, device, or application within a short time window
• multiple denials followed by an eventual approval, especially after repeated prompts
• approvals occurring at unusual hours or from unfamiliar geographies without investigation
• help desk tickets asking how to stop prompts, reset MFA, or bypass verification
• users reporting “MFA spam” or adopting workarounds such as phone silencing or device fatigue

Good analysis also separates legitimate MFA friction from weak policy design. For example, a VPN that triggers prompts on every application switch may be over-authenticating low-risk actions, while a risky sign-in from a new device should still require a strong challenge. NHI Management Group’s research on the Microsoft Midnight Blizzard breach shows why repeated identity pressure points matter: attackers often succeed by exploiting human decision fatigue and weak operational controls, not by breaking cryptography.

Teams should align telemetry with governance controls in the NIST Cybersecurity Framework 2.0 and use that data to refine policies, step-up thresholds, and trusted device handling. The goal is to reduce unnecessary prompts without lowering assurance for genuinely risky events. This guidance tends to break down in legacy SSO stacks and remote access gateways because they lack enough context to distinguish routine access from anomalous behaviour.

Common Variations and Edge Cases

Tighter MFA policy often increases user burden, so organisations have to balance security gains against prompt fatigue, support load, and business disruption. That tradeoff is real, and current guidance suggests there is no universal threshold for how many prompts is “too many.”

Some environments create false positives that look like fatigue but are actually a policy mismatch. Examples include shift workers logging in across multiple time zones, developers using ephemeral cloud environments, or finance teams accessing systems during month-end close. In those cases, repeated prompts may reflect poor session design rather than user resistance. Risk-based authentication, device binding, and longer session lifetimes for low-risk workflows can help, but only when those settings are governed consistently.

Another edge case is deliberate adversary pressure. MFA push fatigue attacks can produce a pattern of denials followed by a single accidental approval, which is why prompt counts alone are not enough. Teams should correlate authentication logs with device posture, location drift, and user reporting channels before deciding whether the issue is fatigue, fraud, or both. As NHI Management Group notes in the Ultimate Guide to NHIs, many organisations still lack full visibility into identity behaviour, which makes this kind of diagnosis harder than it should be.

In environments with highly distributed workforces or shared devices, the same control can behave differently across user groups, so teams should segment by population rather than rely on a single enterprise-wide average.

Related resources from NHI Mgmt Group

• How can IAM teams tell whether agent access is actually safe?
• How can security teams tell whether MFA and SSO are actually reducing ransomware exposure?
• How can security teams tell whether review fatigue is setting in?
• How can IAM teams tell whether phishing-resistant MFA is actually improving security?