Your phone asks you to approve a login. Then it asks again. A minute later, it asks a third time.

This is not a broken app. It may be an attacker who already knows your password and needs one tap from you to finish the login. The attack is called MFA fatigue, push bombing, or MFA bombing. It works because a technically valid security prompt can still be socially engineered.

TL;DR

  • Repeated MFA prompts usually mean someone is actively trying to use the account.
  • Never approve a prompt you did not start. Report it and change the password from a known-clean device.
  • Security teams should treat a burst of denied or unanswered prompts as an incident, not user error.
  • Number matching reduces accidental approval, but phishing-resistant MFA such as FIDO2 security keys and passkeys is stronger.
  • After one approval, investigate the account as compromised: revoke sessions, inspect new authentication methods, and review activity.

Why This Matters

MFA fatigue begins after another control has already failed. The attacker may have obtained a password through phishing, password reuse, malware, or a leak. They submit that password to the real identity provider, which sends a genuine approval request to the victim’s phone.

That last detail makes the attack confusing. The notification comes from the correct app. There may be no fake website on the phone and no obvious spelling mistake. The attacker is abusing the normal login flow.

CISA recommends phishing-resistant MFA as the strongest response. Where an organization cannot deploy it immediately, CISA recommends number matching as an interim defense against push fatigue. Number matching makes the user enter a number shown on the login screen instead of accepting a context-free Approve button.

The Attack Chain in Plain English

An MFA fatigue attack usually follows five steps:

  1. The attacker obtains a valid username and password. The source could be a phishing page, an infostealer, password spraying, or reused credentials.
  2. The attacker signs in to the real service. The password is correct, so the service generates an MFA request.
  3. The victim receives an unexpected prompt. The attacker repeats the login to create more prompts.
  4. Pressure replaces technical exploitation. The victim may approve by mistake, to stop the noise, or because the attacker calls while pretending to be support.
  5. The attacker establishes persistence. They may register another authenticator, create an application password, grant OAuth consent, or keep the issued session alive.

The MFA prompt is therefore not the beginning of the incident. It is evidence that the attacker may already have the first factor.

What the User Should Do

If you receive a prompt you did not initiate:

  1. Deny it. If the app offers a reason, select the option indicating that you did not attempt the login.
  2. Do not approve a later prompt to make the notifications stop. Approval completes the attack.
  3. Contact your real help desk through a known channel. Do not use a phone number or link supplied by an unexpected caller or message.
  4. Change the password from a trusted device. Use a new, unique password. If the device may have infostealer malware, isolate and examine it before using it for recovery.
  5. Review active sessions and registered authentication methods. Remove anything you do not recognize.

One accidental approval changes the response. Do not merely deny the next prompt and move on. Tell the security team exactly when the approval happened so they can correlate it with sign-in and application logs.

How Defenders Can Detect Push Bombing

The most useful signal is a sequence, not a single failed login. Look for:

  • several MFA challenges for one account within a short window;
  • repeated denials, timeouts, or fraud reports followed by one approval;
  • a password sign-in from a new network followed by MFA prompts to a known user;
  • an approved prompt followed by a new device, new MFA method, OAuth grant, mailbox rule, or privileged action;
  • help-desk calls in which someone asks the user to approve a prompt or read out a code.

A practical detection groups authentication events by account and session. Alert when the number of push challenges exceeds the user’s normal pattern, especially if the source IP, autonomous system, country, device, or user agent is new. A single threshold for every user will create noise; service accounts and test accounts should not receive interactive push prompts at all.

The critical pattern is:

valid password -> repeated MFA failures -> MFA success -> sensitive change

Preserve the challenge result, source address, device details, authentication method, session identifier, and subsequent account changes. Do not log OTP values, session cookies, or other secrets.

Controls That Actually Reduce the Risk

Prefer phishing-resistant MFA. FIDO2 security keys and properly implemented passkeys bind authentication to the legitimate site. They do not ask the user to approve an unrelated push request.

Enable number matching and context. Show the application and approximate location, and require the number from the initiating screen. This makes blind approval harder. It does not make the flow phishing-resistant: an attacker can still relay a number through a convincing phishing session.

Limit and rate-control prompts. Repeated challenges should trigger throttling, risk evaluation, and an alert. A user should not receive an unlimited stream of approval requests.

Protect authentication-method registration. Require strong, recent authentication before adding a new factor. Alert on new methods and notify the account owner through an independent channel.

Make reporting easy. A “report suspicious prompt” option should create a security event and a clear response workflow. Training should use one memorable rule: if you did not start the login, do not approve it.

Responding After a Suspicious Approval

Treat the identity as compromised until evidence shows otherwise.

  1. Disable or restrict the account if the business impact justifies it.
  2. Revoke active sessions and refresh tokens. Revocation may not be instantaneous across every application.
  3. Reset the password and investigate how it was obtained.
  4. Remove unrecognized authentication methods, application passwords, devices, OAuth grants, and recovery details.
  5. Review activity after the approval: email rules, file access, role changes, token creation, data export, and lateral movement.
  6. Re-enable access with a known-clean device and a phishing-resistant authentication method where possible.

Do not close the incident after a password reset alone. An already issued session or newly registered factor may survive that action, depending on the platform.

What You Can Do Today

  • Search the last 30 days of identity logs for accounts with repeated push denials or timeouts followed by success.
  • Turn on number matching if plain approve/deny push is still in use.
  • Confirm that users can report an unexpected prompt without searching for a help-desk number.
  • Test whether session revocation and authenticator removal work across your important applications.
  • Start moving administrators and other high-impact users to FIDO2 security keys or passkeys.

The goal is not to teach users to endure better harassment. It is to make an unsolicited prompt difficult to approve, visible to defenders, and insufficient for long-lived access.

Sources