MFA Isn't Enough: Stopping Prompt-Bombing Attacks in Microsoft 365

MFA prompt-bombing is one of the simplest attacks in an adversary’s playbook, and it keeps working. The attacker already has a user’s stolen credentials. They trigger a flood of push notifications to the user’s phone, over and over, until the user approves one out of frustration, confusion, or just wanting the buzzing to stop.

The 2025 Verizon Data Breach Investigations Report found that stolen credentials remain the top initial access vector, which means the pool of accounts vulnerable to prompt-bombing grows with every breach. Microsoft’s Digital Defense Report has cited hundreds of thousands of MFA fatigue attempts blocked annually, though the specific figures vary across report editions.

The good news: Microsoft 365 includes tenant-level controls that can shut down this attack entirely. Here is how to confirm your current configuration and close any remaining gaps.

How Prompt-Bombing Plays Out

The attack starts with a valid username and password. Attackers buy these in bulk from credential dumps, harvest them through phishing, or extract them using infostealer malware that scrapes saved browser passwords. Once they have working credentials, the MFA prompt becomes the only thing standing between the attacker and full account access.

In a prompt-bombing attack (also called MFA fatigue), the attacker repeatedly attempts to sign in, triggering a push notification to the user’s Microsoft Authenticator app each time. The notifications arrive in rapid succession. Some attackers time them for early morning or late evening, when the user is groggy and more likely to tap “Approve” without thinking. Others combine the push flood with a phone call or text, posing as IT support and telling the user to approve the notification to “fix” an account issue.

This is exactly how the Uber breach in September 2022 unfolded. A threat actor affiliated with Lapsus$ purchased an Uber contractor’s credentials on the dark web, then bombarded the contractor with MFA push requests for over an hour. When the notifications alone didn’t work, the attacker contacted the contractor on WhatsApp, impersonating Uber IT support and instructing them to approve the prompt. The contractor complied.

From that single approved push, the attacker accessed Uber’s internal systems, Slack, cloud consoles, and vulnerability reports. Cisco disclosed a similar breach the same year, where an attacker used a combination of MFA fatigue and voice phishing to gain VPN access to corporate systems.

The pattern is consistent: the attacker doesn’t break MFA. They wear down the human behind it.

Why Default MFA Configuration Leaves You Exposed

Standard push-notification MFA presents a simple binary choice on the user’s phone: Approve or Deny. There’s no verification that the person approving the prompt is the same person who initiated the sign-in attempt. The user sees a notification, taps a button, and the authentication succeeds. Under normal conditions, this works fine because the user is the one logging in. During a prompt-bombing attack, that simplicity becomes a vulnerability.

The problem compounds when tenants rely on per-user MFA, the legacy method configured directly on individual accounts in the Microsoft 365 admin center. Per-user MFA applies the same MFA requirement to every sign-in regardless of context. It has no concept of sign-in risk, device compliance, or geographic location, and it doesn’t distinguish between a login from your office network and one from a VPN exit node in another country. Every attempt triggers the same push notification with the same Approve/Deny choice.

Microsoft has been pushing organizations toward Conditional Access policies for years because they provide the contextual evaluation that per-user MFA lacks. If your tenant still uses per-user MFA, migrating to Conditional Access is the highest-impact change you can make. We covered this migration, along with other commonly missed settings, in our post on M365 security configurations SMBs get wrong.

Five M365 Controls That Shut Down Prompt-Bombing

Each of these controls is available in Microsoft 365 Business Premium and E5 plans (E3 tenants need an Entra ID P2 add-on for control #3). Applied together, they eliminate prompt-bombing as a viable attack path against your tenant.

1. Number Matching in Microsoft Authenticator

Number matching changes the MFA prompt from a simple Approve/Deny button to a verification step. When a sign-in triggers MFA, the browser displays a two-digit number. The user must enter that exact number in the Authenticator app to complete authentication. An attacker spamming push notifications can’t tell the user which number to type because the number changes with each attempt and only appears on the sign-in screen the attacker controls.

Microsoft enforced number matching as the default for all Authenticator push notifications in May 2023 and removed the ability to disable it. Confirm it is active in your tenant and document the configuration. Navigate to Entra admin center > Protection > Authentication methods > Microsoft Authenticator and verify that number matching is enabled for all users.

2. Additional Context in Push Notifications

This feature adds the application name and the geographic location of the sign-in attempt to the push notification. Instead of a generic “Approve sign-in?” prompt, the user sees “Approve sign-in to Microsoft Office 365 from Dallas, TX?” If the user is sitting in their office in Houston and gets a notification showing a sign-in from an IP geolocating to Eastern Europe, the mismatch is immediately obvious.

Additional context is configured in the same Entra ID authentication methods blade as number matching. Enable both “Show application name” and “Show geographic location” under the Microsoft Authenticator settings. This feature pairs well with number matching. Together, they change the MFA prompt from a reflexive tap into a deliberate decision.

3. Conditional Access Risk-Based Policies

Conditional Access with Identity Protection evaluates every sign-in against Microsoft’s risk detection engine. The engine analyzes signals like impossible travel (logging in from two distant locations within minutes), unfamiliar sign-in properties, anomalous token activity, and known-malicious IP addresses. Based on those signals, each sign-in gets classified as low, medium, or high risk.

Two policies matter most for stopping prompt-bombing:

Sign-in risk Conditional Access policy: Configure a Conditional Access policy that blocks access or requires a password change for sign-ins classified as medium or high risk. A prompt-bombing attack from an attacker’s IP address, especially one flagged for previous malicious activity or originating from an atypical location, will trigger elevated risk and get blocked before the MFA prompt ever reaches the user.

User risk Conditional Access policy: When Microsoft detects that a user’s credentials have been compromised (appearing in known breach databases, for example), the user is flagged as high-risk. A user risk Conditional Access policy can require the user to perform a secure password reset and re-register MFA methods before regaining access. This breaks the prompt-bombing chain at the source by invalidating the stolen credentials.

Both policies require Microsoft Entra ID P2 licensing, included in Business Premium and E5. Configure them in Entra admin center > Protection > Conditional Access > Policies. Microsoft provides policy templates that cover both scenarios.

4. FIDO2 Security Keys and Passkeys for Admin Accounts

Prompt-bombing can only work against MFA methods that rely on push notifications or one-time codes. FIDO2 security keys and passkeys are immune because they don’t involve a push notification at all. Authentication happens through a cryptographic handshake between the security key (or device-bound passkey) and Microsoft’s identity platform. There’s nothing to approve, nothing to bomb.

FIDO2 authentication is also phishing-resistant. The credential is cryptographically bound to the legitimate Microsoft login domain, so it won’t respond to proxy-based AiTM phishing attacks either. For a deeper look at how AiTM attacks bypass traditional MFA by stealing session tokens in real time, that post covers the attack chain and M365-specific defenses.

At minimum, require FIDO2 security keys or passkeys for all accounts with administrative roles: Global Administrator, Exchange Administrator, Security Administrator, and any role with write access to Conditional Access policies. A compromised admin account can disable your MFA policies entirely, so protecting those accounts with the strongest available authentication method is critical.

Enable FIDO2 security keys in Entra admin center > Protection > Authentication methods > FIDO2 security key. Microsoft has also expanded passkey support to work with Windows Hello, Apple Face ID/Touch ID, and Android biometrics, which makes deployment practical without issuing hardware tokens to every user.

5. Authentication Strength Policies for Privileged Roles

Conditional Access authentication strength policies let you define which MFA methods are acceptable for specific scenarios. Instead of allowing any MFA method (push notification, SMS code, TOTP app) across the board, you can create a policy that requires phishing-resistant MFA for privileged roles while allowing standard Authenticator-based MFA for regular users.

Microsoft includes three built-in authentication strength levels: MFA strength (any MFA method), passwordless MFA strength, and phishing-resistant MFA strength. For admin accounts, assign the phishing-resistant MFA strength. This ensures that even if an attacker compromises an admin’s password and attempts prompt-bombing, the attack fails because push notifications aren’t accepted for that account. Only FIDO2 keys, passkeys, or certificate-based authentication will satisfy the policy.

Configure authentication strength in Entra admin center > Protection > Authentication methods > Authentication strengths, then reference the strength requirement in your Conditional Access policies targeting admin roles.

Prompt-Bombing Is One Piece of a Larger Problem

MFA fatigue attacks exploit a specific weakness in push-based authentication. But they’re part of a broader category of MFA bypass techniques that every M365 tenant needs to account for. AiTM phishing intercepts authenticated session tokens through proxy servers, bypassing MFA entirely without the user denying or approving anything. Infostealer malware harvests session cookies from browsers, giving attackers authenticated access days or weeks after the initial infection.

Each of these attacks targets a different part of the authentication flow, but they share a common lesson: MFA is a necessary control, not a sufficient one. Conditional Access policies, phishing-resistant credentials for privileged accounts, token protection, and continuous monitoring all matter. CISA’s guidance on phishing-resistant MFA recommends FIDO2-based authentication as the gold standard and explicitly calls out push-notification MFA as vulnerable to fatigue attacks.

The five controls outlined above are available in the licensing tiers most SMBs already own. The gap is implementation, and the gap stays open until someone configures these settings in your tenant. If your M365 security hasn’t been reviewed since initial setup, or if your organization still relies on per-user MFA and basic push notifications, these are the highest-priority changes on the list. Our Microsoft 365 consulting and managed security teams work with SMBs across Texas and Oklahoma to close exactly these gaps.