Approval abuse is the misuse of normal business authorisation steps to complete a harmful action, such as a payment, reset, or access change. The weakness is usually procedural rather than technical, because the attacker only needs one approving human to treat a malicious request as valid.
Expanded Definition
Approval abuse occurs when an attacker turns a normal business approval path into a control bypass, using legitimate-looking requests to obtain a payment, reset, or access change. In NHI and IAM environments, the target is often the person or process that signs off on the action, not the system that executes it. That makes the weakness procedural, but the impact is operational and security-critical.
Definitions vary across vendors on whether approval abuse is treated as social engineering, business email compromise, or workflow manipulation. NHI Management Group treats it as a distinct governance failure because the attacker succeeds by exploiting trust in an approval state rather than by breaking authentication directly. It is closely related to segregation-of-duties failures, weak escalation paths, and over-broad delegated authority, and it becomes more dangerous when the request concerns credentials, secrets, or privileged access. For broader identity-risk context, see the Ultimate Guide to NHIs and the access-control expectations in NIST Cybersecurity Framework 2.0.
The most common misapplication is treating approval abuse as a simple phishing problem, which occurs when organisations ignore workflow design and rely on human caution alone.
Examples and Use Cases
Implementing approval controls rigorously often introduces more friction and review time, requiring organisations to weigh operational speed against the cost of a compromised approval chain.
- A finance approver receives a payment change request that mirrors a known vendor pattern, but the destination account is controlled by the attacker.
- A help desk technician approves a password reset or MFA reset because the request appears to come from a legitimate employee, enabling account takeover.
- An admin signs off on a temporary privilege elevation for a service account, but the request actually expands standing access beyond the approved window.
- A workflow in a CI/CD or cloud platform routes a secret or token request to a single approver with no secondary verification, allowing unauthorised issuance.
- A third-party access request is approved without validating business need, creating a path into internal systems through a trusted partner relationship.
These patterns align with the broader NHI risk picture described in the Ultimate Guide to NHIs, where weak governance and excessive privilege turn small process errors into durable access paths. For a standards view of access governance, the NIST Cybersecurity Framework 2.0 reinforces that approvals must support controlled and reviewable access decisions.
Why It Matters in NHI Security
Approval abuse matters because NHIs often depend on human sign-off to create, rotate, approve, or extend machine access. If that approval layer is weak, attackers can obtain API keys, service account changes, token issuance, or privilege elevation without defeating technical defenses. This is especially serious in environments where secrets are already overexposed and approvals are the last barrier before issuance. NHI Management Group research shows that 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, which helps explain why approval failures quickly become real incidents instead of theoretical risks.
Approval abuse also undermines Zero Trust because the control plane is supposed to verify every request, not merely trust a familiar-looking workflow. When a single approver can authorise sensitive NHI actions, attackers can chain one mistaken decision into persistence, lateral movement, or data exposure. Practitioners typically encounter the operational cost only after a fraudulent approval has already been executed, at which point approval abuse becomes unavoidable to investigate and contain.
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 approval and privilege abuse that leads to unsafe NHI access changes. |
| NIST CSF 2.0 | PR.AC-4 | Addresses controlled access decisions and least-privilege enforcement in approvals. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires explicit verification of every access-related request, including approvals. |
Require multi-step verification before approving NHI creation, reset, or privilege elevation.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
