MFA Fatigue Attacks: Detecting Push-Bombing Before the Approve

The attacker already has the password. All that stands between them and the account is a push prompt, so they send dozens of them until your customer, worn down and confused, finally taps approve.

MFA fatigue turns your strongest login control into the attack surface. The second factor works exactly as designed — a real human approves a real prompt — which is why fixing it means looking behind the push, at the device and network generating the flood.

The flood starts with a login attempt

Every push notification is downstream of an authentication attempt. Before your MFA provider ever rings the victim’s phone, the attacker’s device has hit your login endpoint with the stolen password. That is your intervention point.

If you score the device at that first step, you can decide whether the push is worth sending at all. A login from a device with no history on the account, riding a datacenter or residential-proxy IP, from an unexpected country, does not deserve to generate a prompt the victim can accidentally approve.

Signals that mark the attacker’s login

Push-bombing has a recognizable shape at the point of origin:

• Repeated login attempts for one account in a short window, each firing a push
• A new device with no successful history on the account
• A proxy or datacenter ASN inconsistent with the customer’s normal network
• A geography mismatch against the account’s login history
• Velocity: many push triggers per minute, far above human retry behavior

Prynt resolves a stable visitorId and network reputation server-side at login, so you can attach that risk score to the authentication attempt before the push provider is invoked. The flood never reaches the victim because it never leaves your backend.

Rate-limit the push, not just the login

The fix is to make the push conditional on device trust:

1. On each login attempt, resolve the device and network before requesting an MFA push.
2. If the device is known and trusted, send the push as normal.
3. If the device is new or high-risk, throttle: cap pushes per account per window, or suppress them entirely and require a device-bound factor instead.
4. On a burst of high-risk attempts, lock the account’s push channel and notify the enrolled device out of band.

Number-matching MFA — where the user types a code shown on the login screen — also helps, because a fatigued tap alone no longer completes the login. Pair it with device scoring so the attacker’s screen and the victim’s phone never share the number.

Keep it invisible for real users

The whole point is that a legitimate login from a known device generates exactly one push and sails through. Device scoring adds no friction to the customer approving their own login on their own phone; it only bites the anomalous flood.

Reason codes keep the decision auditable. “Push suppressed: new device, residential proxy, five attempts in ninety seconds” tells your team precisely why the prompt never fired, and gives you evidence when a customer asks.

Why per-account limits alone are not enough

A common first fix is to cap MFA pushes per account per minute. It helps, but a determined attacker spreads the flood across many accounts, or paces it just under your ceiling, and a global per-account limit cannot tell a real user’s frantic retries from an attack.

Device and network context is what makes the throttle intelligent. A trusted device that fails a push and retries is a customer fumbling with their phone; a never-seen device on a rotating proxy pool driving prompts across dozens of accounts is a campaign. Scoring the origin lets you apply a tight limit to the second case while leaving the first untouched, so you stop the attack without turning your own users into collateral. The same device identity also links the individual floods together, revealing one operator behind what looks like unrelated noise.

Stop the flood at the source

MFA fatigue is not a weakness in the second factor — it is a weakness in sending prompts to anyone who has the password. Score the device behind each login and the push flood dries up before your customer ever has a chance to approve it.

Prynt is free to start. Compare a trusted device against a fresh one in the playground, then gate your push requests on that score.