Push notification authentication verifies a login by sending an approval prompt to a trusted app on the user’s registered device; the user taps "approve" or "deny" to confirm. It’s smoother than typing a code and binds the approval to a device the user already has.

Push is a step up from OTP in usability (no code to read and type) and it can carry context (where and when the login is happening) to help the user judge whether to approve.

How push authentication works

After a first factor, the service sends a signed push to the user’s registered app. The prompt typically shows details of the login attempt. The user approves or denies, and the app returns a cryptographically signed response confirming possession of the trusted device. Because the approval is tied to the device and (in stronger implementations) to the specific request, it resists some replay attacks better than a typed code.

The MFA fatigue problem

Push has a specific, notorious weakness: MFA fatigue, also called prompt bombing. An attacker who already has the password triggers login after login, flooding the victim with approval prompts, betting they’ll eventually tap "approve" out of annoyance or confusion. This has been behind several high-profile breaches. Defenses include number matching (the user must enter a number shown on the login screen), showing rich context, rate-limiting prompts, and (most effectively) risk-based logic that suppresses or hardens prompts when the pattern looks like an attack.

Push vs. phishing-resistant methods

Basic push is not fully phishing-resistant: a real-time phishing proxy can trigger a legitimate-looking prompt the user approves. Number-matching and context help, but the strongest path remains passkeys, where approval is cryptographically bound to the correct origin. Push is a reasonable, user-friendly factor, best deployed with number matching and risk-based controls rather than as a naked approve/deny.

Defending push against fatigue attacks

Because prompt bombing is push’s signature weakness, the defenses against it are worth spelling out. Number matching is the most effective: instead of a simple approve/deny, the user must enter a number shown on the login screen into their authenticator, which is impossible if they’re not actually looking at a legitimate login. Rich context (showing the location, app, and time of the request) helps the user judge whether a prompt is real. Rate limiting caps how many prompts an attacker can fire, blunting the "spam until they cave" tactic. And risk-based logic can suppress or harden prompts entirely when the pattern looks like an attack, rather than dutifully forwarding every one.

Even with these, basic push isn’t fully phishing-resistant, a real-time proxy can trigger a legitimate-looking prompt the user approves. Number matching and context narrow that window considerably, but the strongest end state remains passkeys, where approval is cryptographically bound to the correct site and can’t be relayed. The practical guidance: if you use push, never ship it as a naked approve/deny: pair it with number matching, context, and risk-based controls, and treat it as a stepping stone toward phishing-resistant authentication.

Frequently asked questions

What is push authentication?

A method where the user approves a login via a prompt on their trusted device app.

What is MFA fatigue?

An attack that spams approval prompts hoping the user eventually taps approve; also called prompt bombing.

How do you defend against prompt bombing?

Number matching, rich context, rate limiting, and risk-based suppression of suspicious prompts.

Related: MFA Fatigue / Prompt Bombing · Multi-Factor Authentication (MFA) · Passkeys · Risk-Based Authentication