MFA fatigue is an attack that spams a user with repeated multi-factor approval prompts until they finally tap approve to make them stop. The attacker already has the password; the flood of push notifications is how they get past the second factor without stealing anything technical.
What is MFA fatigue?
MFA fatigue, also called MFA bombing or push bombing, targets the weakest link in push-based multi-factor authentication: the human being asked to tap approve. The attacker who already holds a valid username and password triggers login attempt after login attempt, each one firing a push notification to the real user's phone.
The bet is on annoyance and confusion. Prompts arrive late at night, dozens in a row, or at a moment the user was half-expecting to log in somewhere. Eventually the user taps approve to stop the buzzing, assumes it is a glitch, or is socially engineered by a fake help desk call telling them to accept the prompt. That single tap hands the attacker a fully authenticated session.
For a fraud or security team, MFA fatigue is a reminder that a stolen password plus a tolerant MFA design is enough. It sits at the account-takeover stage of the kill chain, after credential theft and before whatever the attacker does with the access, and it typically follows credential stuffing, phishing, or an infostealer breach that supplied the password.
How an MFA fatigue attack unfolds
The pattern is short and repetitive by design:
- PrepObtain the password The attacker gets valid credentials from phishing, credential stuffing, or a data breach.
- TriggerSpam approval prompts Repeated logins fire a stream of push notifications to the victim's authenticator or phone.
- PressureWear the user down Timing, volume, or a fake help-desk call nudges the user toward tapping approve.
- AccessRide the session One approval grants a valid session, and the attacker registers a new device or resets MFA to keep it.
Who is involved?
Who | Their role |
The attacker | Holds the stolen password and drives the flood of approval prompts. |
The user | Receives the prompts and, worn down or misled, approves one of them. |
The identity provider | Sends the push challenges; its default settings decide how easy the flood is to run. |
The fake help desk | In social-engineered variants, calls the user to explain away the prompts and coach the approval. |
What it looks like in practice
An employee's password turns up in a credential dump from an unrelated breach. Late one evening, their phone starts buzzing with approval prompts for the corporate single sign-on, one after another. They ignore the first few, then get a call from someone claiming to be IT, apologizing for a system issue and asking them to approve the next prompt to clear the backlog.
The tired employee taps approve. The attacker now holds an authenticated session, immediately enrolls their own device as a trusted authenticator, and begins moving through internal systems. From the identity provider's logs, it looks like a normal, approved login by a known user.
Why it matters to operators
MFA fatigue undercuts a control many teams treat as the finish line. Deploying MFA is not enough if the factor can be approved by reflex; the design of the prompt matters as much as its presence. A single careless tap can neutralize an entire second-factor program, and because the resulting session is genuinely authenticated, downstream monitoring may see nothing wrong.
The fix is mostly in configuration, not new technology. Number matching, where the user types a code shown on the login screen, and phishing-resistant factors like passkeys and hardware security keys remove the reflexive-approval path. Rate limiting the prompts, alerting on repeated denials, and coaching users that a burst of unexpected prompts means their password is compromised turn the attack from a soft target into a noisy failure.
What to watch in the data
- Prompt bursts. Many MFA challenges to one user in a short window, especially repeated denials followed by a late approval.
- Odd-hour approvals. Successful approvals at times the user is normally offline, or right after a cluster of pushes.
- New device enrollment. A fresh authenticator or trusted device added immediately after a contested login.
- Impossible travel. The approval originating from a location or IP inconsistent with the user's usual pattern.
- Help-desk contact nearby. Support or reset activity around the same session, hinting at the social-engineered variant.
Quick questions
Does MFA fatigue break the MFA itself?
No, it does not crack the technology. It exploits the human approval step in push-based MFA. The attacker already has the password and just needs the user to tap approve once, which is a behavioral weakness, not a cryptographic one.
How is it different from AiTM phishing?
Adversary-in-the-middle phishing steals the session token in real time through a proxy page. MFA fatigue does not intercept anything; it simply pesters the user into approving a legitimate prompt. Both defeat basic MFA, but by different routes.
What stops it most reliably?
Number matching and phishing-resistant factors like passkeys or hardware keys, because they require deliberate action tied to the actual login rather than a one-tap yes. Rate limiting and denial alerts help too.
Why do users approve at all?
Fatigue, confusion, and social pressure. A flood of prompts feels like a bug, late-night buzzing wears people down, and a convincing fake help-desk call can make approving seem like the helpful thing to do.
What should a user do when prompts appear unexpectedly?
Deny every one and treat it as proof the password is compromised. They should change the password immediately and report it, since the prompts mean an attacker already has valid credentials and is trying to get in.
Qué saber junto con MFA fatigue
Informe de Fraude y ALD 2026
Olvídate de las predicciones. Este informe desglosa a qué se enfrentan realmente los equipos de fraude y ALD, y cómo responder.