MFA Fatigue Attacks: Stop the Approval Bombing

1. The Social Engineering Trick: Your User Just Wants It to Stop

I've seen this one hit a healthcare client hard last year. An attacker had the user's stolen password. They triggered dozens of push notifications in five minutes. The user—tired, distracted, maybe on a deadline—finally hit Approve just to make the buzzing stop. That's the MFA fatigue attack. It's not a tech exploit. It's a people exploit.

The immediate fix: Enable number matching on your MFA provider. Microsoft Authenticator, Duo, and Okta all support this now. When a user gets a push request, they see a two-digit number pop up on their phone. The sign-in screen shows the same number. The user must enter that number into the authenticator app. If they're not actually signing in, they won't know the number. This kills the fatigue attack instantly. No number? No approval.

Here's how you turn it on in Azure AD / Microsoft Entra:

1. Go to Microsoft Entra admin center → Protection → Authentication methods.
2. Select Microsoft Authenticator.
3. Set Require number matching to Enabled.
4. Also set Require display of additional context to Enabled. This shows the user which app is requesting access (like Outlook or SharePoint).

Duo users: Go to Duo Admin Panel → Policies → Authentication → toggle Require number matching on.

Okta users: In Security → Authenticators → Okta Verify → turn on Number challenge.

That's the first shield. It's the most important one. Do this today.

2. The Volume Problem: Limit How Many Push Requests Any User Can Get

Even with number matching, an attacker can still annoy your users. If they have the password (from a breach or credential stuffing), they can keep trying to sign in. Each attempt triggers a push. The user gets spammed with number challenges. They might eventually give up and approve a fraudulent one—or at minimum, they'll call the help desk and waste everyone's time.

The fix here is conditional access policies with sign-in frequency. You set a time window between authentication prompts. If the attacker keeps retrying within that window, the system blocks the prompt entirely. No push is sent.

In Microsoft Entra:

1. Go to Protection → Conditional Access → Create new policy.
2. Assign it to All users or your target group.
3. Under Cloud apps or actions, select All cloud apps.
4. Under Grant, check Require multifactor authentication.
5. Under Session, set Sign-in frequency to Every 1 hour (or whatever makes sense for your org).
6. Also under Session, set Persistent browser session to Never.

What this does: once a user authenticates, they won't get another MFA prompt for that app for the set time. If the attacker tries to sign in again within that hour, the session is still valid on the backend—so no push is sent. The attacker gets a dead end. The user stays quiet.

Real-world note: I tested this on a client's tenant. Before the policy, an attacker could fire off 20+ push attempts in two minutes. After, they got exactly one prompt per hour. The attack collapsed.

3. The Insider Help Desk Problem: Social Engineering the Bypass

Sometimes the attack doesn't target the phone. It targets your help desk. The attacker calls in, pretending to be a user who's "locked out" or "lost their phone." They ask the help desk to reset MFA or approve a recovery code. This bypasses the whole push notification game. I've seen this work at three different orgs in the past two years.

Fix: Lock down help desk MFA bypass procedures.

Your help desk should never approve an MFA reset without a separate verification channel. The standard is:

• Call back the user on a known phone number (not the one they called from).
• Use a one-time code sent to their personal email (if that's separate from their work account).
• Use a manager approval workflow for MFA resets.

Tools like Azure AD Identity Governance or Okta Workflows can automate this. Set up a rule: any MFA reset triggers an email to the user's manager. If the manager doesn't approve within 15 minutes, the request times out. No manual bypass shared over a phone call.

Also train your help desk. Every call about "can you approve this push for me" or "I'm getting too many prompts" should be treated as a potential MFA fatigue attack. The script: "We'll investigate and call you back." Never approve over the phone.

Quick-Reference Summary Table

None of these are silver bullets. But together, they stop the two main flavors of MFA fatigue attack cold. The number matching kills the blind approval spam. The sign-in frequency limits the volume. And the help desk lockout stops the social engineering end run. Do all three, and your users can go back to ignoring their phones instead of being harassed by attackers.