MFA Fatigue Approval: When “Approve” Becomes Your Weakest Link

Multi-Factor Authentication (MFA) is now a baseline control in most organizations. We pat ourselves on the back once MFA is enabled for everyone and move on to the next security project.

But attackers haven’t stopped. Instead, they’ve adapted.

One of the most effective techniques they use today is MFA fatigue (also called MFA fatigue approval, push bombing, or MFA spamming). Instead of breaking crypto, they simply annoy your users into approving a malicious sign-in.

In this post, I’ll walk through what MFA fatigue approval is, how the attack works end-to-end, and what you can do as an engineer or security admin to defend against it.

What is MFA fatigue approval?
In many environments, users approve sign-ins through a simple push notification:

“Are you trying to sign in?”
[Approve] [Deny]

MFA fatigue approval happens when an attacker:

1. Obtains a valid username and password, and
2. Keeps triggering MFA prompts repeatedly,
3. Until the user, out of frustration or confusion, finally taps “Approve”.

The underlying authentication protocol still works as designed. The weakness is the user’s decision under pressure.

MFA is still better than passwords alone, but if the user approves anything that pops up on their phone, the effective security is close to zero.

How attackers run MFA fatigue attacks
Let’s break down a typical attack flow.

1. Steal credentials
First, the attacker needs valid credentials. Common sources:

1. Phishing pages imitating common login portals
2. Password reuse across multiple sites
3. Credentials for sale from previous breaches
4. Infostealer malware that exfiltrates browser-saved passwords

Once they have user@company.com and the password, MFA becomes the only thing standing in their way.

2. Trigger repeated MFA prompts
The attacker starts logging in again and again to the target service:

1. Each attempt sends a legitimate MFA prompt to the user’s phone or authenticator app.
2. Some attackers script this to fire prompts in bursts or at random intervals.
3. Others specifically target late-night hours when the user is tired and less careful.

The goal is not to bypass MFA technically. The goal is to wear down the human.

3. Add social engineering
To increase success, attackers often combine the prompts with social engineering, for example:

Calling the user pretending to be IT support:

1. We are doing an MFA system test. Please approve the next prompt you see.
2. Sending a fake “helpdesk” email instructing them to approve a series of prompts.

Now the user is receiving multiple notifications and a “helpful” voice tells them it’s all normal.

1. The one wrong tap
   After enough prompts:

2. The user is annoyed: “Let me just approve this so it stops.”

3. Or they are half asleep and assume, “Maybe something is syncing in the background.”

4. Or they trust the fake IT call and think they’re helping.

They tap Approve once.

That single approval hands the attacker a valid session token, and from that point, it becomes a standard post-compromise scenario.

5. Post-compromise actions
Once inside, attackers can:

1. Access email and collaboration tools
2. Search for sensitive data (contracts, credentials, internal docs)
3. Register their own MFA device for persistence
4. Elevate privileges, move laterally, and in worst cases, deploy ransomware

All of this started from an MFA-protected account.

Why this technique works so well
MFA fatigue approval is powerful because it attacks human behavior and UX, not the math.

A few reasons it’s so effective:

Notification overload
Users receive many prompts and alerts daily. A few more don’t stand out.

Bad habits
Some users approve out of routine without carefully reading the prompt.

Poor context
Many MFA prompts don’t clearly show location, device, or app. Users approve blindly.

Time pressure & annoyance
Late-night or repeated prompts create stress. People want them to stop.

Imperfect training
Users are told “MFA makes you safe”, but rarely taught “Unexpected prompts = active attack”.

If your environment relies purely on tap approve MFA without guardrails, you are vulnerable to this even if “MFA is enabled for everyone”.

How to detect MFA fatigue attacks
You can’t defend what you can’t see. Typical detection indicators include:

Multiple MFA prompts for one user in a short time window
Example: 15 MFA attempts in 5 minutes.

Many denied requests followed by a single successful approval
Pattern: deny, deny, deny, approve.

Unusual times and locations
Successful approval at unusual hours, or from a location/device that doesn’t match the user’s normal pattern.

Helpdesk tickets about “weird MFA spam”
Users complain they keep getting prompts they didn’t initiate.

If you have access to your identity provider or SIEM logs, building alerts around these patterns is a great starting point.

Technical defenses against MFA fatigue approval
Now, let’s get to the part that matters: what you can actually do.

1. Replace “Approve/Deny” with number matching or codes
   The most impactful change:

2. Instead of a generic approve/deny push, require the user to

3. enter a number shown on the login screen, or

4. enter a verification code from the app.

This forces a tight binding between the login session and the device. An attacker who only has the password and can’t see the login screen can’t guess the number.

It also forces the user to pay more attention: it’s harder to “mindlessly approve” when you have to type something.

2. Enrich MFA prompts with context
Give users enough data to make a good decision:

1. Where is this request coming from? (City, country)
2. What is being accessed? (App/resource)
3. Which device or browser is used?

If a user is sitting in India and sees a prompt from a login in another country at 3 a.m., they should instantly know: this is not me.

3. Limit MFA prompt retries
Don’t let attackers spam your users indefinitely.

1. Set rate limits on MFA attempts per user per time window.
2. After several failed or denied attempts, temporarily block further prompts.
3. Require additional verification or helpdesk interaction if there’s a spike in MFA failures.

This both protects users and gives your security team a signal that something suspicious is happening.

4. Use stronger, phishing-resistant methods where possible
For high-value accounts (admins, finance, executives), consider moving beyond push-based MFA:

1. FIDO2 security keys / hardware tokens
2. Platform authenticators tied to specific devices
3. Certificate-based authentication

These methods remove the “tap approve” surface entirely and are much harder to abuse remotely.

5. Hardening privileged and cloud admin accounts
MFA fatigue against admin accounts is particularly dangerous.

For privileged roles:

1. Require MFA on every sign-in, no long “remember this device” window.
2. Restrict admin sign-in to dedicated, hardened devices and locations.
3. Use just-in-time elevation (PIM-style) so users are not permanently privileged.
4. Combine Conditional Access-like rules: device compliance, location, risk signals.

Even if an attacker manages one approval, they still have a much harder time escalating.

The human side: training users to say “No”
Technology alone won’t solve MFA fatigue approval. You also need user education.

Key messages for users:

Never approve a prompt you didn’t initiate.
If you’re not currently logging in, treat the prompt as an attack.

Multiple prompts = red flag.
If you get repeated prompts, don’t ignore them—report them immediately.

IT will never ask you to approve random MFA prompts.
Any call, chat, or email asking you to “help test MFA by approving” is suspicious.

A simple rule you can include in internal training:

If you’re not logging in right now and you see an MFA request, always deny it and notify IT.

Final thoughts

MFA is essential, but it’s not magic. If your users are one annoyed tap away from compromise, you haven’t closed the loop.

1. To reduce the risk of MFA fatigue approval:
2. Move beyond simple push approvals.
3. Add context and friction where it matters.
4. Monitor for suspicious MFA patterns.
5. Train users to treat unexpected prompts as an active security incident.