Why does prompt bombing work against MFA users?

Prompt bombing works because repeated requests create fatigue, and fatigue pushes users toward approval without careful review. The attacker is exploiting human exhaustion, not breaking the factor itself. Organisations should limit repeated prompts, add request context, and make suspicious login attempts easier for users to recognise quickly.

Why Prompt Bombing Works Against MFA Users

prompt bombing succeeds because MFA is only as strong as the person approving the request. The attacker does not need to defeat the second factor if they can exploit fatigue, distraction, or a moment of trust. This is why repeated push prompts, vague login notifications, and busy response workflows are high-risk patterns in practice. NIST’s NIST Cybersecurity Framework 2.0 reinforces that protective controls must be paired with usable detection and response.

For NHIs and human users alike, the lesson is the same: authentication events need context, rate limits, and escalation paths. NHIMG research on the Microsoft Midnight Blizzard breach and the DeepSeek breach shows how credential exposure and social engineering often complement one another rather than operating as separate attack paths. In practice, many security teams encounter prompt bombing only after a user has already approved a malicious session and the attacker has moved laterally.

How MFA Fatigue Becomes a Real-World Attack Path

Prompt bombing works best where MFA is implemented as a simple yes or no push without strong context. The attacker initiates repeated authentication attempts until the user accepts just to stop the notifications. In some environments, this is paired with stolen passwords, token replay, or help desk impersonation, which makes the request look routine instead of suspicious.

Current guidance suggests reducing the number of opportunities for a mistaken approval rather than relying on user vigilance alone. Useful controls include:

• Rate limiting repeated MFA prompts and locking suspicious sequences.
• Adding request context such as location, device, application, and time.
• Using number matching or cryptographic challenge-response instead of simple approve-deny pushes.
• Alerting users on impossible travel, new device enrollment, or repeated denials.
• Combining MFA with conditional access and device trust signals.

For broader identity governance, the State of Secrets in AppSec report highlights how exposed secrets and weak operational habits create the conditions attackers need to reach the prompt stage in the first place. The control objective is not just to authenticate, but to make each request intelligible to the user and evaluable by policy at runtime. This guidance breaks down most often in high-volume service desks and shift-based operations because users normalize repeated prompts as background noise.

Where the Standard Answer Breaks Down

Tighter MFA controls often increase user friction, requiring organisations to balance security against login speed and support burden. That tradeoff becomes especially important in environments with legacy VPNs, shared endpoints, or globally distributed workforces where prompt frequency can be high. Best practice is evolving, and there is no universal standard for exactly how much context is enough.

The most common edge case is a user who is already under operational stress, such as during incident response, on-call rotations, or travel. In those settings, even strong controls can fail if the notification lacks clarity or the user cannot tell whether the prompt is expected. Organisations should treat repeated MFA challenges as an anomaly signal, not normal behaviour, and route them into detection workflows that can trigger temporary account protection or step-up verification.

Prompt bombing also becomes more effective when attackers mix it with session theft, adversary-in-the-middle phishing, or push fatigue across multiple channels. A single control rarely solves this alone. Current guidance suggests pairing MFA with phishing-resistant methods, user education, and fast revocation paths so that one mistaken approval does not become a full compromise.

Related resources from NHI Mgmt Group

• How should security teams reduce MFA prompt bombing risk?
• What should organisations do when users work around MFA or other access controls?
• Why do fake verification pages work so well against users?
• How should financial institutions close MFA gaps across legacy systems?