June 18, 2026 - 8 min read

By PhishClean Research Team

MFA Fatigue Attacks Are Rising - How to Defend

MFA fatigue attacks exploit a very human weakness: when a phone keeps buzzing with sign-in prompts, someone may approve one just to make the interruption stop.

Multi-factor authentication is still one of the most useful account protections available. MFA fatigue does not mean MFA failed as a concept. It means attackers are targeting the approval experience around weaker forms of MFA, especially push prompts that ask users to approve or deny a login.

The attack usually starts before the prompt. An attacker may already have a password from phishing, credential stuffing, malware, or a leaked database. Once the password works, they trigger repeated MFA prompts and wait for a tired, distracted, or confused user to approve one.

What MFA fatigue looks like

• Repeated push notifications arrive when you are not signing in.
• A message or call claims IT needs you to approve a prompt for testing or account recovery.
• The prompt appears during a stressful moment, such as a meeting, invoice deadline, or travel day.
• The attacker alternates between login attempts and social engineering to make the request feel official.

The goal is not technical elegance. The goal is pressure. The attacker wants the victim to stop thinking about whether the prompt is legitimate.

What to do if you receive unexpected MFA prompts

1. Deny the prompt. Do not approve it to clear the notification.
2. Change the account password from a clean, trusted device.
3. Review recent sign-ins and active sessions.
4. Report the event to IT or the service provider.
5. Check whether the account has new forwarding rules, recovery methods, app passwords, or OAuth app grants.

If you approved one by mistake, act quickly. Revoke active sessions, rotate the password, review account activity, and alert the people who manage the account. Approval may have created a valid session for the attacker.

What organizations should change

• Move privileged and high-risk users to phishing-resistant MFA.
• Require number matching or stronger challenge context for push prompts.
• Alert on repeated denied prompts, prompt bursts, and logins from unusual locations.
• Teach users to report unexpected prompts as security events.
• Investigate the source of the password exposure, not only the MFA event.

Why these attacks keep working

MFA fatigue survives because it attacks a workflow, not a protocol. The push prompt was designed to be fast and low-friction, and that is exactly what the attacker exploits. Approving is one tap; investigating takes effort. Repeat the prompt enough times and the odds shift toward the tap.

It is also cheap. Once a password works, replaying the login costs the attacker nothing, so they can spread attempts across nights, weekends, and time zones until they catch the victim at a weak moment. And because the approval arrives on a phone while the risky login happens elsewhere, the victim never sees the context that would give the game away: the unfamiliar location, the odd device, the login page that was never really the vendor's. Splitting the decision from the evidence is the whole trick.

A personal audit for push-prompt risk

You can lower your own exposure in under an hour:

1. List the accounts where MFA is a plain approve/deny push, then check whether the provider offers number matching, a passkey, or a hardware key, and upgrade where you can.
2. Fix the password layer that feeds these attacks. Reused passwords are what let credential stuffing turn one old leak into working logins on your current accounts.
3. Review recovery settings: phone numbers, backup emails, and app passwords you no longer recognize are how attackers keep access after you change a password.
4. Decide now what you will do when an unexpected prompt arrives - deny, then change the password. Having the plan in advance beats improvising while half-asleep.

How responders should scope a suspected fatigue attack

For security teams, a burst of denied prompts is evidence, not noise. The prompt spam proves the attacker already holds a valid password, so the investigation has two threads. First, contain the account: reset the credential, revoke sessions and refresh tokens, and check for new MFA methods, forwarding rules, or OAuth grants added around the event. Second, find the password's source - a phishing page the user visited, an infostealer on the device, or a reused credential from an external leak - because that source has usually touched more than one account.

Interview the user about what they clicked in the days before the prompts began; the guidance in what to do if you clicked a phishing link doubles as a useful scoping checklist. Closing the ticket after the deny, without tracing the credential, invites the same attacker back next month with better timing.

Why browser context still matters

MFA fatigue often begins with a browser event: a fake login page, a suspicious redirect, a credential-harvesting form, or an OAuth consent prompt. If that first step is blocked, the attacker never reaches the prompt-spam stage.

PhishClean helps by flagging risky login pages, suspicious redirects, and browser-side phishing signals before credentials or consent approvals become fuel for an MFA fatigue attack.