MFA fatigue attacks: Stop account takeovers now

Cybersecurity & Malware Intermediate 👁 8 views 📅 May 26, 2026

MFA fatigue attacks flood users with push notifications until they approve. Here's how to lock them down with number matching and policy changes.

Yeah, you're getting hit with MFA fatigue attacks

It's annoying as hell — your users are getting hammered with push notifications at 2 AM, and eventually someone taps "Approve" just to make it stop. The attacker gets in, and you're cleaning up a breach by morning. Here's the fix.

The fix: Number matching in Authenticator

The single most effective change you can make is enabling number matching in Microsoft Authenticator. This kills the attack dead because the user has to enter a number displayed on the login screen into the app. A random push with no context gets ignored — or better, rejected.

Here's exactly how to do it in the Azure AD portal:

  1. Go to Azure Active Directory > Security > Authentication methods > Microsoft Authenticator.
  2. Click Settings (the gear icon) at the top.
  3. Set "Require number matching" to Enabled.
  4. Under "Show application name" and "Show geographic location", set both to Enabled. This gives users context so they know which login request is real.
  5. Click Save.

That's it. Takes five minutes. Users will grumble for a day because they have to look at the screen and type a number. Too bad — it's better than getting breached.

Why this works

MFA fatigue attacks rely on the attacker spamming push notifications until the user caves. Without number matching, the push just says "Approve sign-in?" with no additional info. Users trained to approve quickly will do it out of reflex. Number matching forces a conscious action — the user must see the number on the login page and type it into the app. If the attacker sends a push without the user initiating a login, the number doesn't match anything, and the user rejects it.

I've seen environments where this single change dropped successful MFA fatigue attacks from weekly incidents to zero over six months. It's not a silver bullet for everything, but for this specific attack, it's damn near perfect.

Less common variations of the same issue

1. Third-party MFA (Duo, Okta, RSA)

Microsoft's not the only one getting hit. Duo and Okta have similar problems with push fatigue. For Duo, enable "Require number matching" in the Duo Admin Panel under Policies > Push Authentication. Okta calls it "Okta Verify with number challenge" — turn it on in Security > Authenticators. Same concept, same fix.

2. Token-based attacks (TOTP fatigue)

Less common but I've seen it: attackers harvest TOTP codes from compromised SMS or email, then use them to bypass MFA. This isn't push fatigue, but it's related. The fix is to block SMS and email as MFA methods entirely. Use Authenticator or hardware keys (FIDO2/WebAuthn) for all privileged accounts. SMS is better than nothing, but barely.

3. User education failure

You can configure every policy perfectly, and users will still approve random pushes because they're tired or distracted. Some shops implement "MFA self-service reporting" — a Power Automate flow or custom app where users report suspicious pushes. This gives you data on who's ignoring their training so you can have a direct conversation with them. Don't skip this piece.

Prevention: Don't stop at number matching

Number matching stops the immediate attack, but you need broader defenses. Here's what I'd do tomorrow:

  • Set up Conditional Access policies that block MFA prompts from untrusted locations or impossible travel scenarios. If a login comes from New York and then Tokyo five minutes later, deny it.
  • Reduce session lifetimes. Keep users signed in for no more than 24 hours on non-privileged accounts. For admins, drop it to 8 hours or less. Longer sessions reduce the attack surface because there's fewer MFA prompts overall.
  • Enforce passwordless for admins. Move your global admins to FIDO2 keys or Windows Hello for Business. No push notifications at all — they authenticate with hardware or biometrics. This sidesteps the entire problem.
  • Monitoring and alerting. Set up Azure Monitor alerts for high volumes of failed MFA attempts from a single user within a short window. That's the classic sign of an MFA fatigue attack. Alert the SOC, or at least the IT team, so you can block the user's account before the attacker succeeds.
  • User training with real examples. Show users what a real MFA fatigue attack looks like — the flood of notifications, the weird times. Tell them to never approve anything they didn't initiate, and to report it immediately if they see a suspicious push. Make it a quick 5-minute video, not a 45-minute module they'll skip.

One more thing: don't bother with SMS as MFA for anything important. It's vulnerable to SIM swapping and interception. Number matching in Authenticator or hardware keys are the only practical defenses right now. If your users complain about having to type a number, tell them it beats resetting their password after a breach.

MFA fatigue attacks are lazy but effective. Don't let your users be the weak link. Turn on number matching today, lock down your policies, and move forward.

Was this solution helpful?