Threat Intelligence

🚨 MFA Fatigue Attacks: How Enterprises Defend Against Push Notification Bombing (2026)

By A Yousif Tanoli · 25 September 2026 · 9 min read · 1,620 words

In September 2022, an Uber contractor received so many MFA push notifications from an attacker — one after another, for nearly an hour — that they finally tapped Approve just to make them stop, handing the attacker complete access to Uber's internal systems, AWS, Google Workspace, and HackerOne bug reports. MFA fatigue attacks exploit the weakest link in modern authentication: human patience. Every enterprise running push-based MFA today is exposed to this technique unless they have specific controls in place.

Why MFA Fatigue Is a Tier-1 Threat in 2026

MFA adoption rose sharply after 2020, and attackers adapted. Where phishing once stole credentials and bypassed authentication entirely, sophisticated groups now treat credentials as a stepping stone and MFA approval as the real target. Push-based authentication — where users tap Approve on a smartphone notification — is the most common MFA deployment in enterprises worldwide, and it is the weakest against fatigue.

The Lapsus$ group, responsible for breaches at Microsoft, Samsung, Okta, and Nvidia between 2021 and 2022, used MFA bombing as a core technique. Microsoft's own post-incident analysis confirmed that the group obtained valid employee credentials, then sent push requests continuously overnight until a target approved. CISA Advisory AA22-181A, published jointly with the FBI and NSA, identified "MFA fatigue / push notification spamming" as a primary method used by state-sponsored and financially motivated actors targeting critical infrastructure.

According to CISA's 2023 Multi-Factor Authentication guidance, organizations should treat push-based MFA as a "less secure" authentication method when it lacks additional verification context, and should prioritize phishing-resistant methods such as FIDO2 security keys for privileged access. The guidance notes that "MFA implementations that use simple push notifications remain vulnerable to real-time phishing proxies and prompt bombing."

The scale is significant. Microsoft's Security team reported in 2024 that push-notification fatigue attacks account for a meaningful fraction of identity-based incident response engagements — enough to prompt the mandatory rollout of number matching for all Entra ID tenants.

How a Push Notification Bombing Attack Works

Understanding the attack mechanics clarifies why standard per-account lockout policies offer no protection:

1. Credential acquisition: The attacker obtains the target's username and password — commonly through phishing, credential stuffing from a prior breach, or purchasing them from initial access brokers.
2. Authentication attempt: The attacker attempts to sign in using the stolen credentials. The identity platform validates them and issues an MFA challenge to the legitimate user's registered device.
3. Flooding the device: The attacker immediately re-attempts login repeatedly. Each attempt sends a new push notification to the target's phone. Depending on rate limiting, this can reach dozens of prompts per hour.
4. Social engineering escalation: In some documented cases (Uber 2022, Okta 2022), the attacker also contacts the target directly via WhatsApp or voice call, impersonating IT support and explaining that the push notifications are a system test requiring approval.
5. Access obtained: Once the user approves a prompt, the attacker's session is authenticated and access is granted — without any phishing page, malware, or further interaction.

The attack succeeds against any push MFA implementation that relies solely on a binary Approve / Deny decision without additional verification. The user has no way to verify which login attempt they are approving or from which device or location it originated.

MFA Fatigue vs. Other MFA Bypass Techniques

Detection: What to Look For in Your Logs

Detecting push bombing before a user approves requires monitoring for anomalous MFA request volume per account in a short window. Most identity platforms expose this through their audit logs.

Microsoft Entra ID (Azure AD): Sign-In and Audit Logs

In Log Analytics, the SignInLogs and AADNonInteractiveUserSignInLogs tables capture MFA outcomes. Look for high-frequency MFA challenges to a single account over a short time window:

SignInLogs
| where TimeGenerated > ago(30m)
| where AuthenticationRequirement == "multiFactorAuthentication"
| where ResultType != 0                        // Non-successful sign-ins
| summarize MFAChallenges = count(),
            UniqueIPs = dcount(IPAddress)
  by UserPrincipalName, bin(TimeGenerated, 5m)
| where MFAChallenges > 5                      // Tune to your baseline
| order by MFAChallenges desc

Additionally, alert on the specific result code for MFA denial: ResultType = 500121 (Authentication failed during strong authentication request) combined with repeated attempts from a foreign or unknown IP against a single account signals active bombing.

Okta: System Log

In Okta's System Log, filter for eventType = user.authentication.auth_via_mfa with outcome.result = FAILURE and group by actor. A spike of five or more MFA challenge failures per user within a five-minute window warrants an alert. Okta's built-in ThreatInsight feature flags this automatically when enabled, but SIEM correlation provides an additional, auditable layer.

Behavioral Signals to Correlate

• MFA challenge volume spike against a single account (5+ in 5 minutes)
• MFA request originating from a country or ASN never seen for that user
• Successful MFA approval immediately following a sequence of denied prompts (possible fatigue success)
• User-initiated MFA fraud report or help-desk call within the same time window

Prevention: Six Controls That Eliminate Push Bombing Risk

1. Enable Number Matching (Highest Impact, Immediate)

Number matching changes the push notification from a binary Approve / Deny to a challenge: the sign-in page displays a two-digit number that the user must type into the authenticator app before the prompt resolves. An attacker triggering a push from their own device cannot know which number appears on the legitimate sign-in screen, so matching fails even if the user opens the app.

Microsoft made number matching mandatory in Entra ID's Microsoft Authenticator starting in May 2023. If you have not verified that your tenant enforces it, check under Entra ID > Protection > Authentication methods > Microsoft Authenticator > Configure and confirm Require number matching is set to Enabled for all users — not just the preview group.

2. Enable Additional Context in Push Notifications

Additional context surfaces the application name, geographic location, and IP address of the sign-in attempt within the push notification itself. A user in London who receives a push notification showing "Sign-in from Lagos, Nigeria to Salesforce" has an immediate signal to deny and report. This setting is separate from number matching in Entra ID and should be enabled alongside it.

3. Cap Push Attempts Per Session

Configure the identity platform to lock the account or trigger a help-desk alert after a defined number of failed MFA push attempts within a session. Microsoft Entra ID supports this via Conditional Access policies combined with Identity Protection risk signals. A threshold of three consecutive MFA failures per sign-in window, triggering a block and risk flag, prevents the sustained flooding approach that most fatigue attacks rely on.

4. Migrate Privileged Accounts to FIDO2 / Passkeys

Push-based MFA is fundamentally vulnerable to fatigue because the approval is a human judgment call under pressure. FIDO2 hardware security keys and platform passkeys eliminate this by binding authentication to a cryptographic challenge that only the physical device in the user's possession can answer. No push notification is sent; no human approval is required beyond a biometric or PIN on the device itself.

As CISA's guidance states: "Organizations should migrate toward phishing-resistant MFA — such as FIDO2 security keys — particularly for privileged accounts and accounts with access to sensitive data." For a full deployment framework, see our Enterprise Passkey Deployment compliance guide.

A tiered approach keeps implementation costs manageable:

• Tier 1 — Privileged accounts (admins, DevOps, finance): FIDO2 hardware keys (YubiKey, Google Titan). No push MFA permitted.
• Tier 2 — Standard staff: Number matching + additional context enabled in push MFA. Push attempt cap enforced.
• Tier 3 — Contractors / guests: Time-limited access with strict Conditional Access scope. Phishing-resistant where practical.

5. Disable Legacy Authentication Protocols

Legacy protocols such as IMAP, POP3, SMTP AUTH, and older Exchange ActiveSync connections bypass modern MFA entirely. An attacker who obtains credentials can authenticate via these channels without ever encountering an MFA challenge. CISA and Microsoft have both published explicit guidance recommending blocking all legacy authentication traffic in Conditional Access before focusing on push MFA hardening — a misconfigured legacy channel can render push security improvements irrelevant.

In Entra ID, create a Conditional Access policy with Client apps: Exchange ActiveSync clients + Other clients set to Block for all users. Monitor for blocked legacy sign-in attempts using the SignInLogs | where ClientAppUsed contains "IMAP" query as a baseline measure before enforcing.

6. Security Awareness Training Specific to Push Fraud

Technical controls do not remove the risk entirely — a user who receives a push from a legitimate-looking IT helpdesk caller impersonating internal support may still approve. Training should address three specific scenarios:

1. Unsolicited pushes: If you did not initiate a sign-in, deny all pushes immediately and report to security regardless of how urgent the caller sounds.
2. Volume flooding: Repeated pushes are never a technical glitch — they indicate an active attack. Deny, lock your account via self-service if available, and call the real help desk using a number from internal directories only.
3. Impersonation calls: Real IT support never asks you to approve an MFA push during an inbound call. The legitimate direction is always user-initiated.

Incident Response: What to Do When Bombing Is Detected

When SIEM or Identity Protection raises a push bombing alert or a user reports an unsolicited push flood, the response window is measured in minutes — the attack succeeds the moment the user approves one prompt.

If a successful approval is confirmed, treat it as a full identity compromise: rotate all credentials the account had access to, revoke OAuth tokens, and audit connected third-party applications. A enterprise password manager makes bulk credential rotation significantly faster during these windows.

MFA Fatigue Defense: Audit Checklist

• Number matching enforced for all users in Microsoft Authenticator or equivalent
• Additional context (app name, location, IP) enabled in push notifications
• Push attempt cap configured — session lock or risk flag after 3 consecutive failures
• Legacy authentication protocols blocked via Conditional Access for all users
• Privileged accounts using FIDO2 hardware keys or platform passkeys (no push MFA)
• SIEM alert active for 5+ MFA failures per account in a 5-minute window
• Incident response runbook tested for push bombing scenario in the last 12 months
• User training completed covering unsolicited push recognition and reporting procedure

Push-based MFA made authentication dramatically harder for attackers in 2018. By 2022 it had a documented bypass route that required no malware, no phishing page, and no technical sophistication — just patience and a phone. The controls above close that gap. Number matching alone eliminates the core mechanics of most fatigue attacks at near-zero deployment cost; the rest of the list builds defence in depth that holds when a determined actor targets a specific employee.