MFA Fatigue Attacks: When “Approve” Becomes the Vulnerability

Multi-factor authentication was supposed to close the door on stolen passwords. For years, it did a good job. Then attackers found a way around it that requires no malware, no exploit, and no clever code. They simply ask the user to let them in, again and again, until the user says yes.

MFA fatigue attacks are one of the cleanest examples of a technical control defeated by human behavior. The control works exactly as designed. The person holding the phone is the weak point. This post explains how these attacks unfold, why they work on smart people, and what security teams can do about them.

What Is an MFA Fatigue Attack?

An MFA fatigue attack (also called MFA bombing or push bombing) abuses push-based authentication. The attacker already holds a valid username and password. They try to log in, which triggers an approval request on the victim’s phone. The victim did not start that login, so they deny it. The attacker tries again. And again.

The goal is volume and annoyance. Some attackers send dozens of prompts over an hour. Others space them out over days. Eventually the target taps “Approve,” either by mistake, out of exhaustion, or because they just want the notifications to stop.

That single tap gives the attacker a fully authenticated session. From the system’s point of view, a legitimate user approved a legitimate login. No alarm fires.

Why Push Notifications Became the Target

Push-based MFA is popular for good reasons. It is fast, it needs no code entry, and employees like it. Compared with SMS codes, it also resists some interception techniques.

The problem is the design of the approval itself. A standard push prompt asks a binary question: approve or deny. It often gives the user little context. There may be no clear location, no application name, and no way to tell a real login from a fake one.

Attackers noticed this gap. If the only barrier is a single tap, then the barrier is only as strong as the user’s attention at that moment. Attention is a poor thing to build a security control on.

How the Attack Unfolds

Most MFA fatigue attacks follow a predictable pattern. Understanding each stage helps teams spot where to interrupt it.

Stage one: credential acquisition. The attacker needs a valid password first. They get it from phishing pages, infostealer malware, credential dumps from older breaches, or password reuse across accounts. Without this step, the attack cannot start.

Stage two: the prompt flood. The attacker logs in repeatedly. Each attempt sends a push to the victim’s registered device. Timing matters. Many attackers deliberately strike late at night or early in the morning, when people are tired and less careful.

Stage three: social pressure. Some attackers add a second channel. They message or call the victim, pose as IT support, and say the prompts are a system glitch. They ask the user to approve one request “to clear the queue.” This combination is very effective because it gives the confused user a reason to comply.

Stage four: access and movement. Once approved, the attacker has a session. They check what the account can reach, register their own MFA device so they keep access, and look for ways to move deeper into the environment.

A Realistic Scenario: The 11 PM Prompt Storm

Consider a finance analyst at a mid-sized logistics company. Call her Elif. She uses push-based MFA for her email and her company VPN.

Months earlier, Elif used her work email to sign up for a freight-tracking portal. That portal later leaked its user database. Elif had reused a password variation across both accounts. A credential buyer sorted the leaked data by company domain and tested her login against the company’s VPN.

At 11:07 PM on a Tuesday, her phone buzzes. An approval request appears for her VPN login. She did not start it. She taps Deny and goes back to her show.

Four minutes later, another buzz. Then another. By 11:40 PM, she has received more than a dozen. She is tired, annoyed, and slightly worried. She considers turning her phone off.

At 11:45 PM, she gets a Teams message from an account labeled “IT Service Desk.” It reads: “We are seeing a sync issue on your account. Please approve the next prompt so we can reset it.” The message looks plausible. The name and logo seem right. The prompts have been relentless, and this explanation makes sense.

Elif taps Approve.

Within minutes, the attacker is on the VPN. They enroll a new authenticator app on her account, so even if she changes her password the next morning, they still have a second factor under their control. Over the next two days, they read her mailbox, find invoice approval workflows, and prepare a payment redirection attempt.

Nobody broke the MFA product. Nobody exploited a vulnerability. The company had MFA, and it was running exactly as configured. The attack succeeded because the approval step required no thought, and because the user had no clear way to verify the “IT” message.

Why Smart People Fall for It

It is tempting to call this a user error. That framing misses the point. The attack is designed to exploit predictable human responses, not stupidity.

Several psychological factors combine here:

• Alert fatigue. Employees see dozens of notifications daily. Authentication prompts blend into that stream.
• Desire for relief. Repeated interruptions create stress. Approving ends the stress immediately.
• Authority and context. A message from “IT” explaining the prompts removes doubt at the exact moment doubt is useful.
• Time pressure and tiredness. Attackers choose hours when judgment is weakest.
• Habit. People approve legitimate prompts all day. The motion becomes automatic.

A well-run attack stacks several of these at once. Even trained, careful employees can slip when three or four line up.

Signs of an MFA Fatigue Attempt

Detection matters, because the user may not report what happened. Security teams can watch for these indicators:

• Multiple failed or denied MFA prompts in a short window for one user
• Authentication attempts from unusual locations or unfamiliar IP ranges
• A successful approval soon after a long string of denials
• A new MFA device or authenticator registration right after a login
• Logins at odd hours that do not match the user’s normal pattern
• Users reporting unexpected prompts or odd “IT” messages

The sequence matters most. Ten denials followed by one approval is a very different signal from ten denials alone. Many identity platforms can alert on this pattern if someone configures the rule.

What Security Teams Can Do Right Now

You cannot remove the human from authentication. You can, however, make the approval step much harder to abuse. The following steps give the best return for most organizations.

Move Toward Number Matching

Number matching shows a code on the login screen. The user must type that code into the authenticator app to approve. A person who did not start the login has no code to enter. This single change defeats the blind-tap approach that fatigue attacks rely on. Most major identity providers support it, and many now enable it by default.

Add Context to Prompts

Configure prompts to show the application name and the approximate location of the request. A prompt that says “Sign in to VPN from a country you have never visited” is easy to reject. A bare “Approve?” is not.

Consider Phishing-Resistant Methods

Hardware security keys and passkeys (FIDO2) bind authentication to the legitimate site and the physical device. There is no push to approve and nothing to type into a fake page. For administrators and high-value accounts, prioritize these first. Full rollout takes time and budget, so a phased plan works well.

Rate-Limit and Lock on Repeated Prompts

Set a threshold for denied or ignored prompts. After a handful of attempts, temporarily lock the account or require a stronger method. This cuts the attacker’s volume advantage.

Alert on the Right Patterns

Build detection rules around denial-then-approval sequences, new device enrollments, and impossible travel. Send these alerts to someone who will act on them quickly. An alert nobody reads is the same as no alert.

Protect MFA Enrollment

Many fatigue attacks end with the attacker registering a new device. Require stronger verification before new MFA methods can be added. Notify the user through a separate channel whenever a new device is enrolled.

Tighten the Help Desk Process

Attackers often impersonate IT, and sometimes they target the real help desk instead. Define how IT will and will not contact employees. A simple rule works well: IT never asks you to approve a prompt you did not trigger. Publish that rule where employees will see it.

Reduce Password Reuse and Credential Exposure

The attack needs a valid password. Encourage password managers, enforce unique credentials, and check for exposed accounts regularly. Cutting off the first stage makes everything else harder.

Give Employees a Clear Reporting Path

Make it easy to say “I keep getting prompts I didn’t trigger.” Employees should know who to tell, and they should never worry about blame. A quick report at prompt number three is worth far more than silence until prompt number thirty.

A Short Checklist for Your Next Review

Use this list in your next security review or tabletop exercise:

1. Is number matching or an equivalent control enabled for all push-based MFA?
2. Do prompts show application and location details?
3. Are privileged accounts using phishing-resistant authentication?
4. Do alerts exist for repeated denials followed by an approval?
5. Are new MFA device enrollments verified and reported to the user?
6. Do employees know that IT will never ask them to approve an unexpected prompt?
7. Is there a simple, blame-free way to report suspicious prompts?
8. Have you tested all of this with a realistic exercise, not just a policy document?

If you answer “no” or “not sure” to more than two of these, you have meaningful exposure.

Training Employees to Recognize and Resist MFA Fatigue

Technical controls reduce the attack surface. They do not remove it. Some prompts will still reach users, and some users will still face pressure from a convincing fake IT message. That is why awareness training matters here.

Effective training for this threat goes beyond a slide that says “never approve unknown prompts.” It should do three things.

First, it should explain the attack in plain language, with a story like the one above. People remember stories better than rules. Second, it should give employees a clear script: deny, do not respond to chat messages, report immediately. Third, it should let them practice the decision under realistic conditions, so the correct response becomes a habit before the real attack arrives.

Repetition matters too. A single annual session fades quickly. Short, frequent exposures keep the behavior fresh without burying people in content.

Where Cruxroot Fits

The attack chain behind MFA fatigue starts long before the first prompt. It starts with a stolen password and ends with a human decision. Cruxroot addresses both ends of that chain.

Dark web monitoring helps you find exposed credentials early. If employee email addresses and passwords show up in leaked data, you can force resets before an attacker tries them. That removes the first ingredient of the attack. It does not catch everything, since not all leaks surface publicly, but it shrinks the window of opportunity.

Phishing simulations let you test how employees react to social engineering, including fake IT messages and credential harvesting pages. You see where people hesitate, where they click, and where they report. Those results show which teams need more support.

Gamified training keeps awareness practical and engaging. Employees work through realistic scenarios, such as repeated prompts followed by a convincing “IT” message, and learn the right response by doing. Short sessions with clear feedback tend to stick better than long compliance modules.

None of these tools replaces strong technical controls. Number matching, phishing-resistant authentication, and good detection remain essential. Cruxroot works alongside them, covering the human layer that those controls cannot fully reach. Through your MSP partner, these capabilities can be deployed and managed across your organization without adding a heavy burden to your internal team.

Conclusion

MFA fatigue attacks work because they target a moment, not a system. The attacker needs one tired, confused, or pressured person to tap a button. Technology can make that moment safer through number matching, better context, and phishing-resistant methods. Awareness can make the person at the center of it better prepared.

The strongest approach combines both. Fix the approval step. Watch for the warning patterns. Train people to deny, report, and ignore anyone telling them otherwise. When “Approve” stops being an easy answer, the attack loses most of its power.

Check our latest the blog regarding Tailgating and Physical Social Engineering: The Attack Your Firewall Can’t Stop