The short answer
Push-based multi-factor authentication replaces a code you type with a prompt you tap. That is a genuine security improvement in most respects, and it introduces one specific weakness: the attacker controls how often the prompt appears, and you control only whether you tap it.
The attack is not technical. An attacker who already has your password triggers login after login, generating a stream of approval prompts, and waits. At two in the morning, after the fortieth notification, somebody taps approve — to make it stop, or because they assume a broken app is retrying, or because they are asleep enough not to be reasoning at all.
It has worked against organisations with mature security programmes. The weakness is in the interaction design, not the cryptography.
Why the prompt is the problem
A traditional TOTP code requires you to open an app, read six digits, and type them. It is deliberate. Nothing happens unless you initiate it.
A push prompt inverts the initiative. It arrives unprompted, it is answered with one tap, and — critically — the approve button is usually large, prominent, and positioned exactly where a thumb rests. The deny button is smaller and often requires a second confirmation.
Three human factors then do the work:
Habituation. You approve legitimate prompts many times a week. The action becomes automatic. Automatic actions are not evaluated.
Interruption. Prompts arrive during something else. The fastest route back to what you were doing is the big button.
Ambiguity. A bare prompt saying “Approve sign-in?” gives you nothing to check against. Most people cannot recall whether they left a session open on a laptop at the office, and in the absence of information, “probably me” is the default inference.
The attacker exploits all three simultaneously by increasing volume until whichever one is going to break, breaks.
The variants
Volume bombing. The pure form. Dozens or hundreds of prompts in a short window. Crude, noisy, and effective often enough to be worth doing.
Timed low-volume. Far more dangerous. Two or three prompts sent at 09:00 on a weekday, when you are logging into things anyway and a prompt is unremarkable. This defeats rate-limiting controls tuned for bombing, and it defeats the user’s suspicion, because three prompts is not alarming.
Push plus a phone call. The attacker calls claiming to be IT or the bank’s fraud team, explains that a system migration is generating verification prompts, and asks you to approve the next one. This converts the attack from a gamble into a near-certainty, and it is the version most often seen in serious incidents. The call may spoof the institution’s real number.
Approval after a real login. The attacker waits until you legitimately authenticate, then fires their own attempt seconds later. The second prompt looks like a retry of the first.
The prerequisite everybody forgets
Every one of these attacks requires the attacker to already have your password. Push bombing is the second step, never the first.
That means the attack is downstream of credential compromise — reuse from a breach, a phishing page, or an infostealer. Fixing the second factor without fixing the first leaves the attacker able to try indefinitely, and the defender relying on a person never making one mistake at an arbitrary hour.
If you receive an unexpected push prompt, the actionable information is not just “someone is attacking me”. It is “my password is already known to someone”, and that is the thing to fix within the hour.
The three controls that work
Number matching. The login screen displays a two- or three-digit number, and the prompt on your phone asks you to select it from three options. This is the single most effective mitigation, because it makes approval impossible without seeing the initiating screen. A blind tap has a one-in-three chance of being wrong and, more importantly, the user cannot approve by reflex. Most major identity providers now offer this and many enable it by default. If your provider supports it and it is off, turning it on is the highest-value change available.
Context in the prompt. Showing the application, the geographic location and the IP of the login attempt turns an unanswerable question into an answerable one. “Approve sign-in?” is unanswerable. “Sign-in to Payroll from Lagos, Nigeria” is trivially answerable by someone in Helsinki.
Rate limiting with lockout. Capping failed attempts and locking the account after a threshold removes the volume the crude attack depends on. This does not address the low-and-slow variant, which is why it is third rather than first.
Together these are strong. Individually, number matching does most of the work.
Passkeys remove the category
Phishing-resistant authentication does not have this failure mode, because there is no approval to give and no code to relay. A passkey signs a challenge bound to the origin, and the browser refuses to sign for a domain that does not match. There is no prompt an attacker can trigger from their own session that your device will answer.
Where a passkey or hardware security key is available for an account that matters — your email above all, since email is the recovery path to everything else — that is the migration worth making. Passkeys for banking: where they work covers the mechanics and the current state of adoption.
What to do when a prompt you did not expect arrives
Deny it. Always. A denied legitimate login costs you one retry.
Do not approve to stop the noise. Put the phone on silent instead. The prompts stopping is not a goal worth achieving by approving one.
Change the password immediately, from a different device. Not later. The prompts prove the password is compromised, and the account is protected only by your continuing to decline.
Check active sessions and sign out everywhere. Most providers list active sessions with location and device. Terminate all of them after the password change, not before.
Report it. For a work account, tell security — you are seeing evidence of a credential compromise that probably is not limited to you. For a bank, use the number on your card.
Never approve a prompt because someone on the phone asked you to. No legitimate institution will ever make that request. Like the rule about reading back codes, this one is absolute, which is what makes it usable when you are being pressured — and pressure is the entire point of the call.