Key takeaway: Push-approval MFA reduces a security decision to a single tap made with almost no context. Number matching and phishing-resistant factors restore the context that tap removed.
The Attack Requires No Sophistication
The attacker already has a valid password from a breach or phishing kit. They attempt login, which triggers a push notification to the victim’s phone. The victim declines. The attacker attempts again. And again — sometimes dozens of times over hours, often deliberately at two in the morning.
Eventually someone taps approve. Occasionally out of genuine confusion about whether a legitimate service is misbehaving. Occasionally to stop the noise. Sometimes the attacker escalates by calling the target while posing as IT and saying “we’re troubleshooting your account, please approve the prompt you’re about to see.”
Several widely publicised enterprise breaches began exactly this way. No cryptography was broken. The protocol behaved as designed.
The Design Flaw
A bare push prompt asks a person to make a security decision while giving them nothing to decide with. It says “approve sign-in?” and offers two buttons. It does not meaningfully convey where the request originated, what application requested it, or that the person receiving it is not the person triggering it.
Worse, it trains a reflex. Users approve dozens of legitimate prompts per month. Tapping approve becomes muscle memory rather than an evaluated judgement, which is exactly the condition an attacker needs.
Ranking the Available Factors
| Factor | Resists fatigue | Resists phishing | Notes |
|---|---|---|---|
| SMS code | No | No | Also vulnerable to SIM swap |
| Bare push approval | No | No | The vulnerable default |
| Number-matched push | Yes | Partially | Cheap, large improvement |
| TOTP authenticator app | Yes | No | Code is still phishable |
| Passkey / WebAuthn | Yes | Yes | Origin-bound by design |
| Hardware security key | Yes | Yes | Strongest, highest friction |
Number matching is the pragmatic immediate fix. The login screen displays a two- or three-digit number that the user must type into the app. An attacker who cannot see the victim’s screen cannot supply the number, and the user cannot approve by reflex because approval now requires deliberate input.
Passkeys and hardware keys eliminate both fatigue and phishing, because the credential is cryptographically bound to the origin. A user cannot be tricked into authenticating to an attacker’s domain, since the browser simply will not present the credential there.
Operational Measures That Help
Cap push attempts per account per hour and lock further prompts after repeated denials. Alert the security team on the pattern of repeated denials followed by an approval — that sequence is a near-certain indicator of a successful fatigue attack. Show application name, approximate location and requesting IP inside the prompt so the decision has some basis. And train users that a flood of unexpected prompts means report, not approve.
The Bottom Line
Turn on number matching everywhere today; it costs almost nothing and removes the reflex the attack depends on. Then plan migration to phishing-resistant factors for privileged accounts, because number matching narrows the window while passkeys close it.
