MFA fatigue attacks exploit human approval loops, not crypto

At a glance

What this is: This is an analysis of MFA fatigue attacks and the finding that repeated push prompts can convert valid credentials into account access when users approve under pressure.

Why it matters: It matters because IAM teams still rely on push-based approval paths that attackers can manipulate, so detection and phishing-resistant controls are central to preventing takeover.

Context

MFA fatigue attacks target the approval moment inside multi-factor authentication, not the strength of the password or the underlying cryptography. In practice, the attacker already has valid credentials and uses repeated prompts to wear down the user until one approval lands.

For identity programmes, that means the control failure sits in the human decision loop that permissive push MFA still depends on. The relevant governance question is whether an access method can be induced into authorising an attacker through repetition, confusion, or habituation rather than through a broken factor.

Key questions

Q: What breaks when push MFA depends on blind approvals?

A: Push MFA breaks when users are asked to approve requests without enough context to verify the session behind them. At that point, repeated prompts become a social engineering channel rather than a security control, because the attacker only needs one accidental or coerced tap to win.

Q: Why do MFA fatigue attacks succeed even when users know multifactor authentication is supposed to protect them?

A: MFA fatigue works because attackers exploit routine behavior, not just technical weakness. Users become accustomed to repeated prompts and may approve a request to stop the disruption, especially when they are busy or distracted. Once attackers have valid credentials, a stream of notifications can pressure the target into granting access, turning a normal security control into a social engineering channel.

Q: What signals show that an MFA fatigue attack is underway?

A: Look for repeated MFA requests in a short period, a long series of denials, and then one unexpected approval. Off-hours approvals, unfamiliar device context, and login bursts from unusual geographies are also strong indicators that the approval flow is being abused.

Q: Should organisations keep approve or deny push prompts for high-value accounts?

A: Not for critical access. Approve or deny push is easy to abuse because it places the final security decision in a human response that attackers can pressure. For privileged or sensitive accounts, phishing-resistant MFA and tighter conditional access provide a more defensible control posture.

Technical breakdown

How repeated prompts convert valid credentials into access

An MFA fatigue attack begins after the attacker has already obtained a working username and password. Each login attempt triggers another push prompt, phone call, or code request, which makes the victim see a stream of apparently legitimate authentication challenges. Because the first factor is valid, the prompts look routine rather than suspicious. The attack succeeds when the user approves one challenge to stop the noise or because the prompt has become habitual. The cryptography remains intact throughout. The exploitable property is the predictability of human approval under pressure, which is why prompt flooding is a social-engineering problem inside an authentication workflow.

Practical implication: treat repeated approval requests as an authentication abuse signal, not a user inconvenience.

Why permissive push MFA creates a standing abuse path

Push-based MFA is convenient because it turns authentication into a one-tap choice. That convenience also creates an approval loop that attackers can exploit at scale, especially where number matching, phishing-resistant factors, or prompt rate limits are not enforced. Legacy applications and weak fallback methods keep the path open even when stronger options exist elsewhere in the environment. The issue is not that MFA is weak in general. The issue is that permissive push creates a decision surface that can be manipulated by repetition, fatigue, and uncertainty, which makes the method brittle in high-risk access flows.

Practical implication: move high-value access away from simple approve or deny push prompts.

Why post-approval persistence is the real warning sign

Once a user approves the prompt, attackers rarely stop at the session they just won. They often move immediately to register a new MFA method, reset the password, or alter recovery details so they can retain access after the original approval window closes. Those follow-on actions show that the attack has shifted from prompt abuse to account persistence. From an identity-governance perspective, this is the point where the control objective changes from preventing approval to detecting whether the account is being modified to survive containment. That is why persistence telemetry matters as much as prompt telemetry.

Practical implication: alert on MFA re-enrollment, password changes, and recovery setting edits immediately after suspicious approvals.

Threat narrative

Attacker objective: The attacker wants to turn a single coerced approval into durable account access and a foothold for further compromise.

1. The attacker starts with valid credentials stolen through prior compromise, password reuse, phishing, or infostealer logs.
2. They flood the target with repeated MFA prompts until the user approves one out of confusion, annoyance, or habit.
3. The approved prompt opens a session that the attacker uses quickly to register new MFA methods, reset the password, or change recovery data.
4. The attacker retains access by turning a single approved prompt into persistent account control and follow-on intrusion activity.

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.
• Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MFA fatigue is an approval-loop failure, not an authentication-strength failure: The password and second factor can both be technically valid while the human approval process is still coerced into granting access. That distinction matters because many programmes measure MFA coverage without measuring whether the approval model itself can be manipulated. The right question is not whether MFA exists, but whether an attacker can weaponise its human confirmation step. The practitioner conclusion is that permissive approval flows are part of the attack surface.

Phishing-resistant factors change the trust model, not just the user experience: Number matching, FIDO2 security keys, and passkeys reduce the attacker’s ability to turn repetition into consent. They do more than improve convenience because they remove the simplest version of the prompt-abuse loop. That makes this a governance issue as much as an authentication issue: the organisation must decide which access paths still rely on a user’s momentary judgment under pressure. The practitioner conclusion is to reserve weak approval patterns for low-risk contexts only.

Prompt flooding reveals the limits of human-paced authentication governance: Access review and conditional-access programmes often assume the risky event will be visible long enough to investigate after the fact. MFA fatigue compresses the compromise into a short burst, then immediately shifts into persistence actions such as re-enrollment and password change. That creates a narrow detection window and a fast-moving operational problem for IAM and SOC teams. The practitioner conclusion is that post-login telemetry must be tied to identity changes, not treated as separate issues.

Named concept: MFA approval debt: permissive push authentication accumulates risk every time the organisation asks users to resolve a security decision that attackers can repeat indefinitely. The debt grows when the environment accepts simple approve or deny prompts, weak fallback methods, and inconsistent enforcement across applications. The implication is that identity programmes must treat approval design as a control choice, not a convenience preference. The practitioner conclusion is to reduce the amount of trust delegated to a single tap.

Detection has to focus on the chain, not the prompt alone: A burst of MFA notifications is suspicious, but the real signal is the sequence that follows a successful approval. New MFA enrollment, password resets, and changed recovery settings are the highest-value indicators because they show the attacker trying to keep access after the user is no longer being flooded. This is where ITDR and IAM monitoring need to converge. The practitioner conclusion is to correlate prompt storms with immediate post-authentication changes.

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.
• Read next: Identity Threat Detection and Response (ITDR) Guide

What this signals

MFA approval debt: every permissive push workflow adds another place where attackers can convert pressure into access. The practical shift is from asking whether MFA exists to asking whether the approval mechanism can be manipulated faster than the SOC can see it.

The strongest programmes now pair phishing-resistant authentication with identity threat detection, because prompt flooding is only the first move. The higher-value control question is whether post-authentication changes such as MFA re-enrollment and recovery edits are being correlated fast enough to contain takeover.

For practitioners

• Harden push approvals with phishing-resistant factors Require FIDO2 security keys or passkeys for high-value accounts and administrative paths so access is not decided by a single approve or deny prompt.
• Enable number matching everywhere it is supported Turn on number matching in the authenticator stack and verify that legacy tenants, fallback flows, and special-case apps are not still using simple push approval.
• Rate-limit repeated MFA prompts Cap prompt frequency per user and suspend push after repeated failures so a live prompt flood cannot continue until one approval lands.
• Correlate MFA prompts with identity changes Investigate any successful login that is followed quickly by MFA re-enrollment, password reset, or recovery-data changes because that sequence often signals takeover.
• Train users on unsolicited prompt behavior Teach users never to approve a prompt they did not personally initiate and to report repeated prompts immediately through a defined security channel.

Key takeaways

• MFA fatigue attacks exploit the user decision step in push-based MFA, which means the failure can exist even when passwords and factors are technically valid.
• The most reliable danger signals are the sequence after approval, especially rapid MFA re-enrollment, password changes, and recovery-setting edits.
• High-risk accounts need phishing-resistant factors and tighter prompt governance, because repeated approval requests are part of the attack surface.

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 Bombing: Push bombing is an MFA bypass technique that overwhelms a user with repeated authentication prompts until one approval is granted. The attack depends on fatigue, distraction, or confusion, not on breaking the underlying cryptography. It is effective because many organisations still treat user approval as a trustworthy security signal.
• Phishing-Resistant MFA: Phishing-resistant MFA uses authentication factors that cannot be easily replayed, intercepted, or socially engineered. In regulated environments, this usually means device-bound or cryptographic methods rather than push prompts or SMS codes, because the control must hold up under realistic attack conditions.
• Identity Threat Detection and Response: Identity threat detection and response is the practice of finding misuse of credentials, unusual access patterns, and compromised identities across human and machine actors. For NHIs, it relies on telemetry from code, vaults, cloud services, and pipelines to detect abuse early enough to contain it.

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.