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.
Expanded Definition
Push bombing is an MFA fatigue attack that targets the human approval step, not the authentication protocol itself. It sits in the same operational family as social engineering and help-desk abuse, but its defining trait is repetition: the attacker sends enough login prompts that a user eventually approves one to stop the disruption. In practice, that means the control fails because approval is treated as proof of intent.
Definitions vary across vendors about whether push bombing is a phishing variant, an MFA bypass, or an account takeover precursor. For NHI security teams, the useful interpretation is simpler: any workflow that depends on a single tap, swipe, or approval without additional context is vulnerable to user fatigue. That makes this concept highly relevant wherever human identity and non-human identity administration overlap, especially in delegated access, break-glass flows, and agent control planes. The NIST Cybersecurity Framework 2.0 is a useful reference point because it emphasizes robust authentication, access control, and continuous governance rather than treating a single authentication event as sufficient assurance.
The most common misapplication is assuming a push approval proves legitimacy, which occurs when organisations rely on default MFA prompts without number matching, device binding, or alerting on repeated failures.
Examples and Use Cases
Implementing MFA rigorously often introduces friction for legitimate users, requiring organisations to weigh faster access against stronger challenge-response controls and better monitoring.
- A help-desk attacker repeatedly triggers push requests during off-hours until a tired employee approves one, giving access to email, SaaS, or identity admin portals.
- A privileged operator receives multiple prompts while multitasking and accepts one without checking context, allowing lateral movement into systems that protect service accounts and secrets.
- An organisation uses the guidance in the Ultimate Guide to NHIs to recognise that human approval risk becomes more dangerous when the same workflow is used to grant access to automation, API keys, or agentic tools.
- A security team pairs push-bombing awareness with NIST Cybersecurity Framework 2.0 governance so repeated authentication failures trigger step-up verification, not just more prompts.
- A red-team exercise simulates fatigue-based approval to test whether administrators can distinguish a legitimate login from a prompt flood during a live incident.
In the NHI domain, the same pattern can also affect delegated access to consoles that mint or rotate Secrets, so approval friction must be designed around operational context, not convenience alone. The Ultimate Guide to NHIs is especially relevant when teams are deciding how much user interaction should remain in high-risk identity workflows.
Why It Matters in NHI Security
Push bombing matters because it exposes a structural weakness: when user approval becomes the security decision, attackers do not need to defeat cryptography or steal a password, only to force a mistaken approval. That risk grows in organisations that already have poor visibility into service accounts, shared admin paths, or secrets sprawl. NHI Mgmt Group research shows that only 5.7% of organisations have full visibility into their service accounts, which means human-factor compromise can quickly cascade into unmanaged non-human identities and privileged automation. The problem is not limited to login screens; it also affects any approval-based workflow used to authorise access to orchestration tools, cloud consoles, or AI agents.
For that reason, push bombing should be read alongside broader identity governance guidance in the Ultimate Guide to NHIs and mapped to the control objectives in NIST Cybersecurity Framework 2.0. A resilient response usually includes number matching, phishing-resistant authenticators, rate limiting, alerting on prompt bursts, and conditional access policies that treat repeated prompts as suspicious rather than routine.
Organisations typically encounter the business impact only after a user approves a fraudulent prompt and an attacker begins abusing the resulting session, at which point push bombing becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 | Covers authentication abuse and approval-driven bypass patterns against identities. |
| NIST CSF 2.0 | PR.AA-2 | Addresses authentication assurance and verifies identity before access is granted. |
| NIST Zero Trust (SP 800-207) | AC-7 | Zero Trust limits trust in single approvals and emphasizes continuous verification. |
Harden approval workflows with phishing-resistant factors and alerting for prompt flooding.
