Push Fatigue Attacks are a form of social engineering that targets people who approve login requests on their phones. An attacker who already has your password repeatedly triggers approval prompts until you tap approve by mistake, or out of frustration.
Multi-factor authentication is still a strong defense, but it depends on the person answering the prompt. This article explains how the attack works at a conceptual level, why it succeeds, and what individuals and organizations can do to make it far less likely to work.
When Your Phone Keeps Buzzing at Midnight
Imagine receiving a notification from your work email provider at two in the morning, asking you to approve a sign-in from an unfamiliar location. You decline it, then another arrives a minute later, and another after that. By the tenth prompt, you may feel annoyed enough to tap approve just to make the buzzing stop.
That moment of exhaustion is the core of the problem. The attacker does not need to break your cryptography or guess a code. They only need you to accept one request in a sea of requests you never asked for.
Understanding this pattern helps you recognize it when it happens and respond calmly instead of reacting on autopilot to a stream of notifications.
What a Push Fatigue Attack Actually Is
A push notification multi-factor authentication method sends a prompt to an app on your phone, which asks you to approve or deny a sign-in attempt. This is a convenient second factor, because it does not require typing a code. The security depends on the assumption that you will only approve requests you initiated.
In a push fatigue attack, an adversary who has already obtained your username and password begins the sign-in process repeatedly. Each attempt sends a fresh prompt to your device. The goal is to wear down your attention until you approve one, either by accident, by confusion, or because you believe the requests are a system glitch that approval will fix.
The attack is less about technology and more about human behavior. It exploits the gap between how a security control is designed and how a tired person actually responds to it.
Common Signs That an Attack Is Underway
Recognizing an attack early gives you time to respond before any damage occurs. The following signs commonly appear when someone is attempting to exploit repeated prompts:
- You receive several approval requests within a short period that you did not initiate.
- Prompts arrive at unusual hours, such as late at night or early in the morning in your time zone.
- The sign-in details shown, such as location, device, or application name, do not match anything you were doing.
- The same request repeats after you have already denied it, sometimes with only minor changes.
- You receive a message or call from someone claiming to be from IT or support, urging you to approve the request to stop the alerts.
If you notice one or more of these signs, do not approve any pending request. Deny them, change your password from a device you trust, and review your account’s recent sign-in activity. Reporting the event to your employer or account provider helps them investigate and protect others who may be targeted by the same campaign.
Why Attackers Use the Prompt Flood Approach
Attackers usually choose push-based flooding because it is cheap and scalable. Once they have a valid password, sending repeated sign-in attempts costs them very little, and each attempt has some chance of producing a response from the target. Even a small percentage of accepted prompts can be enough to gain access.
The approach also works well against people who are busy, distracted, or unfamiliar with how their authentication app behaves. A person who does not know whether the system sends duplicate prompts may assume the repetition is normal and approve one out of habit.
Because the attacker controls the timing, they can wait for a moment when the target is likely to be distracted, such as during a meeting or while commuting. This is why defenses that rely only on user judgment are fragile.
Understanding the Tradeoffs in Push-Based Multi-Factor Authentication
Push notifications are popular because they are easy to use. Compared with typing a six-digit code, tapping approve is quick and reduces friction for employees and everyday users. This convenience is a real benefit, and it is one reason many organizations adopted push-based MFA quickly.
The tradeoff is that approval becomes a single tap, which lowers the cost of a mistake. A code that must be typed into the login screen forces a deliberate step, whereas a prompt can be accepted without much thought. Understanding this difference helps teams decide where push fits and where stronger options are needed.
No single method is perfect. The right choice depends on the risk level of the account, the user population, and whether other controls, such as device-bound or phishing-resistant methods, are available.
Practical Defenses for Individuals and Organizations
Defending against push fatigue combines technical settings, user habits, and clear procedures. Each measure reduces the chance that a flood of prompts will succeed, even when a password has already been exposed.
Use Number Matching on Approval Prompts
Number matching requires the user to type or select a short number shown on the sign-in screen into the authenticator app before approving. This forces the person to look at the login attempt and confirm the context, which breaks the reflexive tap that fatigue attacks rely on.
Many authentication platforms offer number matching as a setting. Enabling it is one of the most effective and least costly steps an organization can take, because it turns a passive approval into a deliberate action that a rushed or confused user is less likely to complete by accident.
Limit Prompt Frequency and Add Context
Authentication systems can be configured to limit how many push requests a user receives within a time window, and to show additional details such as the approximate location, device type, and application being accessed. Clear context helps people spot requests that do not match their own activity.
Administrators should review these settings periodically, because defaults vary by product and may change over time. Pairing rate limits with alerts to security staff allows a flood of prompts to be investigated rather than silently absorbed by the user.
Teach Users to Deny and Report
Training should make clear that an unexpected prompt is a reason to deny and report, never a reason to approve. Users should know that legitimate IT staff will not ask them to approve a request to stop alerts, and that a real login problem can be solved through a verified support channel.
A simple rule works well: if you did not start the sign-in, deny it. If prompts continue, contact your help desk using a number or address you already trust, not one given to you during the event.
Stronger Authentication Options to Consider
For high-value accounts, organizations often move beyond push approval to methods that resist phishing and fatigue. Phishing-resistant options, such as security keys that use public-key challenges tied to the website’s origin, do not rely on the user deciding whether a prompt looks legitimate.
FIDO2 is a family of standards that includes WebAuthn, which lets a browser and a hardware or platform authenticator prove possession of a private key without transmitting a reusable secret. Because the response is bound to the site being accessed, a fake login page cannot easily reuse it.
Choosing a method involves tradeoffs in cost, device support, and user experience. Teams should evaluate options against their specific threat model rather than assuming one approach fits every account.
What to Do If You Already Approved a Request
If you approved a prompt you did not intend to, act quickly. Change the password for that account from a device you trust, sign out of all active sessions if the service offers that option, and remove any unfamiliar authenticator devices or recovery methods you do not recognize.
Next, review recent account activity for forwarding rules, new connected apps, changed contact details, or unusual file access. Attackers who gain access often try to establish persistence, so checking these areas helps you find traces of misuse.
Report the incident to your employer’s security team or your account provider. Clear reporting helps responders identify the scope of a campaign and may protect colleagues or other customers who received similar prompts.
Checklist for Reducing Push Fatigue Risk
The following checklist summarizes the steps most people and organizations can take. Not every item applies to every setting, but reviewing each one helps identify gaps.
- Confirm that number matching is enabled wherever push-based approval is used for sign-in.
- Review how many push requests a user can receive in a short period, and set reasonable limits.
- Make sure approval prompts show the application, location, and device so users can judge them.
- Train users to deny unexpected prompts and to report repeated requests through a verified channel.
- Plan stronger, phishing-resistant options for administrators and other high-privilege accounts.
Checking these items periodically keeps defenses aligned with how attackers change their methods. Because product features and default settings evolve, consult your authentication provider’s current documentation when you configure or audit these controls.
Building a Calmer Approach to Login Alerts
The most resilient approach treats a login prompt as a question that requires a considered answer, not a nuisance to be silenced. When people understand why an unexpected request is suspicious, they are far less likely to approve it under pressure.
Looking ahead, authentication systems are moving toward methods that make a fatigue attack much harder to execute, including phishing-resistant keys and device-bound credentials. Adopting these gradually, starting with the accounts that matter most, is a practical way to reduce exposure over time.
Start this week by checking your own approval settings, enabling number matching where it is available, and agreeing with your household or team on a simple rule: deny first, then report. Small habits like these steadily make repeated prompts far less effective.