MFA Fatigue and Push Bombing: What the Attack Is and How to Stop It

MFA fatigue is a social engineering attack in which the attacker, who already holds a valid password, floods the victim with multi-factor push notifications until they approve one out of tiredness, distraction or pressure. It is also known as MFA bombing and, in CISA terminology, as push bombing. It has become one of the most cost-effective ways into a company in recent years because it does not break the cryptography of the second factor: it breaks the patience of the person on the other side of the screen.

This guide explains what MFA fatigue is, clarifies the difference between push bombing and MFA bombing, breaks down the attack mechanics, reviews the cases that made it famous (Uber 2022, Cisco 2022 and the 0ktapus campaign against Twilio) and details the defence that closes it: number matching, rate limits on the push, and, as the definitive fix, phishing-resistant MFA with FIDO2 and WebAuthn.

What MFA fatigue is

MFA fatigue is the abuse of push-based second factors by sending repeated approval requests until the legitimate user accepts one just to make the noise stop. The attacker does not need to intercept a token code or clone the device. Two things are enough: a valid password and a second factor configured as an "Approve or Deny" push notification.

The password arrives through the usual identity-theft channels: reuse after a breach (the engine behind credential stuffing), sale on credential markets, or capture by an infostealer on the employee's personal machine. With that first factor in hand, the attacker tries to authenticate over and over. Each attempt fires a notification on the victim's phone. If the system does not throttle those requests, the person receives dozens of identical alerts, often in the middle of the night, until they tap "Approve" to get some sleep.

MITRE ATT&CK catalogues this technique as T1621 (Multi-Factor Authentication Request Generation). It is not a software flaw with an assigned CVE: it is a design flaw in how the push factor delegates the final decision to a tired human being. That is why no patch fully fixes it and why the correct defence changes the type of factor, not just its configuration.

Push bombing, MFA bombing and MFA fatigue: clearing up the terms

All three names describe the same attack family, but each puts the emphasis in a different place:

• MFA fatigue highlights the psychological mechanism: the user's exhaustion as the requests keep coming.
• MFA bombing and push bombing highlight the technique: the sustained barrage of requests. CISA has standardised "push bombing" in its guidance on phishing-resistant authentication.

It is worth not confusing it with two neighbouring techniques. AitM proxy phishing (with kits such as Evilginx or EvilProxy) does not bombard: it intercepts the already authenticated session cookie and bypasses the second factor without asking for approval. SIM swapping targets the SMS factor by hijacking the phone number. Push bombing, by contrast, attacks the legitimate push factor head-on and relies on the victim eventually giving in. Each one is mitigated differently, even though the final destination, FIDO2, closes nearly all of them at once.

How the attack works, step by step

The operational chain of MFA fatigue has three very recognisable phases.

1. The attacker obtains a valid password

There is no campaign without a password. The attacker starts from an email and password pair taken from a reused breach, an infostealer log, or a stolen-credential panel. This phase connects directly to the identity-theft problem described in the social engineering guide: the human factor is once again the starting point.

2. The barrage of push requests

With the password, the attacker retries the login automatically. Each attempt generates a push notification in the victim's authenticator app (Microsoft Authenticator, Duo, Okta Verify). If the platform applies no limits, the user receives a shower of alerts that look identical. The attacker's bet is simple: one of those alerts only needs to land during a moment of distraction, haste or fatigue.

3. The final nudge by voice or message

When the barrage alone is not enough, the attacker adds vishing. They call or message the victim posing as the IT support team: "we are migrating the system, please accept the notification to stop receiving alerts." That combination of bombardment and an authority pretext is exactly what broke Uber and Cisco. The type of phishing that precedes the nudge is usually targeted and highly convincing.

Public cases: Uber, Cisco and 0ktapus

Without glamorising them, these incidents put MFA fatigue on every security team's agenda.

Uber (September 2022). An attacker linked to Lapsus$ obtained the credentials of an external contractor, most likely bought after the contractor's machine was infected by an infostealer. They bombarded the contractor with push requests and, when that did not work, contacted them on WhatsApp posing as Uber support to ask them to accept. The contractor approved one. Once inside, the attacker found PowerShell scripts with hard-coded admin credentials that gave access to the company's PAM solution and, through it, to secrets across multiple internal platforms.

Cisco (May 2022). An initial-access actor compromised an employee's personal Google account, where corporate credentials were synced. They then combined vishing with Duo push bombing until the employee accepted a request. The pattern is identical to Uber's: stolen password plus push fatigue plus a convincing phone call.

0ktapus and Twilio (August 2022). The campaign that Group-IB named 0ktapus hit more than 130 organisations through smishing that impersonated Okta login pages to steal credentials and codes. Twilio was one of the victims. The contrast with Cloudflare is the best lesson: the same campaign reached its employees, but it failed because their second factor was FIDO2 security keys, impossible to bombard or phish. The same bait, two opposite outcomes, and the difference was the type of factor.

How to stop MFA fatigue

The defence is layered, from the quickest to deploy to the most definitive.

Number matching

Number matching removes blind approval. Instead of a simple "Approve or Deny", the login screen shows a two-digit number that the user must type into their app to confirm. Because the attacker cannot see that number, the barrage stops working: the victim cannot approve by reflex. Microsoft made it the default behaviour of Authenticator in May 2023; Duo offers it as Verified Push and Okta as the number challenge. It is the highest effort-to-impact measure available in the short term.

Rate limiting and push lockout

Bombardment thrives on the absence of limits. Setting a cap on requests per time window, applying backoff when denials pile up, and temporarily locking the account after several ignored notifications cuts the attack off at the root. The identity console (Microsoft Entra ID, Okta, Ping) allows these policies. It also helps to show context in the notification itself: application name, approximate location and source IP of the attempt, so that a request from another country looks obviously suspicious.

Conditional access and risk context

Risk-based authentication scores each attempt by device, geolocation, time and pattern. A login from an impossible location demands additional factors or is blocked before any push is generated. This approach fits squarely into a Zero Trust architecture, where no session is trusted simply because the second factor said yes.

FIDO2, WebAuthn and passkeys: the definitive fix

The previous layers reduce the risk; FIDO2 eliminates it. A hardware security key (YubiKey, Titan) or a passkey binds the credential to the site's real origin through public-key cryptography, the foundation of PKI. There is no "Approve" notification to bombard, and the signature is only valid for the legitimate domain, so neither push fatigue nor proxy phishing works. WebAuthn is the W3C standard that implements it in the browser, and passkeys are its mainstream form. Migrating privileged accounts to phishing-resistant MFA, starting with administrators and external access, is CISA's central recommendation and the real close-out of the problem. That access policy is best governed from a coherent IAM strategy.

Prevention checklist

• Enable number matching across the organisation if plain push is still in use.
• Limit the number of push requests per user and time window, with lockout after repeated denials.
• Show application, location and IP in every approval notification.
• Apply risk-based conditional access for anomalous geolocations and devices.
• Migrate administrators, privileged accounts and external access to FIDO2 or passkeys.
• Train staff to report push bombing instead of approving it and to distrust any call asking them to accept a notification.
• Harden the helpdesk and monitor spikes of denied MFA requests as an early sign of an active campaign.

Frequently asked questions

What is the difference between MFA fatigue and push bombing?

None at heart: they are two names for the same attack. "MFA fatigue" emphasises the exhaustion of the user who eventually approves, while "push bombing" (the term CISA uses) and "MFA bombing" emphasise the technique of flooding with requests. They describe the same chain: stolen password plus a barrage of pushes until approval.

Does number matching stop MFA fatigue?

To a large extent, yes. By forcing the user to type a number that only appears in the attacker's legitimate session, it removes the reflex approval that makes the barrage possible. It is not foolproof against a very elaborate vishing call that dictates the number to the victim, but it dramatically raises the cost of the attack and is the fastest mitigation to deploy.

Why is FIDO2 immune to push bombing?

Because there is no notification to approve. FIDO2 and WebAuthn replace "Approve or Deny" with a cryptographic signature bound to the service's real domain. The attacker cannot generate requests the victim accepts by mistake, and the credential does not work on a phishing site because it is tied to the legitimate origin. That is why FIDO2 keys stopped the 0ktapus campaign at Cloudflare.

Does SMS-based MFA protect against MFA fatigue?

SMS does not suffer push bombing because it sends no approval notifications, but it is weaker against other vectors, in particular SIM swapping and code phishing. Swapping push for SMS is not an improvement: the right path is to move to phishing-resistant MFA with FIDO2 or passkeys.

Which accounts should I migrate to phishing-resistant MFA first?

The highest-impact ones: domain and cloud-platform administrators, third-party remote access, and profiles with lateral privileges. These are what an attacker hunts after the first compromise, as Uber showed, and the ones that justify the cost of keys or passkeys from day one.

Related resources

• What is social engineering: the human-factor framework that sustains MFA fatigue and the support-call pretext.
• What is credential stuffing: the usual source of the password that starts the barrage.
• What is vishing: the voice nudge that finished the Uber and Cisco cases.
• Types of phishing: the family of lures that precedes credential theft.
• What is IAM: where MFA and privileged-access policy is governed.

Defence against MFA fatigue with Secra

At Secra we empirically validate your organisation's resistance to MFA fatigue inside controlled exercises: we review the second-factor configuration (presence of number matching, push limits, notification context and conditional access), we simulate bombardment and vishing campaigns in Red Team projects to check whether staff and the helpdesk hold up, and we design the migration roadmap to phishing-resistant MFA with FIDO2 and passkeys, starting with privileged accounts. If you still rely on plain push or TOTP for your administrators, reach us through contact or check our Red Team service.