MFA fatigue and push bombing

How it works

Push-based MFA sends a notification to an authenticator app on the user's phone asking them to approve or deny a sign-in. It was designed to be faster and friendlier than typing a code. The protocol behind it is simple: after the password step succeeds, the identity provider holds the sign-in in a pending state, sends a push through the platform notification service to the user's enrolled authenticator, and completes the sign-in for whichever browser started it as soon as the app answers "approve".

An attacker who already holds a valid password, usually from an infostealer log, a breach dump, or a phishing kit, signs in repeatedly from their own browser. Each attempt passes the password check and fires a new push. The victim's phone buzzes, once, then again, then again, often late at night or during a meeting.

The barrage is frequently paired with a second channel. The attacker calls, texts or messages the victim posing as IT, says a system fault is causing the prompts, and asks them to approve one so it stops. That is a vishing script, not a technical exploit. Eventually a tired, annoyed, or trusting user taps approve, and the pending sign-in in the attacker's browser completes with a fully MFA-satisfied session. The usual next step is to register the attacker's own authenticator so the pushes are no longer needed.

The prerequisite is the password, which is why this technique travels with password spraying, credential stuffing and infostealer credential harvesting. Push bombing converts a password that should have been useless on its own into a working session.

Why it works

Approve-or-deny push outsources a security decision to a person under manufactured pressure, with almost no context to make it well. On an unhardened deployment the prompt shows an app name and a timestamp at most: no location, no device, no reason. A user has no way to tell a legitimate re-authentication from an attacker's attempt, and the interface offers a one-tap escape from an annoying, repeating interruption.

This is not a cryptographic weakness in MFA. The factor works exactly as designed: the phone is in the user's possession and the user approved. The control assumption that fails is that approval means intent, that a person who taps "approve" has checked that the sign-in is theirs. Under repetition, fatigue and a plausible phone call, that assumption does not hold at any scale. The second assumption that fails is binding: a simple approve button is not tied to the session in front of the user, so the approval completes whichever browser is waiting, including one on the other side of the world.

Number matching attacks that binding gap directly. The user must type a number shown on the sign-in screen into the app, and the attacker's screen is the only one showing it, so a blind approval becomes impossible. The attacker can still read the number out on the phone, which is why number matching reduces this technique sharply but does not end the social-engineering variant.

How to detect it

• Push volume per user. In Okta, the System Log event system.push.send_factor_verify_push fires every time a push is sent. Count it per user over a short window. Rejections appear as user.mfa.okta_verify.deny_push in Classic orgs and as user.authentication.auth_via_mfa with outcome reason INVALID_CREDENTIALS in Identity Engine orgs.
• Denied, denied, approved. In Entra sign-in logs (SigninLogs), the AuthenticationDetails column records the result of each authentication step and the method used. A run of MFA failures or interrupts (ResultType 50074, strong authentication required and not passed) followed by a success for the same user from the same IPAddress is the classic shape.
• User reports. When a user taps "report" in Microsoft Authenticator, Entra writes a "Suspicious activity reported" audit event and raises the userReportedSuspiciousActivity risk detection. Okta's equivalent is user.account.report_suspicious_activity_by_enduser. These are high-signal and should page someone.
• Password success without a matching history. A correct password from an IP, ASN or device the user has never used, immediately followed by pushes, indicates the password itself is compromised whether or not the push was approved.
• New authenticator right after approval. user.mfa.factor.activate in Okta, or "User registered security info" in Entra audit logs, within minutes of an approved push from an unfamiliar location.

Be honest about the limits: users legitimately mistype passwords and re-trigger prompts, mail clients on a second device can re-prompt after a password change, and an app reinstall produces bursts. Volume and timing alone are suggestive, not conclusive. Pair the alert with the location and device context of the sign-in, and contact the user out of band before treating it as confirmed. Remember that a burst which never ended in approval still means the password is known and should be rotated.

How to stop it

• Move high-value and privileged accounts to phishing-resistant MFA. FIDO2 security keys and passkeys have no approve-or-deny prompt to wear a user down with, and they also defeat the phone-call variant. The MFA matrix shows which SaaS apps let you require them.
• Turn on number matching everywhere push remains. Microsoft Authenticator applies number matching to all push notifications; Okta Verify offers a number challenge that admins can set to "All push challenges" rather than only risky sign-ins. Set it for every user, not only flagged attempts.
• Show context in the prompt. Entra's additional context setting displays the application name and geographic location in the Authenticator prompt, which gives the user something concrete to reject.
• Rate-limit pushes and lock on threshold. Cap pushes per user per window and block further attempts automatically, rather than leaving the decision to the user. Treat the password as compromised once the cap trips.
• Make the report button do something. Route user reports to a high-risk state that blocks sign-in and forces a reset, so reporting is faster than approving.
• Train on the specific script. "This is IT, please approve the prompt" is the line to teach. There is no fake login page to spot, so generic phishing training does not cover it. See MFA fatigue.

Seen in the wild

• Uber breach via contractor password and MFA fatigue (September 2022): a contractor's password, likely bought after malware infected a personal device, then repeated login attempts and two-factor requests until one was accepted.
• Cisco corporate network breach via synced credentials, vishing and MFA fatigue (disclosed August 2022): Cisco Talos reported credentials synced from a personal Google account, voice phishing posing as trusted organizations, and repeated pushes until the employee accepted, reaching the VPN.
• MFA fatigue and push bombing: defeating MFA without breaking it, the SWI teardown of both cases and the pattern's evolution.

The Identity Breach Report 2026 records push spam in 2 of the 25 MFA bypasses in the Identity Breach Database, both in 2022, and no recorded MFA fatigue case since. The report suggests number matching is the likely reason while noting the data cannot prove it. The phone did not go quiet: the same callers moved to asking employees to approve OAuth apps or log in on a proxied page, which the report counts as talk-past attacks.

Sources

• MITRE ATT&CK T1621: Multi-Factor Authentication Request Generation
• Microsoft Entra: number matching in Authenticator push notifications
• Microsoft Entra: additional context in Authenticator notifications
• Microsoft Entra ID Protection: risk detection types
• Okta: System Log event types
• Okta: configure Okta Verify options, including number challenge
• Cisco Talos: Cisco Talos shares insights related to recent cyber attack on Cisco
• Uber: security update, September 2022
• CISA: Implementing Phishing-Resistant MFA