The attack only makes sense once you accept an unpleasant premise: your password is already gone. Billions of credentials circulate from past breaches, and infostealer malware harvests fresh ones from infected machines daily, packaging them into logs sold for a few dollars. Push-based MFA was deployed as the safety net for exactly this situation. MFA fatigue is the discovery that the net has a human-shaped hole in it.
The mechanics are almost embarrassingly simple
Step one: obtain a valid username and password, through credential stuffing, an infostealer log, or plain phishing. Step two: script login attempts against the target's VPN, SSO portal, or email. Each attempt fires a push notification to the victim's phone reading something like "Approve sign-in?" Step three: repeat. At two in the afternoon the victim declines. The tenth prompt arrives during dinner. The thirtieth wakes them at midnight.
Step four, in the better-executed versions, is a social engineering layer on top. The attacker contacts the victim directly, posing as the company help desk: there is a problem with your account, we are pushing a verification to your device, please accept it. Now the flood of prompts stops being suspicious and starts corroborating the story. The victim is no longer being worn down; they are being helped.
Uber and Cisco, 2022
The two canonical cases both happened in 2022, and both are documented by the victims themselves. In September, an attacker got into Uber's internal systems using an external contractor's credentials, which Uber assessed were likely purchased from a dark web marketplace after malware on the contractor's personal device. Uber's own incident writeup describes repeated login attempts generating a flood of MFA approval requests, followed by the attacker contacting the contractor on WhatsApp while claiming to be Uber IT. One approval later, the attacker was inside, and screenshots of internal dashboards were circulating publicly within hours.
Four months earlier, Cisco Talos had published its analysis of a breach that began with an employee's personal Google account. The employee's corporate credentials were sitting in Chrome's synced password store. The attacker combined voice phishing calls, impersonating support organizations, with waves of MFA push notifications until an accidental or worn-down acceptance let them enroll their own device for future MFA and establish VPN access.
The defender has to decline every fraudulent prompt, indefinitely, including the ones that arrive at 3 a.m. The attacker needs a single tap of approve, ever, and can retry at zero cost. Security controls whose failure mode is "the user must be vigilant forever" tend to fail on schedule.
Why approve-to-login was always fragile
The original one-tap push prompt has three structural problems. It carries almost no context, so the user cannot easily distinguish their own login from an attacker's. It makes approval the easiest action, a single tap, often reachable from the lock screen. And through years of legitimate use it trains a reflex: notification appears, thumb approves. The attack does not defeat the cryptography of the second factor; it invokes the approval ceremony and relies on the human to complete it. In that sense MFA fatigue is a close cousin of phishing, and a reminder that an authentication factor is only as strong as the decision procedure wrapped around it.
Vendors knew. Duo, Microsoft, and Okta all shipped mitigations along the same lines, and Microsoft made the main one mandatory: since May 2023, Microsoft Authenticator push approvals require number matching by default. The login screen displays a two-digit number, and the user must type that number into the authenticator app to approve. A victim being push-bombed no longer has an approve button to fat-finger; they would need the number shown on the attacker's screen, which they cannot see.
What number matching does not fix
Number matching kills the blind-approval variant, and deployment data since 2023 suggests push bombing against number-matched prompts has fallen sharply. But it leaves the social engineering variant alive: an attacker on the phone posing as IT can read the number to the victim and talk them through typing it. More importantly, it does nothing against adversary-in-the-middle phishing, where the victim logs into a proxied replica of the real site. The proxy relays the real number to the victim, the victim enters it in their authenticator believing they are logging in, and they are, on the attacker's session.
The property that closes both holes is origin binding. Passkeys and FIDO2 hardware keys perform a cryptographic exchange that includes the origin of the site requesting authentication, verified by the browser. There is no code to read aloud and no approval to grant; the credential simply will not respond to a domain it was not registered to, no matter how convinced the human is. This is what "phishing-resistant MFA" means when CISA and others use the phrase, and MFA fatigue is one of the attack classes it was coined against.
What to do, on both sides of the prompt
If you run an organization
- Turn on number matching and additional context (requesting application, coarse location) everywhere push MFA remains.
- Rate-limit push attempts and lock the account or alert after a burst of denials. A user declining five prompts in ten minutes is an incident, not noise.
- Give users a deny-and-report button, and treat those reports as compromised-password events, because they are.
- Move administrators and other high-value accounts to FIDO2 or passkeys first, then expand outward.
- Tell your help desk, and your users, that IT will never ask anyone to approve an MFA prompt. That single sentence removes the script the social engineering variant depends on.
If you are the person holding the phone
- An MFA prompt you did not initiate means your password is compromised. Decline it, then change the password. Declining alone treats the symptom and leaves the attacker retrying tomorrow.
- No legitimate support person will ever need you to approve a prompt or read them a code. Anyone asking is describing the attack to you in real time.
- Where a service offers passkeys or supports hardware keys, prefer them over push approval, and see our comparison of 2FA methods for the full ranking.
The larger lesson generalizes past MFA. Any security system with a recurring human approval step will eventually face an attacker who automates the asking. Designs that survive are the ones where the safe answer is also the easy one, and where one tired mistake at midnight is recoverable rather than final.