Common signs include a burst of push requests, approvals that happen after several denials, unexpected enrolment of a new device, and suspicious sign-ins that align with user distraction or help desk impersonation. Security teams should treat these as correlated indicators of pressure-based authentication abuse, not isolated login events.
How MFA fatigue shows up before an account is taken over
mfa fatigue is a pressure tactic, so the earliest signs are behavioural patterns rather than a single failed login. Look for repeated push prompts in a short window, approval after several denials, and sign-in attempts that keep coming from the same account or source path. The pattern matters more than any one prompt.
Teams should pay attention to timing as well. Attackers often combine repeated prompts with distraction, after-hours activity, or a parallel call to the help desk so the user is nudged into approving something that would normally feel suspicious.
Signals become stronger when the prompts are paired with a second change in state, such as a new device enrolment, recovery method change, or a fresh session from an unusual location. That combination suggests the actor is trying to convert nuisance into durable access.
What distinguishes MFA fatigue from normal authentication noise
Normal MFA activity is usually sparse, user-initiated, and tied to a clear action such as a login, device change, or reauthentication. MFA fatigue looks different because it is repetitive, coercive, and often detached from any legitimate user action. The objective is to overwhelm judgement, not to defeat the factor cryptographically.
In practice, that means a burst of push requests should be correlated with other identity evidence, not treated as a stand-alone alert. A clean device, a known location, and a single approval event may be routine. Multiple prompts, a string of denials, and a sudden acceptance are the combination that should raise confidence.
It also helps to distinguish this from benign authentication friction. If the user reports device loss, app migration, or a planned enrolment change, the event may have an ordinary explanation. If the user denies any request and still receives a successful approval, the event deserves immediate review.
Why repeated prompts often lead to secondary identity abuse
MFA fatigue is rarely the end goal. It is usually an initial access tactic that opens the door to session theft, help desk impersonation, or account recovery abuse. Once an attacker gets one approval, they may pivot quickly to adding a device, changing recovery factors, or stealing an active session before the user realises what happened.
For a real-world example of how this pressure tactic can be combined with other access abuse, see Uber breach 2022. The important lesson is that the MFA event is often only the first visible sign of a broader compromise path.
That is why defenders should review adjacent activity, not just the approval itself. A suspicious prompt followed by a help-desk reset, a new enrolment, or a token/session change is more meaningful than any one event on its own.
Risk and Threat Considerations
MFA fatigue is dangerous because it targets human decision-making at the exact moment a control is supposed to be protective. Repeated prompts can train users to approve reflexively, and once one factor is accepted the attacker may gain enough trust to reset credentials, register a new device, or hijack an active session.
Failure mechanism: The attacker forces a flood of push notifications, then uses timing, distraction, or impersonation to obtain one approval and move into recovery, enrolment, or session takeover.
Impact: A single mistaken approval can become durable account access, and in higher-privilege accounts it can expose email, VPN, admin consoles, or downstream systems that depend on the compromised identity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers MFA prompt handling, credential lifecycle, and factor changes. |
| IA-2 — Identification and Authentication (Organizational Users) | Applies because repeated prompts and approvals are user authentication events. | |
| IA-9 — Service Identification and Authentication | Supports evaluation of session and device trust when access is established after a fatigue event. | |
| Recommendation — Tighten authenticator lifecycle controls and monitor unusual factor changes. Require stronger user authentication and review abnormal approval patterns. Authenticate and monitor non-human access paths that may follow compromise. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Repeated push approval abuse is a form of weak authentication handling for digital identities. |
| NHI-07 — Long-Lived Secrets | Fatigue often aims to convert a transient approval into durable access material. | |
| Recommendation — Harden authentication flows against approval abuse and prompt flooding. Reduce standing access and rotate credentials that outlive the approval event. | ||
| MITRE ATT&CK | T1621 — Multi-Factor Authentication Request Generation | Directly covers adversary use of repeated MFA requests to induce approval fatigue. |
| T1110 — Brute Force | Covers repeated attempts against authentication workflows, including pressure-based abuse. | |
| T1556 — Modify Authentication Process | Useful where attackers add recovery methods or alter sign-in flow after a fatigue approval. | |
| Recommendation — Detect repeated MFA request generation and investigate user pressure campaigns. Alert on repeated authentication attempts that cluster around the same account or user. Look for post-approval changes to authentication or recovery paths. | ||
| CIS Controls v8 | CIS-5 — Account Management | Relevant because the attack often relies on account enrolment, recovery, and session changes. |
| Recommendation — Review account and recovery changes when MFA fatigue indicators appear. | ||
Practitioner Guidance
What to verify: Correlate push volume, approval timing, device-enrolment events, and help-desk contacts before deciding whether the alert is isolated noise. If the user reports repeated prompts they did not initiate, treat the identity as actively pressured until proven otherwise.
Decision rule: If the same account shows repeated denials followed by one approval, prioritise session review, factor reset, and recent enrolment changes over simple password reset. If the account is privileged or can reach sensitive systems, escalate immediately rather than waiting for more evidence.
What good looks like: Users can recognise pressure-based prompts quickly, help desks verify enrolment or recovery requests with stronger checks, and security teams can see the full chain from prompt burst to any new device or session creation.
Practitioner takeaway: The key judgement is to treat MFA fatigue as an access-path attack, not an isolated notification problem, because the real risk appears when the pressure event is linked to enrolment, recovery, or session creation.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org