In short: MFA fatigue (also called push bombing) is an attack where a hacker who already knows your password floods your phone with dozens of identical 'Approve sign-in?' prompts. The bet is that you will get tired, confused in the middle of the night, or decide 'it is just a glitch' and tap Approve. One such tap and a stranger is inside your account, having walked straight past your two-factor protection. The reliable defense: turn on number matching, move to passkeys or a hardware key, and never approve a login you did not start yourself.
What MFA fatigue is
Multi-factor authentication (MFA, also known as 2FA) adds a second step to login — a confirmation from your phone. The most convenient and therefore most popular option is a push notification: the app shows 'Signing in, is this you?' with Approve and Deny buttons. Convenient right up until the wrong person starts pressing those buttons.
MFA fatigue exploits the human, not the technology. The attacker has already obtained your username and password — bought it in a breach, phished it, or guessed it because you reuse the same password across sites. They have the password, but a second factor stands in the way. Instead of breaking the encryption, the attacker simply triggers the login over and over, and a stream of approval prompts pours onto your phone. Hence the attack's other names: push bombing, MFA bombing, prompt bombing.
The key idea: if you get an unexpected approval prompt at all, that is already bad news. It means someone has your password. How attackers get passwords, and why a unique password per site closes half the problem, is covered in the article on password managers.
What the attack looks like, step by step
Push bombing almost always follows one script, and knowing that script is half the defense.
- Step 1. The attacker obtains a username + password pair (a breach, a phishing page, a password reused from another hacked site).
- Step 2. They enter it on the login page and trigger the sign-in — again and again, sometimes with an automated script.
- Step 3. Your phone starts buzzing with 'Approve sign-in?' prompts. There can be dozens in a few minutes, or occasional waves over several hours.
- Step 4. Attacks are often timed for an inconvenient moment — late evening or early morning, when your guard is down.
- Step 5. Frequently a message arrives in parallel, supposedly from 'support': 'We spotted a glitch in the login system, approve the request so it gets fixed.' This is classic social engineering — the same logic as in remote-access scams, where the attacker poses as tech support.
- Step 6. The worn-down or deceived person taps Approve — at least once.
- Step 7. The attacker is in. The first thing they do is change the password, disable or reassign 2FA to their own phone, and add their own device — so you can no longer get control back.
A real case: the Uber breach of 2022
The most famous example of push bombing is the attack on Uber in September 2022, attributed to the Lapsus$ group. The scenario matches the description above almost point for point.
First the attackers obtained the password of an external Uber contractor — reportedly through a mix of phishing and buying credentials. They had the password, but push authentication protected the login. So the attacker began triggering the sign-in repeatedly, and a stream of approval prompts flowed to the contractor's phone with pauses over roughly an hour. When the person did not respond, the attacker messaged them, posing as Uber IT and saying the notifications would stop as soon as they approved the request. Tired and believing they were talking to genuine support, the contractor tapped Approve.
From there the attacker was inside the internal network, did some reconnaissance, and found administrative credentials inside one of the scripts, which opened the door to far more sensitive systems. Separately, the incident exposed a technical weakness: the system allowed unlimited login attempts with no throttling or alerts. That is exactly why modern defenses are about leaving nothing to 'blindly approve.'
Why plain push is vulnerable and other methods are not
The weakness of plain push is that it asks you for a single action — a tap on Approve. There is no check that you are the one signing in. Methods that require you to meaningfully carry something over from the login screen, or where the confirmation is cryptographically bound to the site, are resistant to push bombing by design.
| Second-factor method | What it asks of you | Vulnerable to push bombing |
|---|---|---|
| Plain push (Approve / Deny) | One tap on a button | Yes — an accidental tap is enough |
| Push with number matching | Type a number shown on the login screen | Much lower — you do not have the number unless the login is yours |
| TOTP code (authenticator app) | Manually enter 6 digits from the app | No — there is nothing to approve |
| SMS code | Enter a code from a text message | No to push bombing, but vulnerable to SIM swap and smishing |
| Passkey / FIDO2 / hardware key | Biometrics or a key tap; signature bound to the domain | No — plus it also blocks phishing |
SMS looks safe from this particular attack, but it has plenty of other weak spots — code interception, SIM swapping, fake texts. The last one is covered in detail in the piece on smishing and SMS phishing. The strongest option in the table is passkeys: there the confirmation is cryptographically tied to the real site, and 'accidentally approving' someone else's login is impossible in principle. How that works is explained in the article on passkeys.
What number matching is and why to enable it
Number matching is the simplest upgrade that kills push bombing for most people. Instead of yes/no buttons, the app asks you to enter a two- or three-digit number shown on the screen where the login is happening. If you did not start the login, you simply do not have that number — there is nothing to blindly approve.
Microsoft made number matching the default behavior in its Authenticator app in May 2023; Okta, Duo, and others added similar challenges. But plain old push still shows up in many accounts and corporate setups. Go into the security settings of your accounts and your authenticator app and make sure number matching is on, not a bare Approve/Deny.
Does a VPN protect against MFA fatigue
The honest answer: not directly. Push bombing runs through your phone and the human factor, not through the network, so a VPN on its own does not stop this attack. Do not believe ads promising that a VPN will 'protect you from account takeover' — these are different layers of defense.
But a VPN reduces the chance that it ever comes to push bombing. The attack starts with the attacker having your password, and passwords often leak on unprotected networks — the public Wi-Fi of an airport or cafe, where traffic can be intercepted or a fake login page slipped in. By encrypting the connection, LiMP VPN closes that leak channel: there is nothing left to intercept on an open network. It is not a replacement for the second factor but a layer beneath it — the hygiene of the password itself. You can review plans on the LiMP VPN pricing page. Against push bombing specifically, number matching and passkeys are what save you, as described above.
Checklist: how to defend against push bombing
- Never approve a login you did not start yourself. A flood of prompts is not a glitch — it is a direct signal that your password is already stolen.
- Turn on number matching in your authenticator app and account settings instead of plain Approve/Deny.
- Move to passkeys or a hardware key wherever it is supported — this removes the very possibility of 'approving blindly.'
- Got an unexpected prompt? Change that account's password immediately: it is compromised.
- Use a unique password on every site and a password manager, so one leak does not open every door.
- Do not trust 'support' in a messenger or on a call asking you to approve a login — a legitimate service never does that.
- Check active sessions in your account and end every device you do not recognize.
- Turn on alerts for new sign-ins and for changes to security settings — that way you notice someone else's activity right away.
Push bombing is an attack on inattention, and for that reason it loses against a prepared person. A general checklist on passwords, the second factor, and spotting phishing is collected in the separate guide on protecting your account from hacking.
Frequently asked questions
What do I do right now if my phone is flooded with login prompts?
Do not approve any of them. Open the account from another, trusted device and change the password immediately — that invalidates the current login attempts. Then check active sessions and end any you do not recognize.
Does a plain app code (TOTP) help against push bombing?
Yes. TOTP has no Approve button — you have to manually type a six-digit code from the app. The attacker has nothing to send you for approval, so the push-bombing mechanic does not work against that second factor.
Can ordinary people be attacked this way, not just company employees?
Yes. Any account with push approval is vulnerable if its password has leaked — personal email, social media, cloud storage. Corporate victims just make louder headlines.
I accidentally approved a prompt once. What now?
Treat the account as compromised. Change the password, sign out of all sessions, check whether the attacker added their own device or a new 2FA method, and turn on sign-in alerts. The sooner the better — the attacker has a window to dig in.
Does a passkey fully protect against this attack?
Yes, against push bombing completely: the confirmation is bound to the real site and your device, so blindly approving someone else's login is technically impossible. As a bonus, a passkey is also resistant to phishing.
Why do I get these prompts at all if I am not signing in anywhere?
Because someone knows your password and is trying to log in with it. The very fact of an unrequested push means your password has leaked — change it, even if you never approved a single prompt.