MFA Fatigue: Why Employees Approve the Push That Isn't Theirs

Employees approve pushes that aren't theirs because tapping "Approve" has become a reflex, not a decision. Push-bombing (also called MFA fatigue) exploits that habit: attackers already have a valid password and just need one tired, distracted, or annoyed employee to make the prompts stop. A stronger MFA app won't fix this. What works is a written rule employees actually follow, backed by settings that make the reflex harder to trigger.

What Push-Bombing Actually Does

This attack doesn't break your MFA. The attacker just needs a username and password already in hand, from a breach dump, a phishing kit, or credential stuffing. From there:

• The attacker logs in with the stolen credentials, which triggers a legitimate MFA push to the real employee's phone.

• Denied once, they try again, sometimes dozens of times, often late at night or during a known busy stretch.

• Eventually the employee, mid-meeting, half-asleep, or just done with the buzzing, taps Approve to make it stop.

• The attacker now has a fully authenticated session, indistinguishable from a normal login.

Nothing about your encryption, your password policy, or your MFA vendor failed here. A person made a split-second decision under annoyance, and the system did exactly what it was built to do: let an approved push through.

Why Habit Beats Technology Here

MFA approval is trained behavior. Employees see the prompt dozens of times a week for legitimate reasons: a VPN reconnect, an app token refresh, a new device login. Approving on sight becomes automatic, the same way people click through cookie banners without reading them.

Attackers know this. They're not trying to fool a security control; they're trying to trigger a conditioned response. That's why MFA strength alone can't close this gap. The weak point is the moment of habit, not the cryptography behind the prompt.

The Fix Is Procedural First, Technical Second

Two layers matter, and most businesses only build one:

• Technical layer: where your identity provider supports it, move to number-matching push approval (the user types a code shown on-screen instead of tapping a single button) or phishing-resistant options like passkeys/FIDO2. Also enable any built-in alerting or lockout after repeated failed or denied prompts. Most modern platforms offer this, but it's rarely turned on by default.

• Procedural layer: a written, one-line rule every employee can apply without thinking: if you get an MFA prompt you didn't just trigger by logging in yourself, deny it and report it immediately. Don't just dismiss it.

The reporting part is the piece most policies skip. An employee who quietly denies five pushes in a row and moves on has just watched an active attack and told no one. A denied-and-reported push is a signal your team can act on. A denied-and-ignored push is a near-miss nobody learns from.

A Decision Rule Employees Can Actually Use

Skip the long security-awareness deck. Give people this instead:

• Did you just try to log in yourself, right now? If yes, approve.

• If no, or if you're not sure, deny it.

• If you get more than one unexpected prompt in a short window, treat it as an active attack: deny all of them and report immediately, don't wait to see if they stop.

This is deliberately simple. Simple rules survive 2am and Monday-morning chaos; nuanced ones don't.

What To Do If You See a Burst of Denied Pushes Right Now

If your logs show repeated MFA denials for one account in a short window, don't wait for a definitive answer on whether it was "just noise." Force a password reset for that account, revoke active sessions and tokens, and check recent login activity for that user across your key systems. Treat it as a likely compromised credential first, and downgrade it later if it turns out to be nothing. Waiting for certainty is how a contained incident becomes a real one. If it does turn into something bigger, this is exactly the scenario our incident response service is built for. The goal is containing access fast, not documenting it after the fact.

In one engagement with a venture-backed technology company, our team contained an active intrusion during the assessment, a reminder that the gap between "a credential looked odd" and "an attacker has real access" can close very quickly. You can read more in the case study.

If You Don't Have a SOC Watching This

Most small and mid-size businesses don't have someone watching authentication logs at 2am, and that's a fair objection to all of the above. None of it matters if nobody sees the burst of denied pushes. Two things help without requiring a full security team:

• The policy and decision rule above cost nothing and work regardless of tooling. Put it in writing, tell people once, and reinforce it when someone reports a denied push (praise the report, don't scold the trigger).

• For the monitoring gap, you don't need to build a SOC. You need someone checking the right signal at the right time. A managed security setup or ongoing virtual CISO support can configure alerting so a burst of MFA denials reaches a person, not a log file nobody opens.

For general background on phishing-resistant authentication, CISA publishes practical guidance worth a read.

Start With a Free Review

If you're not sure whether your MFA setup, alerting, and employee policy actually close this gap, that's worth a look before an attacker finds out for you. Sheer Safe offers a free security review to help you see where the real gaps are. No pressure, no long sales process.