Why do push-based MFA prompts still get approved during attacks?

Because repeated prompts create annoyance, confusion, and habitual clicking, especially when the user thinks the requests are legitimate IT activity. The issue is not broken encryption. It is a human decision loop under pressure, which is why attackers can convert valid credentials into access without defeating the second factor technically.

Why This Matters for Security Teams

Push-based MFA succeeds when the attacker no longer needs to break the factor itself and instead exploits the person approving it. That makes this an identity and workflow problem, not a cryptography problem. Repeated prompts create fatigue, especially when the user expects routine support activity or assumes the request came from a legitimate admin. Attackers also pair MFA bombing with stolen passwords, helpdesk pretexts, or session hijacking, so the approval becomes the last human gate before access.

This is why guidance around phishing-resistant authentication keeps gaining traction in standards and operational playbooks. NIST’s security controls emphasize stronger authentication patterns, while current attacker tradecraft seen in the Microsoft Midnight Blizzard breach and the Anthropic report on AI-orchestrated cyber espionage shows how adversaries blend identity abuse with social engineering and automation. In NHI terms, the same pattern appears when attackers abuse service workflows, not just human logins. In practice, many security teams encounter this only after an account takeover or helpdesk abuse has already converted a valid credential into access.

How It Works in Practice

Push fatigue works because the prompt is designed for convenience. If a user sees multiple notifications in quick succession, they may approve one to stop the interruption, especially if the application name, IP, or support explanation feels plausible. That means the control is not evaluating intent, only asking for a binary response. Once an attacker has valid credentials, they can keep triggering prompts until the user or helpdesk makes the wrong decision.

Security teams reduce this risk by removing the attacker’s ability to turn repetition into consent. Current best practice is shifting toward phishing-resistant MFA, number matching, device binding, FIDO2/WebAuthn, and contextual checks that assess risk before issuing a challenge. NIST guidance on stronger authenticators is useful here, and the MITRE ATT&CK Enterprise Matrix helps teams map how initial access, credential theft, and valid account abuse chain together. For NHI-heavy environments, the underlying lesson is similar to what Ultimate Guide to NHIs — Why NHI Security Matters Now argues about machine identities: access decisions must reflect the actor, the context, and the workload, not just possession of a secret.

• Use number matching or phishing-resistant factors so a blind approval is no longer enough.
• Throttle repeated prompts and alert on anomalous push frequency, geography, device, or time-of-day.
• Bind approval to a known device and a trusted session, not just a username.
• Escalate to step-up verification for sensitive actions instead of generic login-only approval.
• Require helpdesk verification controls so social engineering cannot be converted into MFA resets.

These controls tend to break down in organisations that still rely on legacy VPNs, broad admin access, and weak helpdesk identity proofing because a stolen password plus repeated prompts can still reach a privileged session.

Common Variations and Edge Cases

Tighter authentication often increases user friction and helpdesk load, so organisations have to balance security against operational speed. That tradeoff is real, especially where mobile workers, contractors, or shared devices are common. Current guidance suggests that approval fatigue is worst when the same factor is used for every event, regardless of risk, but there is no universal standard for how many prompts becomes unsafe in every environment.

One important edge case is when attackers do not rely on prompt bombing alone. They may steal a session cookie, exploit an over-permissioned account, or use a legitimate SSO flow to make the login look routine. In those cases, MFA prompts become only one layer in a larger attack path, which is why the 52 NHI Breaches Analysis is relevant: once identity material is compromised, approval-based controls rarely hold on their own. CISA advisories and NIST controls both support layered detection, but the operational takeaway is simple. If a prompt can be repeated until someone clicks yes, it is not a strong final gate.

For high-risk roles, best practice is evolving toward pushing authentication decisions into the device, the authenticator, and the policy engine, rather than expecting users to make perfect judgments under stress.

Related resources from NHI Mgmt Group

• What do teams get wrong about push-based MFA?
• Why do push-based MFA methods fail in real-world attacks?
• What breaks when push-based MFA is exposed to repeated notification attacks?
• Why do password-based MFA controls still get bypassed in practice?