MFA fatigue and push bombing: what it is and the settings that stop it

Push-based MFA has one weakness that has nothing to do with cryptography: the approve button. If an attacker already has a user's password, they can start a login, the user's phone buzzes, and the whole second factor reduces to whether the user taps "Approve" on a prompt they did not initiate. Repeating that prompt until the user gives in has a name in the ATT&CK framework and a specific fix in NIST's guidance. This article covers the mechanism at the depth an administrator needs, what the three main references say, and the settings in your identity provider that make it stop.

The mechanism, in one paragraph

The attacker has a valid password, usually from a credential-stuffing list or a stealer log. They submit it to your login page. Your identity provider, correctly, sends a push notification to the user's registered device. The user declines, or ignores it. The attacker submits again. And again, sometimes dozens of times in a row, sometimes at 3 a.m., sometimes accompanied by a phone call or message claiming to be the help desk and asking the user to "just approve it so it stops". The moment one prompt is approved, the attacker has an authenticated session. MITRE ATT&CK catalogues this as T1621, Multi-Factor Authentication Request Generation, in the Credential Access tactic: adversaries with valid credentials repeatedly trigger push requests to cause "MFA fatigue", overwhelming users into accepting an unauthorised attempt. The same page notes that self-service password reset flows can be abused the same way where they are push-approved.

Nothing about this requires the attacker to touch the user's device or intercept anything. The only thing being attacked is human patience.

What the references say

NIST SP 800-63B (2025 revision), in Section 3.1.3 on out-of-band authenticators, describes three ways an out-of-band verifier can work and rejects the third. The acceptable methods have the user transfer a secret between the out-of-band device and the primary channel, "to increase assurance that the subject is actively participating". The third method, which compares secrets on the back end and "requests approval on the secondary channel", is "no longer considered acceptable", specifically because it enables "authentication fatigue" attacks where subscribers approve without verifying. The same section adds that push-based verifiers "SHOULD implement a reasonable limit on the rate or total number of push notifications that will be sent since the last successful authentication".

CISA's phishing-resistant MFA fact sheet (October 2022) lists "push bombing (also known as push fatigue)" as one of four threats to MFA, alongside phishing, SS7 exploitation, and SIM swap, and describes it as threat actors bombarding a user "with push notifications until they press the 'Accept' button". Its Table 1 ranks MFA forms: FIDO/WebAuthn and PKI-based methods are "resistant to phishing" and push bombing "not applicable"; app-based OTP and "mobile push notification with number matching" are "resistant to push bombing" but "vulnerable to phishing attacks"; push "without number matching" is "vulnerable to push bombing attacks as well as user error"; SMS and voice are the weakest. CISA's MFA page adds that where phishing-resistant options are not yet available, organisations should consider "numbers matching MFA to block mobile push bombardment".

ATT&CK T1621 lists three mitigations: M1036 Account Use Policies (restrict logins from suspicious or mismatched locations with conditional access), M1032 Multi-factor Authentication (use stronger mechanisms than one-tap push and "enforce rate limits on MFA request prompts"), and M1017 User Training (accept only prompts you initiated, and report the rest).

Why number matching works

Number matching changes the prompt from "Approve?" to "Enter the two-digit number shown on the login screen". The attacker sees the number on the login page they are driving; the user does not. The user cannot approve a login they cannot see. It is exactly NIST's "transfer the secret between the out-of-band device and the primary channel" requirement, and it converts the approve button from a decision into a proof of presence. It is not phishing-resistant, because a relay page can show the user the real number, which is why CISA places it below FIDO. But against push bombing, which is the attack in this article, it is decisive.

The settings

Every major identity provider exposes the same handful of controls under different names. Here is the checklist in provider-neutral terms.

Pick the rate limit deliberately. Five prompts in ten minutes without a success is already unusual for a real user; a real user who fat-fingers a password gets a second prompt, not a tenth.

Detection: what this looks like in the log

T1621's detection guidance is the practical part: look for excessive or anomalous push notifications from unusual IPs or geolocations, repeated MFA challenges for the same session, rapid failed logins followed by MFA challenges, and multiple MFA requests through identity integrations with no successful interactive login. In your sign-in log, the signature is a single user with many "MFA denied" or "MFA timed out" events in a short window from a source that is not the user's usual one, and then, if the attack worked, one "MFA approved" from that same source.

A query in the shape most SIEMs accept:

-- users with 5+ push denials/timeouts in a 10-minute window, and whether an approval followed
SELECT user, source_ip,
       COUNT(*) FILTER (WHERE result IN ('mfa_denied', 'mfa_timeout')) AS refused,
       MAX(CASE WHEN result = 'mfa_approved' THEN event_time END)        AS approved_at
FROM signin_events
WHERE event_time > now() - interval '24 hours'
GROUP BY user, source_ip, date_trunc('minute', event_time) / 10
HAVING COUNT(*) FILTER (WHERE result IN ('mfa_denied', 'mfa_timeout')) >= 5;

Adjust the column names to your provider's export. The important row is any row where approved_at is not null: that is a compromised session, and the response is to revoke the session, reset the password (it was known to the attacker before the pushes started), review what the session did, and re-enrol MFA. A row with refusals and no approval is still a finding: it means the password is known, and it should be changed and the source blocked.

What to do

1. Turn on number matching for every push user this week, and remove the plain-approve mode from the policy rather than leaving it as a fallback.
2. Set a push rate limit that fails closed, and make the fallback a different factor, not "try again later".
3. Give privileged accounts a phishing-resistant factor, which also removes push from their path entirely.
4. Ship the detection query above, or its equivalent, with an alert on any approval after repeated refusals.
5. Tell users the one rule that matters: never approve a prompt you did not just start, and use the report button when one arrives. Do not tell them anything more complicated.
6. Treat every burst of refused prompts as a known-compromised password, because it is.

The limitation, stated plainly: number matching and rate limits stop push bombing. They do not stop a relay phishing page that shows the user the real number in real time, which is the subject of the adversary-in-the-middle article in the Attack and Defense section, and the reason CISA and NIST both keep pointing at FIDO.