MFA Fatigue Attacks: Why Repeated Prompts Are a Warning

An unexpected sign-in approval means someone may already know the password. In an MFA fatigue attack, the attacker sends repeated push prompts and waits for the user to approve one through confusion, habit or frustration.

The attack in four steps

1. A password is obtained through phishing, reuse or malware.
2. The attacker starts a real login.
3. The service sends an approval prompt to the legitimate user's device.
4. Prompts continue until one is approved or the attacker changes tactics.

Some attackers follow with a phone call pretending to be IT support. The call is not proof of legitimacy; it is part of the pressure.

What to do immediately

• Deny the request and do not share a code or approve a number.
• Open the official service directly and change the password from a trusted device.
• Review active sessions, registered MFA methods and recovery details.
• Report the event to the employer or service security team.

Make prompts harder to abuse

Enable number matching when available so the login screen and approval device must show the same value. Prefer passkeys or hardware security keys for important accounts because they bind authentication to the legitimate domain. Remove old phones and unused approval methods.

For administrators

Investigate repeated denied prompts rather than treating them as user error. Apply rate limits, require number matching, alert on unusual locations and migrate privileged accounts to phishing-resistant authentication. Help-desk staff should verify identity through an established process instead of asking a user to approve a surprise prompt.

The key lesson is simple: MFA fatigue is usually evidence of an earlier control failure. Stop the prompts, rotate the exposed password and inspect the account before returning to normal use.

The correct response to repeated prompts

Deny the request, then open the service through a known bookmark and inspect active sessions. Change the password if it may be known, revoke remembered devices, and report the event. Do not approve one prompt merely to stop the notifications: that single approval can create a valid session for the attacker.

Controls that reduce prompt bombing

Number matching forces the user to see a value from the login screen, but it is not a complete defence if the victim is socially engineered into reading that value. Device context, location, risk-based rules, rate limits and phishing-resistant credentials provide stronger layers. Help desks should treat sudden floods of denials as an incident rather than a usability complaint.

For a team exercise, send no real prompts. Walk through a fictional alert and ask each employee where they would report it, which account page they would open, and how they would revoke sessions.