MFA Push Bombing: How to Stop Fatigue Attacks Without Replacing Your MFA Platform

Push bombing is mechanically simple. An attacker obtains valid username and password credentials through phishing, credential stuffing, or purchasing from an initial access broker. They then authenticate normally up to the MFA step, triggering a push notification to the victim's device. They repeat this process continuously, typically using an automated script or by manually cycling through login attempts at ten to thirty second intervals. Each attempt produces a new push notification on the victim's phone.

The psychology works through several mechanisms. Repeated interruptions on a personal device during working hours create genuine annoyance, and many users tap the wrong button reflexively. Some users believe the repeated notifications indicate a technical glitch with their own login session and approve the prompt to resolve what they perceive as their own problem. In social engineering variants, an attacker calls the victim pretending to be IT support, explains that there's a system issue causing repeated prompts, and instructs the user to approve the next request. This is precisely the technique used against an Uber contractor in 2022.

The Uber breach mechanics are instructive because they illustrate that technical controls alone are insufficient. The attacker purchased contractor credentials from a dark web marketplace, then initiated a push flood that lasted approximately one hour. When the contractor did not immediately approve, the attacker contacted them via WhatsApp, claimed to be from Uber IT, and convinced them that approving the push was required to stop the alerts. The contractor approved. Within minutes, the attacker had internal network access and was escalating privileges using a PowerShell script found on a network share that contained hardcoded administrator credentials.

Understanding this flow is critical because the defensive response needs to address both the repeated-push problem and the social engineering problem. Number matching addresses the technical bypass. Security awareness training addresses the social engineering component. Neither alone is sufficient.

Number matching is a feature in modern push MFA systems that requires the user to enter a numeric code displayed on the login page into their authenticator app before they can approve the push. This simple addition breaks push bombing because the attacker cannot transmit the correct number to the victim's app without the victim also being able to see it, which would require them to be actively engaged with their own login session.

In practice, when a user authenticates to an Azure AD or Entra ID application, their browser displays a two-digit number. The Microsoft Authenticator app shows a prompt asking the user to enter that number. An attacker sending a push flood from a separate session sees a different number on their screen. The victim sees no number because they are not actively logging in. They receive a push notification asking them to enter a code they have no way of knowing. When users encounter this without an active login session, the correct response is to deny the request and report it.

Enabling number matching in Microsoft Entra requires navigating to Entra ID, then Security, then Authentication methods, then Microsoft Authenticator, and setting the Number Matching option to Enabled under the configuration blade. Microsoft began enforcing this by default in 2023, but older tenant configurations may still have it disabled or set to Microsoft Managed. Verify that it is set to Enabled explicitly.

In Okta, the equivalent feature is called "Push Challenge" with TOTP verification or Okta's own number challenge. Navigate to Security, then Authenticators, then Okta Verify settings. Enable the "Additional Context" feature, which shows the city and device from which the authentication request originated, and enable "Number Challenge" so users must match a code. Okta's documentation distinguishes between Okta Verify push (where number challenge applies) and other factors, so verify which authenticator type is in use across your user base.

For Duo Security, the relevant feature is called Duo Verified Push or Number Verification. Under the Duo Admin Panel, navigate to Policies and create or modify a policy to enable "Verified Duo Push." This presents a code on the browser that the user must enter into the Duo Mobile app. Duo also supports a "Require Biometric" option that forces face or fingerprint verification before approval, which adds a second layer on top of number matching. Both controls are available on Duo's Advantage and Premier tiers; the base Essentials tier has limited policy controls.

Number matching stops the push approval problem, but contextual anomaly detection catches the breach earlier, before the user even sees a push. Modern identity platforms can evaluate dozens of signals at authentication time and either step up the required factor or block the attempt entirely. Configuring these controls correctly is what separates a platform that detects push bombing campaigns from one that silently processes them.

The most useful contextual signals are IP reputation, impossible travel, device compliance, and application sensitivity. IP reputation checks flag authentications originating from hosting providers, VPNs, Tor exit nodes, and known threat actor infrastructure. Impossible travel detects when a user authenticates from New York at 9 AM and then from Amsterdam at 10 AM. Device compliance checks verify that the authenticating device meets endpoint requirements such as disk encryption, OS patch level, and EDR enrollment. Application sensitivity allows different policy tiers for low-risk apps like internal wikis versus high-risk apps like code repositories and financial systems.

In Microsoft Entra, Conditional Access Policies are the enforcement mechanism. A well-configured policy set should include at minimum: block access from non-compliant devices for all applications marked as high sensitivity; require MFA for any access from outside named locations; block authentications from IP ranges in the Entra ID Identity Protection risky sign-in feed; and require password change plus MFA step-up for any user flagged as high risk. Entra ID Identity Protection's sign-in risk scoring ingests Microsoft's threat intelligence and can classify real-time sessions by risk level, enabling automated blocking without requiring manual review.

Okta's ThreatInsight and Okta Identity Threat Protection perform analogous functions. ThreatInsight uses Okta's cross-tenant signal network to identify IP addresses that have been observed attacking multiple Okta customers and can block or challenge those IPs before authentication completes. For Okta customers on Identity Governance tiers, the Okta Identity Threat Protection product adds post-authentication session risk scoring that can terminate active sessions when risk signals emerge mid-session.

The operationally important point is that contextual controls require tuning. An organization's named locations, VPN ranges, and contractor IP pools must be accurately configured or legitimate traffic will be flagged. Budget two to four weeks of detection-mode monitoring before enabling blocking actions on contextual policies. Review the flagged-but-not-blocked log daily during that period to identify misconfigured network definitions before they cause production impact.

FIDO2 authentication uses public-key cryptography tied to the origin of the authentication request. When a user registers a FIDO2 credential, whether a hardware security key like a YubiKey or a platform passkey stored in the device's secure enclave, the authenticator generates a key pair. The private key never leaves the device. The relying party stores only the public key. At authentication time, the server sends a challenge, the device signs it with the private key, and the server verifies the signature with the stored public key.

The critical anti-phishing property is that the signing operation includes the origin, meaning the domain of the site requesting authentication. A FIDO2 credential registered at login.company.com will not respond to challenges from login.company-security.com or any other impersonator domain. The device hardware enforces this check before the signing operation executes. This origin binding is what makes FIDO2 resistant to real-time phishing proxies like Evilginx2, which can intercept and replay TOTP codes and push approvals but cannot intercept a FIDO2 signature bound to the legitimate domain.

Passkeys extend FIDO2 to consumer-grade devices by storing credentials in the platform's credential store, such as Apple Keychain, Google Password Manager, or Windows Hello, and enabling synchronization across devices through the vendor's cloud backup mechanism. For enterprise deployments, the key question is whether synchronized passkeys (which replicate to cloud backups) or device-bound passkeys (which are tied to a single hardware authenticator) are appropriate. CISA's guidance for high-value accounts recommends device-bound credentials; hardware tokens satisfy this requirement while synchronized passkeys may not, depending on the threat model.

Migrating from push MFA to FIDO2 does not require a platform forklift if your identity provider supports FIDO2 natively. Microsoft Entra, Okta, and Duo all support FIDO2 as an authentication method. The migration approach is to add FIDO2 as an available factor, run a registration campaign where users enroll a hardware key or platform passkey, and then create a Conditional Access policy that requires phishing-resistant MFA for all high-sensitivity applications. After verifying that registered users authenticate successfully, remove push as an allowed factor for those applications. For users who have not yet enrolled FIDO2 credentials, temporarily require TOTP rather than leaving push as the fallback.

Hardware security key procurement does not need to be expensive. YubiKey 5 series, Google Titan keys, and compatible FIDO2 keys from other vendors are available at twenty to thirty dollars per key. For executives and privileged users, two keys per person (primary and backup) is the standard recommendation. For bulk workforce deployment, platform passkeys using Windows Hello for Business or Apple Passkeys provide a zero-hardware-cost FIDO2 path, though the synchronization properties must be reviewed against your security policy.

Not every organization is in a position to immediately enable number matching or migrate to FIDO2. Platform licensing tiers, contractual lock-in, or organizational change management processes may delay those changes by weeks or months. In the meantime, there are compensating controls that reduce risk without requiring any platform changes.

The most impactful immediate action is to enforce a maximum push notification count per authentication session at the network or platform level. If your platform supports it, configure a policy that blocks further push attempts after three denied prompts within a defined window, and triggers an account review or temporary lockout. This does not stop a sophisticated attacker who patiently waits between sessions, but it eliminates the high-velocity flood approach and significantly reduces the probability of accidental approval.

The second immediate action is aggressive security awareness communication targeted specifically at the push bombing pattern. Users need to understand one rule: if you receive a push notification and you are not actively logging into a system, deny it immediately and call the IT security team using a known-good phone number. This sounds simple but many users have never received explicit guidance on this scenario. A brief five-minute security awareness video or team meeting covering this specific attack pattern can significantly change behavior. Include guidance that IT will never call you and ask you to approve a push, because that social engineering variant is what completed the Uber breach.

Third, review who has access to which systems and whether all of those users need push-based MFA for all applications. For your most sensitive applications (administrative consoles, code repositories, financial systems, identity management), restricting access to named devices and named network ranges reduces the push bombing surface even before number matching is enabled. An attacker with stolen credentials cannot initiate a push flood for an application that blocks authentication attempts from outside your corporate network ranges.

Finally, enable authentication logging and build a detection alert for repeated failed MFA attempts from the same IP or user account. Multiple push denials from a single user account within a short window is a high-fidelity indicator of an active push bombing campaign. Configure your SIEM to alert on this pattern and define a response playbook: contact the user through an out-of-band channel (phone call to HR-verified number), temporarily disable the account, reset credentials, and investigate the source of the credential compromise before re-enabling access.

The goal of a migration from push MFA to phishing-resistant MFA is to move users incrementally without forcing a cutover deadline that creates helpdesk chaos. The approach that works in practice is a parallel enrollment period followed by application-by-application enforcement, starting with the highest-risk access paths.

Begin by identifying your high-risk application tier. This typically includes your identity provider's admin console, your cloud provider management consoles (AWS, Azure, GCP), your code repositories, your secrets management systems, and any application with access to customer PII or financial data. These are the applications where a compromised session creates existential business risk. Enable FIDO2 as an available factor in your identity platform and create a self-service enrollment flow that takes users less than five minutes to complete.

Run an enrollment campaign for your IT, security, and DevOps teams first. This group has the technical confidence to enroll hardware keys or platform passkeys without friction, and their access to administrative systems makes them the highest-value targets. After successful enrollment, enforce phishing-resistant MFA for the high-risk application tier. Users who have enrolled FIDO2 credentials will authenticate with their new factor. Users who have not yet enrolled will receive an enrollment prompt at their next login.

Expand the enrollment campaign to the broader workforce in cohorts. Provide hardware keys to any user who does not have a compatible biometric device for platform passkeys. For organizations using Windows Hello for Business, most modern corporate laptops already have the hardware to support FIDO2 platform credentials and enrollment is a policy push rather than a physical distribution exercise.

The final enforcement step is to remove push as an allowed factor for the high-risk application tier. Do this after enrollment rates exceed ninety-five percent for the affected user base. Before removing push, build a communication to affected users, configure an automated enrollment reminder for the remaining five percent, and verify your helpdesk has a documented process for handling hardware key loss or reset requests. A user locked out of a sensitive application because their hardware key was lost and push has been disabled is a support incident that needs a clear resolution path before it happens.

Track the migration using a simple dashboard: FIDO2 enrollment percentage by department, authentication method distribution across the high-risk application tier, and helpdesk ticket volume related to MFA issues. These three metrics will tell you whether the migration is on track and where to focus enrollment campaign energy.