MFA Fatigue Attacks: When “Approve” Becomes the Vulnerability

Your employee’s phone buzzes at 2:14 a.m. A login approval request appears. She ignores it. Thirty seconds later, another one arrives. Then another. By the tenth, she is half asleep, annoyed, and desperate for the noise to stop. She taps “Approve.”

That single tap is the whole attack. MFA fatigue attacks exploit human behavior rather than software flaws, and they have become one of the most reliable ways to get past multi-factor authentication. This post explains how they work, why they succeed, and what your security team can do about them.

What Is an MFA Fatigue Attack?

An MFA fatigue attack is a social engineering technique. The attacker already has a valid username and password. They trigger repeated push notifications to the victim’s phone until the victim approves one.

Security teams also call this “MFA bombing” or “push bombing.” The name matters less than the mechanism. The attacker does not break the authentication system. They pressure the person who operates it.

Notice what the attacker needs first: working credentials. That detail shapes everything else in this article. Fatigue attacks are a second-stage move. Something has already gone wrong before the first push notification fires.

Why Push-Based MFA Created This Opening

Push notifications became popular because they are easy. Users see a prompt, tap a button, and move on. No codes to copy, no apps to switch between. Adoption went up, and so did user satisfaction.

The same simplicity creates the weakness. A basic approve/deny prompt carries almost no context. The user often cannot tell where the request came from, which application triggered it, or whether it matches anything they just did.

Compare that to typing a six-digit code. Entering a code requires a deliberate action tied to a specific login. Tapping “Approve” takes less than a second and requires no proof that the person is actually the one logging in.

Attackers understand this gap. They do not need to defeat encryption. They only need one tired, distracted, or confused person to tap the wrong button.

How the Attack Unfolds, Step by Step

Most fatigue attacks follow a similar pattern. The details vary, but the structure stays consistent.

Step 1: Obtain valid credentials. Attackers buy leaked passwords, run credential stuffing against reused logins, or phish them directly. Stolen credentials sell cheaply on criminal marketplaces.

Step 2: Start the login attempt. The attacker enters the credentials on a real login page. The legitimate MFA system sends a push to the victim’s registered device.

Step 3: Repeat the prompts. The attacker triggers request after request. Some do it in a rapid burst. Others space them out over hours to avoid looking automated.

Step 4: Add pressure through a second channel. Skilled attackers do not rely on notification volume alone. They message or call the victim while posing as IT support, claiming the prompts are a known glitch that “Approve” will fix.

Step 5: Gain access. One tap, and the attacker holds a valid authenticated session. From there they can read email, reach internal systems, register their own MFA device, and move laterally.

Step 4 is where many attacks succeed. A stream of prompts creates confusion. A confident voice offering an explanation turns that confusion into compliance.

A Realistic Scenario: The Finance Analyst at 11 p.m.

Consider a mid-sized logistics company with about 600 employees. A finance analyst, call her Elif, uses the same password for her work email and a freight-industry forum. That forum suffers a breach. Her email and password end up in a dump that circulates for weeks.

An attacker finds her credentials and tries them against the company’s Microsoft 365 login. The password works. MFA kicks in and sends a push to Elif’s phone.

It is 10:50 p.m. on a Tuesday. Elif is watching television with her phone on the couch. She sees the notification, does not recognize it, and taps “Deny.” The attacker tries again. Deny. Again. Deny.

After a few minutes, the attacker pauses. Then Elif’s phone rings. The caller ID shows a number that looks internal. A calm voice says, “Hi Elif, this is Marco from the IT service desk. We’re seeing a sync issue on your account tonight. You’re getting a bunch of prompts from us. Just approve the next one and it will clear.”

Elif is tired. The caller knows her name. The explanation sounds plausible, and she has seen odd IT behavior before. She approves the next request.

The attacker now has access to her mailbox. Within an hour, they set up a forwarding rule, read recent invoice threads, and register a new authenticator on her account for persistence. By morning, they have sent a convincing “updated bank details” email to a supplier.

Nothing in this story required advanced hacking. It required a leaked password, a phone number, and a believable script. Every step used a legitimate, working security control against the person it was meant to protect.

Why Smart, Trained People Still Approve

Security teams sometimes treat these incidents as user error. That view misses the point. People approve fraudulent prompts for understandable reasons.

Alert fatigue is real. Employees see many authentication prompts across tools and devices. Approving them becomes muscle memory. A prompt that interrupts a task feels like friction, and people want friction gone.

Timing creates vulnerability. Attackers often strike late at night, early in the morning, or during busy periods. Tired and distracted people make worse decisions.

Repetition wears down resistance. Each denied prompt costs a little attention and patience. Persistent prompts shift the easiest path from “Deny” to “Approve and make it stop.”

Authority and plausibility work. A caller claiming to be IT support exploits a normal assumption. Employees expect IT to occasionally ask them to do things. Without a clear verification habit, they follow along.

The prompt gives no context. If the notification says only “Approve sign-in?”, the user has to guess. Guessing under pressure rarely goes well.

Understanding these factors matters because it changes the response. If you treat fatigue attacks as carelessness, you lecture people. If you treat them as a design and behavior problem, you fix the system and the habits together.

The Warning Signs Your Team Should Recognize

Both employees and security staff benefit from knowing what an attack looks like. Training should cover these signals.

For employees:

• Receiving an MFA prompt they did not trigger
• Receiving several prompts in a short period
• Getting a call, text, or chat message right after prompts begin
• Hearing a request to “just approve it” from anyone, for any reason

For security teams, look in the logs:

• Multiple failed or denied MFA attempts for one account in a short window
• Sign-in attempts from unfamiliar locations or devices followed by a successful approval
• New MFA device registrations shortly after an unusual login
• Logins at odd hours for the user’s normal pattern

An approval that follows a run of denials deserves close attention. It may be the moment the attacker finally got through.

What Security Teams Can Do Right Now

You can reduce your exposure to MFA fatigue without a major project. The steps below range from quick configuration changes to longer-term investments.

Turn on number matching

Number matching asks the user to type a number shown on the login screen into their authenticator app. A blind “Approve” tap no longer works. The user must see the real login attempt to complete it. Most major identity platforms now support this, and it removes a large share of the risk.

Show context in the prompt

Enable additional context such as the application name and geographic location. A prompt that reads “Sign-in to Payroll from Lagos, Nigeria” gives the user a reason to hesitate. A bare approval request does not.

Limit prompt volume

Set rate limits and lockouts on repeated MFA requests. After a handful of denied or ignored prompts, block further attempts and flag the account for review. Attackers rely on unlimited retries.

Move toward phishing-resistant authentication

Hardware security keys and passkeys based on FIDO2 standards do not use push approvals. They tie authentication to the legitimate site and the physical device. For high-risk roles such as administrators, finance, and executives, this is the strongest option available.

Establish a clear “report, do not approve” rule

Give employees one simple instruction. If you receive an MFA prompt you did not start, deny it and report it immediately. Make reporting fast, with a single button or a dedicated channel. Tell people plainly that nobody will be punished for reporting a false alarm.

Verify IT contact through a second channel

Make it a standing policy that IT support never asks users to approve a prompt over the phone. If someone calls claiming to be IT, the employee hangs up and contacts the service desk through a known number. Repeat this rule often.

Monitor and respond to anomalies

Build alerts around bursts of MFA failures, impossible travel, and new device registrations. Pair detection with a tested response playbook. When a fatigue attempt appears, your team should know to reset the password, revoke sessions, review recent account activity, and check for rogue MFA devices.

Fix the root problem: stolen credentials

Fatigue attacks only work when the attacker holds valid credentials. Reduce password reuse, enforce unique passwords through a manager, and watch for your organization’s credentials appearing in breach data. Cutting off the first stage makes the second stage impossible.

A Quick Checklist

Use this list to assess where you stand today.

1. Is number matching enabled for all push-based MFA?
2. Do prompts display application and location context?
3. Are repeated MFA requests rate-limited?
4. Do high-risk roles use phishing-resistant authentication?
5. Can employees report a suspicious prompt in under a minute?
6. Does policy forbid approving prompts at the request of a caller?
7. Do you alert on MFA denial bursts and new device registrations?
8. Do you know which employee credentials already appear in breach data?

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

Technology Alone Will Not Close the Gap

Configuration changes matter, but they do not cover everything. An attacker with a convincing phone script can still talk a person into entering a number or reading out a code. Technical controls reduce the opportunity. Human judgment handles the rest.

That judgment improves with practice. Employees who have never seen a fatigue attack will treat the first one as a confusing IT problem. Employees who have experienced a realistic simulation recognize the pattern and respond correctly. The difference shows up in the first thirty seconds, which is often all that matters.

Annual slide-deck training rarely builds this reflex. People forget policy documents. They remember situations they have lived through, even simulated ones. Repetition, realistic scenarios, and quick feedback do more than a yearly compliance module.

How Cruxroot Helps Address the Problem

Cruxroot supports the human side of MFA fatigue defense, alongside the technical controls described above. Three parts of the platform map directly to the weak points in this attack chain.

Phishing simulations. Attackers often obtain credentials through phishing, and fatigue attacks often arrive with a social engineering follow-up. Cruxroot’s phishing simulations let your organization test how employees respond to realistic lures and pressure tactics. Results show you where habits are strong and where they need work. These simulations do not replace technical defenses. They reveal the gaps those defenses need to cover.

Dark web monitoring. Since fatigue attacks depend on valid credentials, knowing which of your employees’ credentials are already exposed gives you a head start. Dark web monitoring alerts your team when company email addresses and passwords appear in breach data. You can force resets before an attacker uses the stolen login. No monitoring service sees everything, but earlier warning beats none.

Gamified training. Short, interactive modules keep security awareness active rather than annual. Employees practice recognizing unexpected prompts, resisting urgent callers, and reporting incidents quickly. Gamification helps people stay engaged, which improves how much they retain. It works best as a steady habit, not a one-time event.

Through your MSP partner, these tools fit alongside the identity and access controls you already run. Your partner can help configure them to match your risk profile and staffing.

Conclusion

MFA fatigue attacks work because they turn a security control into a pressure point. The attacker does not need to break anything. They need one person to tap “Approve” at the wrong moment.

The defense has two layers. Configure your authentication to remove blind approvals, limit prompt volume, and protect high-risk accounts with phishing-resistant methods. Then train your people to deny, report, and verify, so they handle the next unexpected prompt with confidence rather than confusion.

Start with the checklist above. Fix the quick wins this week. Build the longer-term habits over the coming months. Your approval button should protect the business, not expose it.

Check our latest the blog regarding QR Code Phishing (Quishing): Why a Simple Square Is Slipping Past Your Defenses