Approval fraud is the abuse of a trusted decision point, such as a wire release, banking-detail change, or executive sign-off, by deceiving the person who authorises it. The risk is not only message spoofing but the misuse of human discretion where the workflow lacks independent verification.
Expanded Definition
Approval fraud is a form of social engineering that targets a person’s authority to authorise a change, payment, release, or access decision. It is distinct from simple phishing because the attacker is not only trying to capture credentials or intercept a message, but to manufacture enough trust, urgency, or familiarity that a legitimate approver acts against normal verification practice. In security and identity operations, the term applies to workflows where a human decision point carries real effect, such as finance, privileged access, vendor banking updates, executive approvals, or recovery requests.
Definitions vary across vendors, but the practical security meaning is consistent: the fraud succeeds when an approval step depends on a single person’s judgment without a second, independent control. That makes approval fraud closely related to governance failures in identity, fraud prevention, and workflow assurance. The control objective aligns well with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where organisations need to separate request validation from authorisation. The most common misapplication is treating approval fraud as a messaging problem alone, which occurs when teams focus on email authenticity while leaving the underlying approval workflow exposed to impersonation and urgent-pressure manipulation.
Examples and Use Cases
Implementing strong approval controls rigorously often introduces friction, requiring organisations to weigh faster operations against the cost of additional verification steps, role separation, and escalation paths.
- A finance team receives a request to change supplier bank details after an “executive” email thread, and the approver authorises it without calling back through a known channel.
- An attacker impersonates a senior leader and pushes a wire transfer that bypasses a second approver because the process allows exceptions under time pressure.
- A help desk analyst approves an account recovery or MFA reset request after a convincing story, without checking an independent source of truth.
- A privileged access workflow accepts a manager’s approval for elevated access, but no separate validation confirms the business need, scope, or identity of the requester.
- An organisation uses CISA guidance on social engineering to train staff, then pairs that training with callback verification for any high-risk change request.
These cases show why approval fraud is often a process weakness rather than a single-point technical compromise. The attacker only needs one trusted path that is allowed to proceed on human recognition alone.
Why It Matters for Security Teams
Security teams need to understand approval fraud because it exploits the gap between identity assurance and business authority. A person may be properly authenticated, yet still be tricked into authorising the wrong action. That is why approval workflows should be treated as security controls, not just administrative convenience. In practice, this means introducing independent verification, stronger separation of duties, better change confirmation for high-risk events, and logging that supports later investigation.
The issue also intersects with identity governance and Non-Human Identity operations. Automated approvals, delegated authorisers, service accounts, and agentic AI workflows can all become trust amplifiers if they are allowed to trigger downstream actions without validation. Guidance in OWASP’s LLM security guidance and broader identity control practices reinforces the same principle: the authority to act must be bounded, traceable, and independently checked where the impact is material. Organisations typically encounter the full cost of approval fraud only after a payment, access grant, or recovery action has already been executed, at which point containment and reversal become operationally unavoidable.
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 surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST SP 800-63 set the technical controls, and DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Covers least-privilege access decisions that approval fraud can bypass. |
| NIST SP 800-53 Rev 5 | AC-5 | Defines separation of duties, a core defence against fraudulent approvals. |
| NIST SP 800-63 | IAL2 | Identity proofing strength matters when approvals depend on who is making the request. |
| OWASP Non-Human Identity Top 10 | Approval paths for service accounts and automation can become trust abuse points. | |
| DORA | Operational resilience expectations apply to fraudulent payment or change approvals in regulated firms. |
Add verification and escalation controls to payment and recovery workflows that can cause material loss.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
