🔓 MFA Fatigue Attacks: How Push Bombing Bypasses Your Second Factor (2026 Guide)

In September 2022, Uber’s corporate Slack, internal dashboards, and security tools were all compromised in a single evening — not by cracking any encryption, but by sending MFA push notifications to a contractor until they finally clicked Approve. MFA fatigue attacks require no exploit code and no zero-day; they exploit the most predictable vulnerability in any security system: human patience runs out.

The attack bypasses multi-factor authentication entirely by targeting the human layer. An attacker with your username and password can trigger an unlimited stream of “Did you just sign in?” push notifications. Eventually, many people approve one — and that approval hands over full authenticated access. The fix is not to abandon MFA but to upgrade away from simple push approvals toward number matching or phishing-resistant FIDO2 credentials.

What Is an MFA Fatigue Attack?

Multi-factor authentication was supposed to be the backstop that kept stolen passwords from becoming stolen accounts. And for most attack types, it works. Credential stuffing, brute force, and phishing campaigns are all stopped cold when a second factor is required. MFA fatigue is the adversary’s answer to that wall: rather than trying to bypass the second factor technically, they abuse the human who holds it.

According to CISA Advisory AA22-074A (2022): “Threat actors sent multiple MFA push requests to the target’s legitimate device, causing alert fatigue, until the target accepted the request.” The advisory named MFA fatigue as one of the most commonly used initial access techniques by sophisticated threat actors that year, including nation-state groups.

The technique works because standard push-based MFA asks the wrong question. When your phone displays “Are you trying to sign in?” with an Approve button, it is really asking: “Did someone just submit correct credentials?” — and the answer is yes, even when the attacker submitted them. There is no context showing where the request came from, no code to match, and no way to distinguish your own login from an attacker’s.

How the Attack Unfolds Step by Step

A push bombing campaign follows a consistent sequence that any security team should recognise:

1. Credential acquisition. The attacker obtains valid credentials first — typically purchased from dark web marketplaces selling dumps from prior breaches, or stolen through a targeted phishing campaign. Password reuse across sites makes this step trivially easy: one breached database often yields credentials that work elsewhere.
2. Login trigger. The attacker submits the correct username and password to the target service. The service recognises the credentials as valid and dispatches an MFA push notification to the registered device.
3. The flood. The attacker continues triggering login attempts in rapid succession. The victim’s phone receives notification after notification: “Are you trying to sign in?” — sometimes dozens per hour, often arriving in the middle of meetings, at night, or during a busy commute.
4. Acceptance. Confused, annoyed, or simply exhausted, the victim approves a notification — sometimes believing it to be a glitch from their own device, sometimes hoping that approving will make the alerts stop.
5. Social engineering overlay (advanced variant). In more sophisticated attacks, the attacker calls the victim while notifications arrive, impersonating IT support and requesting they “confirm identity” by approving the next prompt. This dramatically increases success rates and was used in both the Uber and Cisco breaches.

Once approved, the attacker holds a fully valid authenticated session — generated by the victim’s own device.

Real-World MFA Fatigue Breaches (2022–2026)

Three landmark incidents cemented MFA fatigue as a mainstream threat and forced the security industry to rethink push-based authentication as a gold standard:

Uber (September 2022). An attacker purchased Uber contractor credentials from the dark web, then sent MFA push notifications for over an hour until the contractor finally approved one. The attacker gained access to Uber’s internal Slack, HackerOne vulnerability database (containing unremediated bug reports), and cloud infrastructure — announcing the breach directly from Uber’s own Slack workspace.

Cisco (May 2022). The LAPSUS$ and Yanluowang threat actors combined voice phishing with MFA bombing to compromise Cisco’s VPN environment. The attacker posed as a Cisco IT technician while simultaneously flooding the target’s phone, ultimately achieving persistent access to internal systems before being detected.

Microsoft / LAPSUS$ (March 2022). The LAPSUS$ group publicly documented their use of MFA fatigue in their own Telegram channel, describing it as trivially effective. They would call targets claiming to be company IT, then ask them to approve a pending MFA notification while the flood continued. Microsoft confirmed the technique was used against its own employee accounts during the Lapsus$ intrusion campaign.

Why Standard Push MFA Is Vulnerable by Design

NIST SP 800-63B (2024 revision) addresses this explicitly: out-of-band push authenticators “may be susceptible to prompt bombing when the verifier does not require explicit context display.” A push notification that shows only “Approve / Deny” with no IP address, no geographic location, and no challenge code gives the user no basis to evaluate the legitimacy of the request.

The vulnerability is structural, not incidental. Standard push MFA was designed to minimise friction at the cost of context. That trade-off made sense when the threat model assumed attackers without valid credentials. Once an attacker holds the password, the push mechanism becomes a social engineering surface rather than a security control.

Five Defenses That Actually Stop MFA Fatigue

1. Enable Number Matching

Number matching displays a random code on the login screen and requires the user to enter that exact number in the authenticator app to approve. An attacker triggering unauthorised notifications cannot know the code displayed on the legitimate user’s screen — which means any push flood becomes useless regardless of volume. Microsoft reports that enabling number matching in Authenticator reduced successful MFA fatigue attacks to near zero in enterprise deployments. Most major identity providers now support it; enabling it is usually a single configuration toggle.

2. Add Context to Push Notifications

Configure your identity provider to include the login location, IP address, and device type in every push notification. A prompt reading “Sign-in from Kyiv, Ukraine — IP 185.x.x.x at 03:14” is self-evidently illegitimate to anyone who is sitting at home in London. The UK National Cyber Security Centre (NCSC) recommends contextual push notifications as a practical MFA hardening measure, noting they “allow users to identify and deny suspicious requests before approving.”

3. Rate-Limit and Lock Out Push Requests

Most enterprise identity providers — Microsoft Entra ID, Okta, Duo, and others — allow administrators to flag accounts after a threshold of consecutive denied or unanswered push requests. Setting this to five or fewer attempts within an hour stops the flooding phase before it becomes exhausting. Trigger an automatic password reset and IT alert when lockout fires, since the flood itself is evidence of a credential compromise.

4. Switch to FIDO2 / Hardware Keys for Critical Accounts

Phishing-resistant MFA using FIDO2 (WebAuthn) or hardware security keys eliminates fatigue attacks entirely by design. There is no push notification to approve; authentication requires physical interaction with a hardware token or a biometric confirmation on the registered device. CISA’s updated MFA guidance explicitly calls FIDO2 “the most secure form of MFA” and recommends it for all privileged accounts, email access, and cloud administration. Deploy hardware keys first to your highest-risk users: executives, IT administrators, and anyone with access to sensitive data stores.

5. Train Users to Treat Unexpected Pushes as an Incident

A single unexpected push notification is suspicious. A flood of them is a confirmed credential compromise. Users should be trained to deny every push they did not personally initiate and to immediately report a notification flood to the security team — not to approve one “just to make it stop.” Run tabletop drills that simulate the notification flood and the fake IT support call to build muscle memory before the real attack arrives.

The Role of Strong, Unique Passwords

It is easy to focus entirely on hardening MFA and forget that MFA fatigue attacks have a mandatory prerequisite: the attacker already has your password. Every push bombing incident documented in public reporting began with a credential breach, a phishing steal, or a password reuse exploit. Without valid credentials, the attacker cannot trigger the MFA flow at all.

The most underrated first-layer defence is a strong, unique password that was never reused across services and was never exposed in a known breach. A password that has never appeared in any breach database and cannot be guessed or cracked eliminates the attacker’s ability to reach the MFA step in the first place. Generate a random, high-entropy password for every account using a tool like SecureKeyGen and store it in a reputable password manager such as NordPass, which includes breach-monitoring that alerts you when a stored credential appears in a leaked database.

Combined with phishing-resistant MFA, strong unique passwords eliminate both the credential-theft surface and the push-bombing attack surface simultaneously.

What to Do Right Now: Your Action Checklist

1. Audit every MFA-protected account today. If any service uses push-only MFA without number matching, enable number matching immediately — it is available in Microsoft Authenticator, Duo, and most enterprise SSO platforms.
2. Move email and admin accounts to FIDO2. Email is often the recovery key for your entire digital identity. Pair it with a hardware security key or passkey — these are immune to both phishing and push bombing.
3. Configure login context in your authenticator app. Enable location and device display in push notification settings if your provider supports it.
4. Set a push lockout threshold. In your identity provider admin console, set a limit of five or fewer consecutive unanswered or denied pushes before locking the account and alerting security.
5. Rotate any reused or compromised passwords. Run your credentials against a breach database, then use a password manager to generate and store unique credentials for every account. Remove any password shared across two or more services.
6. Know the response protocol. If your phone floods with unexpected MFA requests, deny all of them, change the account password immediately, and report the incident to IT security. Never approve a push you did not initiate — even once.