Push bombing exposes the weakness in legacy MFA controls

At a glance

What this is: This is an analysis of push bombing, also called MFA fatigue, and why repeated approval prompts remain a practical bypass for legacy multi-factor authentication.

Why it matters: It matters to IAM and NHI practitioners because authentication flows that depend on user approval can be coerced, which undermines assurance for both human and non-human access patterns.

👉 Read Beyond Identity's analysis of push bombing and cryptographic MFA

Context

Push bombing is an authentication abuse pattern, not a malware family or a new protocol. The attacker already has credentials or another foothold, then overwhelms the target with repeated login prompts until one approval slips through. For IAM teams, the problem is not only user fatigue. It is that the control itself assumes the user will reliably distinguish legitimate access from abuse under pressure.

The NHI governance connection is direct. Any access model that depends on human approval, especially when it is repeated, noisy, or mobile-dependent, creates a trust gap that does not map well to service accounts, workload identities, or AI agents. In that sense, push bombing is a reminder that authentication design and identity assurance must be evaluated together, not as separate problems. The starting position described in the article is typical for enterprises that still rely on approval-based MFA.

Key questions

Q: How should security teams reduce the risk of MFA fatigue attacks?

A: Security teams should remove approval-based MFA from high-risk access paths, replace it with cryptographic authentication, and reduce the privileges attached to any successful session. They should also detect repeated prompt events as attack signals, not user noise, and trigger response when requests spike unexpectedly.

Q: What is the difference between push-based MFA and phishing-resistant authentication?

A: Push-based MFA asks a person to approve a login request, which attackers can abuse through fatigue or social engineering. Phishing-resistant authentication binds access to a device or key and verifies possession cryptographically, so the attacker cannot win by repeatedly asking for approval.

Q: Why do repeated login prompts create more risk instead of more security?

A: Repeated prompts increase the chance of a mistaken approval and condition users to treat alerts as routine. That turns the authentication step into a behavioural test under pressure, which attackers can manipulate far more easily than they can break cryptographic controls.

Q: How can IAM teams apply the same lesson to non-human identities?

A: IAM teams should avoid workflows that depend on human approval to authorize service accounts, tokens, or AI agents at runtime. Non-human identities should be bound to policy, lifecycle state, and revocation controls so access cannot expand just because a human accepted a request.

Technical breakdown

Why push-based MFA fails under pressure

Push-based MFA asks a user to approve a login request through a mobile prompt or code. That design creates three failure modes: interruption, where the prompt arrives at the wrong time; habituation, where users become trained to approve quickly; and coercion, where repeated prompts create fatigue. The security issue is not the number of prompts alone. It is that approval becomes the trust decision, and the attacker only needs one mistake. This is why MFA fatigue works well against busy users and poorly monitored response paths. In identity terms, the control measures attention instead of proving possession or binding access to a trusted device.

Practical implication: Teams should treat approval-based MFA as a weak trust signal and measure how quickly users can be forced into an unsafe approval path.

Cryptographic authentication versus approval by prompt

Cryptographic authentication removes the decision from the user at login time. Instead of asking for a human response, the system validates device-bound keys and policy conditions such as device state, key integrity, and security posture. If those checks fail, the attempt is denied without asking for approval. That shifts the control from behavioural trust to cryptographic assurance. In practical terms, the difference is between asking a person to recognize risk and forcing the system to verify identity properties directly. For NHI governance, the same pattern matters because machine identities should be validated by binding, lifecycle state, and policy, not by human intervention.

Practical implication: Use cryptographic binding and device policy checks where the business cannot tolerate a human being the final authentication gate.

Push bombing as an identity assurance failure

Push bombing is best understood as an assurance failure in the authentication layer. The attacker does not need to defeat encryption or compromise the MFA channel directly. They exploit the social and operational gap between a legitimate prompt and a malicious flood of prompts. That makes the attack especially effective in environments with alert fatigue, distributed work, and inconsistent device management. For IAM leaders, the lesson is that authentication strength is not just about the factor used. It is about whether the factor can be manipulated into approving the wrong session. The same logic applies to NHI workflows when approvals, tokens, or delegated grants are too easy to trigger without strong policy context.

Practical implication: Revisit any authentication flow where repeated prompts, delegated approvals, or weak device signals can turn a valid login into an attacker-controlled session.

Threat narrative

Attacker objective: The attacker wants a single approved prompt that opens the account without needing to defeat the underlying MFA technology.

1. Entry begins when the attacker obtains valid credentials or another login foothold and starts generating repeated authentication prompts against the target account.
2. Escalation occurs when prompt flooding creates fatigue, confusion, or urgency, making one mistaken approval more likely.
3. Impact follows the single approval, which grants account access and often avoids immediate alerting or detection.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Approval-based MFA is a trust shortcut that attackers can exploit at scale. The article reinforces a broader identity lesson: if the control depends on a tired human making the final decision, it is not a high-assurance factor. Enterprises should stop describing push approval as a strong second factor when the threat model already includes prompt flooding. Practitioners should treat any user-mediated approval step as a compensating control, not a durable authentication boundary.

Push bombing exposes an identity blast radius problem. One mistaken tap can convert a noisy authentication event into full account compromise, which means the blast radius is defined by the privileges attached to the session, not just the login method. That is why MFA hardening must be paired with least privilege, session constraints, and fast revocation. Practitioners should reduce the value of any single approval by shrinking the privilege tied to the resulting session.

Cryptographic prompt removal is the right model when user attention cannot be trusted. A design that authenticates the device and policy state directly is structurally different from a design that asks users to approve access under stress. For IAM programs, this is a reminder that stronger identity assurance often comes from removing the human decision point, not adding more friction around it. Practitioners should prioritize controls that can verify identity without depending on user discipline.

Push bombing is also a warning for NHI governance because the same approval logic shows up in machine workflows. Service accounts, tokens, and AI agents often inherit access paths that were designed for humans, including approval chains, delegated grants, and loosely monitored prompts. That creates inconsistent assurance across the identity estate. Practitioners should align human and non-human access governance around binding, lifecycle, and revocation, not around convenience-driven approval habits.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which leaves many machine identities outside effective governance.
• Forward pivot: For lifecycle and rotation controls, see Ultimate Guide to NHIs and the 52 NHI Breaches Analysis for breach-pattern context.

What this signals

Identity programs should assume that user-mediated approval is an attacker-controllable variable. Once prompt flooding is part of the threat model, teams need to move beyond authentication metrics and measure how much damage a single approved session can do. That is where least privilege, session duration, and fast revocation become the practical controls that matter most.

With 97% of NHIs carrying excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs, the same blast-radius logic applies to machine access. If the organisation cannot bound privilege for service accounts and AI agents, then removing push prompts from human login flows only solves part of the governance problem.

For practitioners

• Replace approval-only MFA for high-risk access Move privileged and remote access to phishing-resistant, cryptographic authentication that does not depend on push approval under pressure. Prioritise admin, finance, and support accounts first, then remove legacy push flows where users can be spammed into granting access.
• Tighten session scope after authentication Limit what a single approved login can do by applying session time limits, step-up checks for sensitive actions, and tighter privilege boundaries. That reduces the blast radius when a prompt is approved in error.
• Instrument prompt abuse detection Track repeated MFA requests, rapid retries, and approval spikes as security signals rather than user inconvenience. Feed those events into response workflows so that prompt flooding can be blocked or escalated before one approval succeeds.
• Apply NHI controls to delegated workflows Review service accounts, API tokens, and AI agent grants for any human approval dependency or overly broad delegated access. Bind those identities to lifecycle controls, rotation, and revocation so they do not inherit weak human-authentication patterns.

Key takeaways

• Push bombing works because it turns authentication into a human fatigue test instead of a cryptographic trust check.
• Repeated approval prompts are dangerous when they can convert one mistaken tap into broad account access.
• IAM and NHI teams should reduce risk by replacing approval-driven access with bound identity, narrow privilege, and rapid revocation.

Key terms

• Push Bombing: Push bombing is an MFA bypass technique that overwhelms a user with repeated authentication prompts until one approval is granted. The attack depends on fatigue, distraction, or confusion, not on breaking the underlying cryptography. It is effective because many organisations still treat user approval as a trustworthy security signal.
• MFA Fatigue: MFA fatigue is the behavioural pressure created when repeated login prompts make a person more likely to approve access without checking carefully. It is a control failure in the authentication experience, and it becomes dangerous when the approved session carries broad privilege or long-lived access.
• Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.
• Identity Blast Radius: Identity blast radius is the amount of access, data, and systems exposed when a single identity is compromised. In practice, it is determined by privilege scope, session length, delegated permissions, and revocation speed. The smaller the blast radius, the less damage one successful authentication can cause.

Deepen your knowledge

Push bombing, MFA fatigue, and cryptographic authentication are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is rethinking how identity assurance should work across human and non-human access, it is worth exploring.

This post draws on content published by Beyond Identity: What Is Push Bombing? And How Beyond Identity Makes It Impossible. Read the original.