TL;DR: MFA fatigue attacks flood users with push prompts until one is approved, and Axiad cites Expel data showing 80% of successful business account compromise attacks already occurred in environments with MFA. The real weakness is not MFA itself but push-based trust that assumes users can reliably separate legitimate requests from attacker-driven noise.
At a glance
What this is: This is an analysis of MFA fatigue attacks and why repeated push prompts can turn MFA into a social engineering target rather than a reliable second factor.
Why it matters: It matters because identity teams need controls that reduce prompt abuse, not just more authentication events, especially where human users, MFA policy design, and sensitive application access intersect.
By the numbers:
- 80% of successful business account compromise attacks occurred in environments with MFA in place.
Context
MFA fatigue attacks exploit a human decision point inside the authentication flow. The control still works as designed, but repeated push notifications can condition users to approve a request simply to stop the noise, which turns prompt volume into an attack surface.
For identity programmes, the issue is not whether MFA exists. The issue is whether the organisation relies on push approvals in a way that assumes user attention, patience, and judgement will remain consistent under pressure. That assumption does not hold once an attacker can trigger repeated prompts.
This article is about human identity governance, but the lesson extends to any workflow that uses repeated approval prompts as a security control. When the verification step can be worn down by volume, the programme needs stronger factors and stricter request controls.
Key questions
Q: What breaks when push-based MFA is exposed to repeated notification attacks?
A: The control breaks when approval becomes automatic instead of deliberate. Repeated prompts can condition users to accept one just to stop the noise, which means the second factor no longer proves genuine intent. In that state, the attacker is no longer defeating MFA cryptographically. They are exploiting the approval workflow itself.
Q: Why do MFA fatigue attacks still work when MFA is already deployed?
A: They work because MFA often assumes a legitimate user will distinguish a real prompt from an attacker-generated one. When attackers can trigger repeated notifications, the control becomes a behaviour test rather than a cryptographic barrier, and the human is the weakest part of the chain.
Q: What are the signs that push-based MFA is being abused?
A: Look for repeated prompts, unusual login timing, multiple failed attempts followed by one success, and support calls that reference unexpected authentication requests. Those signals often indicate an attacker is trying to exhaust or confuse the user rather than break the factor directly. Monitoring should tie those events to account risk, not just authentication volume.
Q: Should organisations move from push MFA to phishing-resistant authenticators?
A: Yes, when users protect sensitive applications or are likely to face targeted social engineering. Phishing-resistant authenticators reduce dependence on user reaction during the authentication event, which is exactly where push fatigue attacks succeed. The goal is to remove the attacker’s ability to turn repeated prompts into a usable access path.
Technical breakdown
How MFA fatigue attacks abuse push notification flow
MFA fatigue attacks work by overwhelming the user with repeated approval requests after an attacker already has valid credentials. The attacker is not breaking the MFA protocol itself. Instead, they exploit the human trust layer around it, hoping the user will approve a prompt to make the notifications stop. This is why push-based MFA is vulnerable when it depends on passive user response rather than contextual verification. The attack becomes more effective when users are trained to expect frequent prompts or when organisations do not rate-limit retries and do not correlate prompts with suspicious login behaviour.
Practical implication: reduce prompt volume, constrain retries, and treat repeated approval requests as an alert condition.
Why push MFA fails when users are trained to normalise prompts
Push fatigue succeeds when the authentication experience creates false familiarity. If users see enough legitimate prompts, they stop treating the event as unusual and begin approving without scrutiny. Attackers exploit that habituation by generating a prompt stream that looks operational rather than hostile. The weakness is not the existence of MFA, but the assumption that a user can reliably distinguish routine traffic from malicious traffic in real time. That is why phishing-resistant authenticators matter: they reduce reliance on user judgement during the moment of authentication.
Practical implication: move high-risk populations to phishing-resistant authenticators and remove approval patterns that users can learn to ignore.
Why sensitive applications need stronger step-up controls
A second factor at initial login does not fully contain an account if the attacker can later reach sensitive applications with the same session or trusted posture. MFA fatigue attacks show that initial authentication and application access decisions should not be treated as the same control. Sensitive resources need stronger step-up logic, especially when the request context changes, the device changes, or the user profile changes. In other words, access policy has to follow the risk of the action, not only the success of the login event.
Practical implication: apply stronger checks at sensitive app access points, not just at sign-in.
Threat narrative
Attacker objective: The objective is to turn a legitimate authentication workflow into an approval slip that grants account access without defeating MFA cryptographically.
- The attacker first obtains valid user credentials through phishing or another credential theft method.
- They repeatedly trigger MFA push requests against the target account until the user is fatigued or distracted.
- The user eventually approves one request, giving the attacker access to the device or account.
- The attacker then uses that access to move into sensitive systems or protected data.
Breaches seen in the wild
- Cisco Yanluowang breach 2022: A password synced to a personal Google account plus vishing and MFA fatigue opened Cisco's VPN; the attacker then abused machine accounts.
- Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Push fatigue is a governance problem, not just a user-awareness problem. The control failure begins when organisations rely on the user to be the final filter between a legitimate prompt and an attacker-generated prompt stream. That design assumes the user can preserve signal detection under repetition, which is not a safe security assumption. The implication is that MFA policy has to be judged by how much attacker-driven noise it tolerates before the control breaks.
Repeated prompts are a trust-exhaustion pattern. The attacker is not only trying to capture one approval, they are trying to degrade the user’s confidence in the authentication channel itself. That makes prompt rate and prompt context part of the risk model, not an operational inconvenience. Practitioners should treat repeated approval traffic as evidence that the control boundary is being actively manipulated.
Phishing-resistant authenticators are the cleanest response to prompt abuse. Once the authentication method depends on a user making a noisy yes-or-no decision, social engineering becomes part of the factor itself. Public key-based authenticators remove much of that decision burden and are harder to coerce with prompt flooding. That shifts the security model away from human reaction time and toward cryptographic proof.
Session trust must shrink when MFA is already under pressure. The article’s point about long sessions, device changes, and weak prompt triggers shows that authentication state can persist longer than it should. That creates a mismatch between the original proof event and the later access decision. Identity programmes should view this as a session governance issue, not only an authentication issue.
From our research library:
- Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.
What this signals
MFA fatigue is best understood as a failure of authentication ergonomics under adversarial pressure. Once users are expected to approve repeated pushes, the organisation has effectively made human patience part of the security control.
The operational signal is simple: if a control can be worn down by volume, it is not strong enough for sensitive access paths. That is why step-up requirements, prompt limiting, and phishing-resistant authenticators belong together in the same programme conversation.
For practitioners
- Reduce MFA request volume Rate-limit repeated push requests, add lockouts after suspicious retry patterns, and alert on bursts that suggest prompt bombing rather than normal user behaviour.
- Adopt phishing-resistant authenticators Prioritise public key-based authenticators for employees who access sensitive systems, so authentication does not depend on users approving noisy prompts.
- Tighten step-up authentication for sensitive apps Require additional verification when users request access to high-value applications, especially after device changes, location changes, or unusual session behaviour.
- Review MFA policy exceptions Reassess policies that allow long sessions, weak prompt triggers, or broad authentication method choice, because each one widens the window for fatigue attacks.
Key takeaways
- MFA fatigue attacks exploit the human approval step, not the cryptography behind MFA, which is why repeated prompts can still lead to account compromise.
- The article shows that successful business account compromise can occur even where MFA is already deployed, which makes prompt design and factor choice central governance issues.
- Reducing prompt volume, tightening access triggers, and shifting to phishing-resistant authenticators are the controls most likely to blunt this attack pattern.
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 CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | SP 800-63B — Authentication | This article is about authentication assurance and user-facing factor choice. |
| Recommendation — Use SP 800-63B to evaluate whether your MFA methods resist prompt fatigue and social engineering. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | MFA fatigue changes how access approval decisions are trusted and enforced. |
| Recommendation — Apply PR.AA-05 to tighten approval logic around high-risk access requests and prompt abuse. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article discusses account access abuse, suspicious changes, and control tightening around user authentication. |
| Recommendation — Review account and authentication policies under CIS-5 to reduce abuse of privileged access paths. | ||
Key terms
- MFA Fatigue Attack: An MFA fatigue attack is a social engineering technique that bombards a user with repeated authentication prompts until they approve one out of annoyance, confusion, or urgency. The attacker usually starts with stolen credentials, then uses the approval flow itself to obtain access.
- Push-based MFA: A multi-factor method that sends an approve or deny notification to a device during login. It is convenient and fast, but that same convenience creates a behavioral weakness when users are asked to make repeated trust decisions.
- Phishing-resistant Authenticator: An authentication factor that cannot be easily replayed, proxied, or tricked into disclosure by phishing. In practice, it uses public key cryptography and binds the authentication response to the legitimate origin and transaction context, reducing the value of stolen passwords or repeated prompts.
Deepen your knowledge
NHI governance, human identity, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or IAM programme maturity, it is worth exploring.
Published by the NHIMG editorial team on June 12, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org