It wasn’t a zero-day exploit. It wasn’t sophisticated malware. In September 2022, an 18-year-old hacker broke into Uber’s entire internal network by doing one thing: sending push notifications until someone got tired enough to approve one.

That’s an MFA fatigue attack. And it’s probably the most dangerous threat your employees have never heard of.

What Is an MFA Fatigue Attack?

An MFA fatigue attack (also called push notification bombing or MFA bombing) is a social engineering technique where attackers flood a user with repeated MFA approval requests until the user — out of frustration, confusion, or exhaustion — approves one they didn’t actually request.

MFA alone doesn’t stop this. That’s the whole problem.

The attack doesn’t defeat the technology. It defeats the human using it.

The 2022 Uber breach remains the canonical case study. Lapsus$ obtained a contractor’s credentials from the dark web, then bombarded their phone with MFA push notifications for over an hour. When the contractor kept denying them, the attacker messaged them on WhatsApp, posing as Uber IT support, and said the only way to make the “glitch” stop was to approve one request. The contractor complied. Access granted.

Cisco was hit in May 2022 by a similar playbook — credentials from a personal Google account, voice phishing, and MFA push abuse that ultimately let attackers move through Cisco’s corporate network and exfiltrate data.

These weren’t amateur attacks. They were run by sophisticated groups (Lapsus$, Yanluowang, UNC2447) who specifically targeted organizations that already had MFA deployed. Because they knew: MFA without the right controls is a speed bump, not a barrier.

How the Attack Works — Step by Step

Here’s the full chain:

  1. Credential Harvesting
    Attacker obtains valid employee credentials — through phishing, a dark web data breach, or purchased from an initial-access broker. Username and password are already in the attacker’s hands.
  2. Automated Login Bombardment
    Attacker programs a script to repeatedly attempt login with those credentials. Every attempt triggers a new MFA push notification to the employee’s phone.
  3. Push Notification Spam
    In minutes, the employee’s device is buzzing constantly. Some MDM tools show attackers attempting 100+ times in an hour. The employee is receiving genuine MFA fatigue — not just inconvenience, but confusion about which requests are real.
  4. Social Engineering Layer (Optional)
    If the employee resists, attackers escalate. They may call posing as IT support, send a WhatsApp message claiming to be tech help, or email the employee directly urging them to approve “the stuck request.” The goal is to add urgency to an already-exhausting situation.
  5. User Approves Out of Frustration
    The employee hits “Approve” — either accidentally or intentionally — to make the notifications stop. At that moment, the attacker receives a valid session token.
  6. Session Token Theft & Lateral Movement
    The attacker is now inside your network with a legitimate session. They steal data, access cloud environments, pivot to other systems, or deploy ransomware. The initial access event is already done.

Key insight: The user didn’t get phished in the traditional sense. They were exhausted into approving access they understood was unauthorized — or at least suspicious.

Why SMBs Are Especially Vulnerable

Enterprise organizations have dedicated SOC analysts watching for anomalous push patterns. SMBs typically do not. Here’s what makes small and mid-sized businesses uniquely exposed:

Risk Factor Large Enterprise SMB
24/7 SOC monitoring Yes Rare
MFA vendor tier Advanced (number matching, risk-based) Often free/basic tier
Push notification rate limiting Configured Often default (unlimited)
Security awareness training Mandatory, ongoing Annual checkbox
IT staff per user High Low — one person watches everything
Phishing simulation + MFA testing Regular Rare or never

Most SMBs are running MFA on its weakest setting: basic push-only, no number matching, no rate limiting. Attackers know this. Microsoft reported ~6,000 MFA fatigue attempts per day globally in 2022–2023, and SMBs are disproportionately targeted because defenders are fewer and alerts go unmonitored.

High-value SMBs face the greatest risk:

If you serve any of these verticals, an MFA fatigue attack isn’t hypothetical — it’s a when, not an if.

What's Your MFA Fatigue Exposure?

Build a free personalized IR plan that covers MFA fatigue scenarios — tailored to your industry in 8 questions.

Build My IR Plan →

7 Controls That Actually Stop MFA Fatigue

Here’s what works. Not all of these are needed simultaneously — but each one layers on real protection.

1. Enable Number Matching or Verified Push

What it is: Instead of a simple Approve/Deny button, the employee must enter a code shown on the login screen into their authenticator app. Without the code, the push can’t be approved.

Why it works: A frustrated click on “Approve” becomes meaningless. The attacker doesn’t know the code. Microsoft calls this “application-side number matching” — it’s available in Microsoft Authenticator today.

Duo Security calls the equivalent feature “Verified Push” — the app shows the service name and IP of the login attempt, making spoofed requests obvious.

Okta FastPass uses device attestation so only enrolled, trusted devices can approve a push — making stolen session tokens from push abuse far less valuable.

Action: Go to your MFA vendor’s admin console. Find “number matching” or “verified push” and enable it for all users. This is the single highest-ROI change you can make.

2. Deploy Phishing-Resistant MFA (FIDO2/WebAuthn)

What it is: Hardware security keys (YubiKey, Google Titan) or platform-based passkeys that bind authentication to a specific website. Even if an attacker has your credentials and pushes notifications, they cannot complete login without the physical key.

Why it works: FIDO2 authentication is resistant to AiTM (adversary-in-the-middle) attacks, push notification abuse, and credential replay. NIST SP 800-63B recommends phishing-resistant authenticators for high-value accounts.

Action: Require FIDO2 security keys for: C-suite, IT admins, anyone with cloud console access, anyone with access to financial or customer data.

3. Implement Conditional Access Policies

What it is: Rules that restrict login based on device health, location, user risk score, and IP reputation. If login comes from an unknown device in an unusual country, or if the user fails MFA multiple times in a short window, the system blocks or flags it.

Why it works: An attacker can spam push notifications, but they still can’t get in if conditional access policies require a known, compliant device from a trusted location. Azure AD, Google Workspace, and Okta all support these policies.

Action: Configure your identity provider to block logins from new/unmanaged devices and flag or block repeated MFA denials (this is a signal of ongoing attack).

4. Rate-Limit Push Notification Volume

What it is: Limit how many MFA pushes can be sent to a single user within a defined time window. After X denials, lock the account or trigger a security team alert.

Why it works: The attacker can’t get enough attempts to succeed if the system caps at 3 attempts and then suspends the account or requires a help-desk verification call.

Action: Most enterprise MFA products (Microsoft, Duo, Okta) support push rate limiting in their admin console. Enable it. If your current vendor doesn’t support it, that’s a vendor upgrade trigger.

5. Train Users: Never Approve Unexpected MFA Requests

What it is: Security awareness training that specifically addresses MFA fatigue. Employees need to know:

Why it works: Training changes behavior. If an employee knows the moment they see an unexpected push that it might be an attacker — and knows the right response is to deny and call IT — you’ve killed the attack chain.

Action: Run a phishing simulation that specifically tests MFA behavior. When you see employees approving unexpected pushes in a simulated test, that’s a training gap you can close before a real attacker exploits it.

6. Configure SIEM Alerting on Repeated MFA Denials

What it is: Set your SIEM or log monitoring to fire an alert when a single user receives 5+ MFA push denials within 15 minutes. This is the operational signature of a live MFA fatigue attack.

Why it works: You catch the attack while it’s still in progress — before someone approves one. An alert triggers your IR team or MSP to contact the employee directly and freeze the account while the attack is active.

Action: If you don’t have a SIEM, this is a strong argument for one. Microsoft Sentinel, Splunk SOAR, and even Azure Monitor can all be configured to alert on this pattern. Many MSPs have this built into their monitoring stack.

7. Have a Rapid Credential Reset Playbook Ready

What it is: A documented, step-by-step incident response procedure for when an employee approves an unexpected MFA push. This shouldn’t be figured out during a crisis.

Why it works: Speed matters. The faster you can reset credentials, revoke sessions, and investigate scope, the less damage the attacker can do.

Playbook steps:

  1. Confirm employee didn’t intentionally approve a real login (they’ll tell you if it was unexpected)
  2. Immediately reset their password and revoke all active sessions
  3. Check their account for rule forwards, delegation, or authorized app grants added during the session window
  4. Check cloud admin consoles for any new privileged role assignments
  5. Scope lateral movement — did they access other systems from that session?
  6. Contact your incident response team or MSP
  7. Preserve logs — do not reset before forensics are reviewed

The 15-Minute Response Checklist: “I Just Approved a Push I Didn’t Request”

This is a live attack. Move fast.

Minutes 0–2: Contain

Minutes 2–7: Investigate

Minutes 7–15: Respond

Vendor Configuration Quick Reference

Vendor Feature to Enable Where to Find It Notes
Microsoft Authenticator Number matching Azure AD → Authentication Methods → Microsoft Authenticator → Enable “Number matching” Roll out to pilot group first; some user friction initially
Duo Security Verified Push + push rate limiting Duo Admin Panel → Policy → Authentication Policy → Enable Verified Push + set “Maximum pushes per login” Also set “Device health policy” to block unmanaged devices
Okta Push Challenge + Okta FastPass Okta Admin → Security → Authentication → Factor → Enable “Push” + enroll FastPass for high-value users Okta FastPass uses device attestation — resistant to push abuse
Google Workspace Security keys (FIDO2) required for admin accounts Google Admin Console → Security → 2-Step Verification → Enable “Security key” for super admins Enable advanced protection program for highest-risk accounts
Cisco Duo (if used) Verified push + anomaly detection Duo → Policies → Default policy → “Anomaly detection” Configure auto-lockout after 3 denied attempts

Frequently Asked Questions

What is an MFA fatigue attack?
An MFA fatigue attack (also called push notification bombing or MFA bombing) is when an attacker obtains valid credentials, then repeatedly triggers MFA push notifications to a victim’s device until the victim approves one out of frustration or confusion — granting the attacker access to the account.

How did the Uber breach happen with MFA in place?
Lapsus$ obtained a contractor’s credentials, then bombarded their phone with MFA push requests for over an hour. When the contractor resisted, the attacker WhatsApped them posing as Uber IT, claiming the only fix was to approve one request. The contractor complied, granting a valid session token. The attacker then moved through Uber’s internal network, Slack, AWS, GCP, and the HackerOne bug bounty platform.

What is the difference between MFA fatigue and MFA bombing?
They’re the same thing. “MFA fatigue” describes the psychological mechanism; “MFA bombing” describes the technical method — flooding a device with requests. Both refer to MITRE ATT&CK technique T1621: Multi-Factor Authentication Request Generation.

Can SMBs defend against MFA fatigue attacks without an enterprise security team?
Yes. The highest-impact controls (number matching, push rate limiting, conditional access) are available in most commercial MFA products at any price tier. User training specifically on MFA fatigue behavior is low-cost and high-impact. A managed MSP can handle monitoring and alerting.

Why is push-only MFA dangerous?
Push-only MFA with no number matching, no rate limiting, and no context information (no IP, device, or location shown) is trivially exploitable via fatigue. The approve button requires zero cognitive effort — which is exactly what makes it vulnerable to exhaustion-based attacks.

What’s the difference between MFA fatigue and AiTM attacks?
MFA fatigue exploits user psychology — tricking a human into approving a push they shouldn’t. AiTM (adversary-in-the-middle) attacks position a proxy between the user and the identity provider, intercepting the MFA session token as it’s issued. Many modern attacks combine both: AiTM proxies steal the token, MFA fatigue gets initial approval.

How does number matching prevent MFA fatigue?
Number matching requires the user to see a code displayed on the login screen and manually enter it into the authenticator app. Without the code, the push cannot be approved — so a frustrated click on “Approve” alone accomplishes nothing. The attacker never sees the code.

What should an employee do if they receive an unexpected MFA push?
Deny it immediately, do not approve it, and call your IT help desk to report it. A legitimate IT team will never ask you to approve a push to “stop notifications” or “fix a glitch.” Treat unexpected MFA pushes as a potential active attack until proven otherwise.

Don't wait for the push notification

Get a personalized Incident Response Plan — built for your business, delivered free.

Get My Free IR Plan →

Related Resources

Want your team to be MFA fatigue-proof? Book a Business training session — $900 flat rate, unlimited users, hands-on coaching.

Quick Test

How many MFA pushes would it take to fatigue your team?

Most employees don\u2019t know what an unexpected MFA push means. Our free 10-question Cybersecurity Scorecard measures your team\u2019s real-world readiness against MFA fatigue and credential attacks.

Take the Free Scorecard \u2192