What is an MFA fatigue attack?

Key takeaways

• MFA fatigue (also called push bombing) requires the attacker to already have a valid password; it is the second stage, not the first.
• Push-based MFA is structurally vulnerable: the user is asked to approve a binary prompt with no context about who or where is requesting access.
• High-profile compromises at Uber, Cisco, Microsoft, and Twilio in 2022-2023 ran on this pattern; the same pattern still works in mid-market environments in 2026.
• Number matching, location context, and additional risk signals reduce success rate; they do not close the gap.
• Phishing-resistant MFA (FIDO2, passkeys) eliminates the attack at its root.

How does an MFA fatigue (push bombing) attack work?

The attack has four stages.

1. Password acquisition. The attacker obtains the user's password through credential stuffing (using passwords leaked in other breaches), spear phishing, info-stealer malware, or purchase from broker marketplaces. The MFA fatigue attack is the second-stage move; obtaining the password is the first.

2. Authentication initiation. The attacker uses the password to start a sign-in flow. The identity provider responds by requesting MFA. Where push-based MFA is in use, this triggers a push notification on the user's authenticator app.

3. Push bombing. The attacker initiates the authentication flow repeatedly, sending five, ten, fifty push prompts to the user. The pace can be slow (one every twenty minutes through the day) or fast (a wall of prompts in the middle of the night). The intent is to push the user toward approving one of the prompts, either by mistake (tapping the wrong button) or out of frustration (just make it stop).

4. Optional social engineering pairing. A vishing call from "IT support" confirms the prompts are legitimate. "We are running a security check, you will see some prompts, please approve them." The combination of push pressure and a confirming voice raises success rates substantially.

When a prompt is approved, the attacker is in. From that point the attack continues with normal post-foothold tradecraft: persistence, lateral movement, data discovery, BEC, or OAuth grants for durable access.

Why push notification MFA is structurally vulnerable

Push-based MFA was designed for usability, not adversary resistance. Three properties make it vulnerable:

1. Binary approval with no context. The user sees "approve or deny" with limited information about what is being authenticated, where, or by whom. Many implementations show the requesting app name and a vague location, but not the requesting IP, the device fingerprint, or recent failed attempts from the same source.
2. No binding to the requesting client. A push approval is interpreted by the identity provider as "the user has approved this authentication", regardless of where the authentication is coming from. The MFA decision is severed from the device making the request.
3. Race conditions in user behavior. Users tap push notifications reflexively. Modern phones display authenticator prompts in lock-screen environments where a thumb-swipe is muscle memory. The attack succeeds on small percentages of attempts, but the attacker can run many attempts.

The contrast is with phishing-resistant MFA: FIDO2 and passkeys cryptographically bind the authentication to the relying party, so an attacker cannot route an authentication attempt to the user's device at all. There is no push to bomb.

Examples of MFA fatigue compromises

Notable incidents demonstrate the pattern.

• Uber, September 2022. An attacker obtained credentials for an Uber contractor and bombed push prompts. After failing repeatedly, the attacker contacted the contractor over WhatsApp claiming to be Uber IT, instructing them to accept the next prompt. The contractor approved; the attacker reached internal Slack, AWS, and internal admin tooling.
• Cisco, May 2022. A Cisco employee's Google credentials were used to attempt login. Push prompts followed by a vishing call from "Cisco IT" produced approval. The attacker reached VPN access; later activity escalated to data exfiltration before being contained.
• Microsoft and others targeted by Lapsus$ in 2022. Multiple high-profile compromises followed the same pattern: credentials acquired through credential markets or info-stealer malware, MFA fatigue (often paired with vishing) for approval, post-access actions including source code theft and extortion.

In mid-market manufacturers, the pattern is structurally identical with smaller dollar figures and lower public profile. The same techniques, against smaller defenders, with less observation, still succeed regularly.

How to detect MFA fatigue attempts in logs

For organizations on Microsoft Entra, Okta, or equivalent identity providers, four detection sources matter:

1. Repeated sign-in failures and MFA denials per user per short window. Five or more push prompts denied in 10 minutes is unusual. The threshold should produce alerts, not just log entries.
2. Mixed-outcome sequences (denies followed by approval). A sequence of denials followed by an approval, especially from the same source IP, is a signature of a successful fatigue attack. Detection should run continuously, not just in periodic reports.
3. Geographic anomalies. Authentication attempts from unexpected countries or impossible-travel patterns, paired with approval activity, are high-confidence signals.
4. Out-of-hours activity. Push prompts in the middle of the night, when the user is asleep, are either innocent (an automated workflow) or hostile (push bombing during low-attention hours). Baselining each user's normal activity hours makes the anomaly visible.

These detections belong in the identity layer, not the SIEM alone. Tools like Microsoft Entra Identity Protection, Okta ThreatInsight, and equivalents handle most of these natively but require configuration.

How to migrate off push MFA without breaking the user experience

For mid-market manufacturers, the path from push MFA to phishing-resistant MFA usually goes through three steps.

1. Enable number matching and context immediately. Microsoft Authenticator and Okta Verify both support number matching (the user types a number displayed on the requesting screen into the authenticator) and extended context (location, app name, IP). Enabling these can be done tenant-wide in a single change and raises the bar without changing the user's authenticator app.

2. Roll out passkeys for high-risk roles. Executives, IT, finance, AP, and HR receive passkeys (or FIDO2 hardware keys for shop-floor accounts where smartphones are restricted). Coverage of these roles addresses the highest-loss compromise paths first. See What is a passkey?.

3. Phase out push MFA for all users over six to nine months. The migration runs by cohort, with help-desk capacity reserved during each cohort's transition. The end state is that push-based MFA is unavailable as an authentication method tenant-wide.

The user-experience trap to avoid: rolling out passkeys without removing the push-based fallback. As long as the push option exists, attackers will route there. The migration is not complete until the weak factor is removed.

For shared-device, shop-floor, or BYOD-restricted environments, a combination of hardware FIDO2 keys (for shared kiosks) and conditional-access policies (allowing weaker MFA only on managed devices in trusted network segments) handles edge cases without rolling back to broad push MFA.

Best practices for phishing-resistant MFA rollout

1. Plan the destination first. Decide what "done" looks like (no push MFA tenant-wide, passkeys for all knowledge workers, hardware keys for shop-floor) before rolling out individual changes. The plan keeps each step inside a coherent path.
2. Start with the highest-loss roles. Executives, finance, AP, HR, IT, and any role with access to the ERP, the engineering file server, or the OT network.
3. Use conditional access to require phishing-resistant MFA for sensitive applications first. Tighten by application, not just by user. The ERP, admin consoles, M365 admin, and remote-access portals get phishing-resistant MFA as a requirement; weaker factors stop working for those apps.
4. Plan recovery and replacement workflow before rollout. Lost-device handling, hardware-key replacement, passkey resync. Help-desk procedures need to handle these without falling back to weaker authentication.
5. Monitor the gap during migration. Push-MFA volume should fall steadily; tenants where it does not are silently rolling back. Dashboards on MFA factor usage by role are useful as a steering signal.
6. Continuous simulation during and after migration. Adaptive simulation that includes credential-harvest and MFA-fatigue components reveals how far migration has actually closed the gap, not just how far the policy says it has.
7. Insurance and compliance alignment. Underwriters reward phishing-resistant MFA; document the migration as it happens for renewal evidence. See What is cyber insurance underwriting?.

MFA fatigue FAQs

Is number matching enough to stop MFA fatigue?

Number matching raises the bar but does not close the gap. A persistent attacker pairs the push bombing with a vishing call that tells the user the displayed number to enter. The user complies because the call appears to come from IT. Number matching is a useful interim control on the path to phishing-resistant MFA; it is not the endpoint.

What is the difference between MFA fatigue and SIM swap?

MFA fatigue exploits push-based MFA approval; the attacker already has the password and is trying to get the user to approve. SIM swap is the takeover of a victim's phone number through their carrier, allowing the attacker to receive SMS-based MFA codes directly. Both bypass weak MFA implementations; the mechanism is different.

Do passkeys stop MFA fatigue?

Yes. Passkeys are phishing-resistant by design: the authenticator is bound to the relying party, so an attacker cannot route an authentication attempt to the user's device for approval. There is no push prompt to bomb because there is no password to start the flow from. See What is a passkey? and What is FIDO2?.

Can you stop MFA fatigue without changing authenticator apps?

Partially. Enabling number matching, additional context (location, app name), and tighter risk-based conditional access reduces success rates. Rate-limiting push prompts and surfacing repeated denials as identity alerts also helps. None of this closes the gap fully; phishing-resistant MFA is the only durable answer.

How ARG simulates MFA fatigue and recommends remediation

MFA fatigue is part of ARG's continuous identity simulation. It runs alongside spear phishing, vishing, and OAuth consent phishing, against the same named individuals, on the same engagement cadence.

The simulation is operated by James Wall on infrastructure ARG controls. Where the engagement scope permits and the executive sponsor has authorized it, ARG runs credential-acquisition simulation paired with controlled push bombing against a defined target list, sometimes paired with a vishing call to mirror the real-world attack chain. The simulation never harms the production account; the test confirms whether the user would have approved and what detection signals would have fired.

Findings include: which roles approved under fatigue, how quickly detection surfaced the anomaly, what conditional access caught, what would have to change to harden the path. The remediation backlog covers tenant-wide policy changes (number matching, extended context, rate limiting), role-specific upgrades (passkeys, hardware keys), application-specific conditional access tightening, and detection coverage on identity logs.

Re-testing in subsequent rounds confirms whether the remediation held. The output documents the migration path from push-based MFA to phishing-resistant MFA with measurable evidence at each step, ready for compliance audit and insurance renewal.

For founding clients, MFA-fatigue simulation is part of the monthly retainer alongside the other social engineering channels.

Apply as a founding client or see how the engagement works for the full delivery cycle.