TL;DR: MFA fatigue attacks exploit repeated push prompts, stolen credentials, and help desk social engineering to turn one approval into full account compromise, with real-world breaches at Uber, Cisco, and MGM Resorts showing the pattern repeatedly, according to 1Kosmos. Push-based MFA stops looking resilient once attackers can convert user exhaustion into authentication success.
At a glance
What this is: This is an analysis of MFA fatigue attacks and the way repeated push notifications turn valid credentials into account takeover.
Why it matters: It matters because IAM programmes that rely on one-tap approvals can fail quietly, while NHI, autonomous, and human identity controls all depend on stronger authentication boundaries.
By the numbers:
- MGM Resorts attack in 2023 showed just how far this can go, with losses exceeding $100 million.
👉 Read 1Kosmos' analysis of MFA fatigue attacks and phishing-resistant MFA
Context
MFA fatigue is a human identity failure mode, not an authentication protocol failure. Push-based approvals are designed for speed, but attackers exploit the gap between receiving a prompt and making a careful decision, especially when users are already managing multiple devices and late-night sign-ins.
For IAM teams, the issue is not whether MFA exists. The issue is whether the programme still relies on a trust action that can be worn down through repetition, distraction, and social engineering. In that sense, MFA fatigue is a governance problem as much as an authentication problem.
The article argues that phishing-resistant MFA, passkeys, hardware keys, and identity-bound verification reduce the conditions that make push bombing effective. That is a typical failure pattern in environments that adopted MFA quickly without enough controls around rate limiting, context, or user pressure.
Key questions
Q: What breaks when organisations rely on push-based MFA for high-risk access?
A: Push-based MFA breaks when the approval step becomes routine instead of deliberate. Attackers combine stolen credentials with repeated prompts until a user approves one under fatigue, distraction, or social pressure. That creates authenticated access without defeating the password or the MFA system itself, which is why the control is weak in high-risk environments.
Q: Why do MFA fatigue attacks work so well in modern IAM programmes?
A: They work because many IAM programmes still treat user approval as a reliable trust signal. Repetition, late-night sign-ins, and multi-device notifications make the prompt easier to approve than to evaluate. When organisations depend on human attention as a security control, attackers can exploit normal exhaustion and turn it into access.
Q: How do security teams know if MFA fatigue is affecting their environment?
A: Look for repeated denied prompts, challenge bursts from the same account, unusual timing patterns, and follow-on logins from new locations or devices. Abnormal MFA activity often appears before the account is fully compromised. Monitoring should focus on the sequence of prompts and approvals, not just the final login success.
Q: Who is accountable when a user approves a fraudulent MFA request?
A: Accountability is shared across identity security, help desk operations, and access governance. If the programme still relies on approval-only MFA, the organisation has built a control that assumes perfect user attention. Frameworks such as Zero Trust and modern authentication guidance push responsibility toward stronger verification methods, not blame after the fact.
Technical breakdown
Why push-based MFA fails under repeated prompts
Push MFA works by asking a user to approve or deny a login request from a secondary device. That design assumes each prompt is treated as a deliberate security decision. Under fatigue, the approval step becomes habitual instead of reflective, which turns a control into a behavioral timer. Attackers do not need to break the cryptography of the primary password; they only need a valid login flow plus enough repeated requests to force a mistaken approval. The weakness is structural because convenience was built into the control from the start.
Practical implication: treat one-tap approval as an attack surface, not a safe default.
How push-bombing pairs stolen credentials with social engineering
Push-bombing usually starts with credentials obtained through phishing, credential stuffing, or a third-party breach. Once the username and password are accepted, the attacker triggers repeated MFA challenges until the victim approves one. Some campaigns add voice phishing or help desk impersonation to increase pressure and create a false sense of legitimacy. The real failure is the combination of reusable secrets and a user-mediated approval path that can be manipulated in real time. That makes the attack both cheap to run and highly scalable.
Practical implication: monitor for repeated challenge bursts and block them before the user reaches decision fatigue.
Why phishing-resistant MFA changes the trust model
Phishing-resistant methods such as passkeys and hardware security keys bind authentication to the legitimate service and the present user, rather than to a reusable secret that can be replayed or socially engineered. They remove the standing approval prompt that fatigue attacks depend on. In Zero Trust terms, identity verification becomes a stronger, cryptographic event rather than a repeated behavioral nudge. That reduces reliance on human attention as a security mechanism, which is the core weakness exploited by push fatigue.
Practical implication: replace approval-based MFA for high-risk users and sensitive applications with phishing-resistant methods.
Threat narrative
Attacker objective: The attacker wants to turn a routine authentication workflow into a full account takeover that enables theft, persistence, and downstream operational damage.
- Entry begins when the attacker obtains valid credentials through phishing, credential stuffing, or another compromise and then triggers repeated MFA challenges against the target account.
- Escalation occurs when the victim becomes fatigued, distracted, or socially engineered into approving one of the prompts, which converts a weak approval step into authenticated access.
- Impact follows when the attacker uses the approved session to move quickly into data theft, ransomware deployment, privilege escalation, or broader operational disruption.
Breaches seen in the wild
- MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
- IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Push-based MFA creates approval debt: The control asks users to repeatedly spend attention on a security decision until they eventually stop making that decision carefully. That is not just a usability issue. It is a governance flaw because the system depends on the user staying alert longer than an attacker needs to wait. The implication is that approval-heavy MFA should be treated as a fragile control, not a mature authentication end state.
Human fatigue is the attacker’s privilege escalation path: MFA fatigue attacks do not require stronger malware or novel exploitation. They convert cognitive exhaustion into authenticated access, then use that access to escalate into broader system compromise. That is why this pattern repeatedly appears in major breaches. The practitioner conclusion is that identity assurance cannot rely on repeated human judgment under pressure.
Phishing-resistant MFA is now a baseline identity control, not an advanced option: The article’s examples show that push-only MFA remains vulnerable in exactly the environments that expect it to be protective. Hardware-backed authentication, passkeys, and identity-bound verification reduce the chance that a user can be manipulated into approving the wrong request. The implication is that organisations should stop treating push MFA as sufficient for higher-risk access.
Verified identity must replace notification trust: A prompt that asks for approval is not the same as a prompt that proves the user is present and the service is legitimate. That distinction matters across human IAM and high-risk administrative access alike. The implication is that identity programmes need to measure whether their MFA method actually verifies identity or only trains users to react.
MFA fatigue is a warning signal for broader trust design: When a basic login prompt can be worn down, the issue is rarely only authentication. It usually exposes weaker contextual controls, poor rate limiting, and response gaps between identity, help desk, and security operations. The practitioner conclusion is to evaluate the full trust chain, not just the login factor.
From our research:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
- If you are maturing human MFA and machine identity together, start with 52 NHI Breaches Analysis to see how access misuse becomes breach impact across identity types.
What this signals
Approval fatigue should be treated as a control design defect. If users can be conditioned into approving prompts, the programme is relying on a human reflex rather than a verified trust signal. The practical shift is toward phishing-resistant authentication for high-risk access and away from notification-based approval as a default pattern.
Push abuse is a cross-domain warning for identity teams. Human IAM, privileged access, and NHI governance all fail when the organisation assumes that a single authentication event is enough to establish trustworthy access. The real issue is whether the access path can survive repeated challenge pressure without turning into a bypass.
With 97% of NHIs carrying excessive privileges, identity programmes already have a blast-radius problem on the machine side. MFA fatigue shows the same pattern in human access: when control strength depends on one action, the attacker only needs one mistake to change the outcome.
For practitioners
- Replace push-only MFA for sensitive access Move privileged users, contractors, and remote access paths to phishing-resistant authentication such as passkeys or hardware security keys. Reserve push approvals for low-risk scenarios only, and remove one-tap approve flows where the blast radius is high.
- Rate-limit repeated MFA prompts Set hard limits on challenge frequency, alert on bursts, and lock or step-up accounts after repeated denials. Repeated push requests should be treated as hostile activity, not normal login variance.
- Add context to every authentication prompt Display application name, geolocation, device details, and request origin in the prompt so users can spot abnormal sign-in behavior. The more specific the context, the harder it is for attackers to make a prompt look routine.
- Train help desk teams on approval-based impersonation Build scripts and escalation rules for calls or messages that try to coerce users into approving a prompt. Help desk staff should be able to recognise that an authentication push is not proof of identity.
Key takeaways
- MFA fatigue attacks succeed because they turn repeated approval requests into a human reliability problem, not a cryptographic one.
- Real breaches at Uber, Cisco, and MGM Resorts show that push-based MFA can become an operational entry point for authenticated compromise.
- Phishing-resistant MFA, better prompt context, and strict challenge rate limiting are the controls that actually change the outcome.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST Zero Trust (SP 800-207), NIST SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | PR.AC-1 | Zero Trust requires stronger verification than approval-only MFA. |
| NIST SP 800-63 | AAL3 | Phishing-resistant authentication is the right target for fatigue-prone access. |
| NIST CSF 2.0 | PR.AA-01 | Authentication assurance must be resilient to user coercion and fatigue. |
Use alerting and access policy to detect and contain abnormal MFA challenge patterns.
Key terms
- MFA fatigue attack: A social engineering attack that overwhelms a user with repeated authentication prompts until they approve one. The control fails because it depends on human attention staying sharp under pressure, not because the underlying cryptography is broken.
- Phishing-resistant MFA: An authentication method that binds the login to the real user and the legitimate service using cryptographic proof. It reduces the chance that a prompt, code, or approval can be replayed, phished, or worn down by repetition.
- 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.
- Identity assurance: The degree of confidence that the subject attempting access is the right user, device, or workload. Strong assurance depends on binding, context, and resistance to coercion, not only on whether a second factor is present.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle 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 NHI governance in your organisation, it is worth exploring.
This post draws on content published by 1Kosmos: MFA fatigue attacks and phishing-resistant MFA. Read the original.
Published by the NHIMG editorial team on 2026-01-07.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org