High-risk requests should require a separate approval path that does not depend on the same communication channel used to submit the request. This is especially important for payments, vendor changes, and privileged account actions. Independent verification reduces the chance that a convincing impersonation can turn into an authorised business action.
Why This Matters for Security Teams
When a request looks authentic, the real risk is not the wording alone. It is the possibility that a trusted channel, a familiar tone, or a convincing sender identity is being used to trigger a business action with real impact. High-risk approvals for payments, vendor updates, and privileged account changes should therefore be treated as identity events, not just workflow steps. NIST’s Cybersecurity Framework 2.0 reinforces the need for clear governance and access control around business-critical decisions, while NHIMG guidance on the Top 10 NHI Issues shows how identity abuse often sits inside ordinary operational processes until something is approved without independent verification. That is why approval design matters as much as detection. In practice, many security teams encounter fraudulent approval workflows only after money, access, or trust relationships have already been changed.
How It Works in Practice
The safest pattern is a separate approval path that does not rely on the same message thread, chat channel, or email chain used to submit the request. The approver should verify the request through an independent channel, then confirm both the requester’s identity and the business context before authorising anything irreversible. For high-risk actions, current guidance suggests using a second-person review plus a callback, ticket validation, or out-of-band confirmation tied to a known contact method rather than a reply address embedded in the request.
A practical workflow usually includes:
- classification of requests by impact, such as payment release, bank detail changes, or privilege escalation
- independent identity verification for the requester and the beneficiary
- separation of request submission, review, and approval responsibilities
- tamper-evident logging for the request, the approval, and the verification step
- time-bound escalation if the approver cannot validate the request promptly
This is consistent with NHIMG guidance in the Ultimate Guide to NHIs — Key Challenges and Risks, which highlights how identity sprawl and weak governance create approval exposure across ordinary workflows. It also aligns with the control discipline described in the Ultimate Guide to NHIs — Why NHI Security Matters Now, where privileged and overexposed identities increase the blast radius of a single successful deception. The approving person should never be the same person who first received the message if the request is high risk. These controls tend to break down when finance, procurement, or IT operations allow urgency to override verification because the attacker’s message arrives embedded in an otherwise normal business process.
Common Variations and Edge Cases
Tighter approval controls often increase friction, so organisations must balance fraud resistance against operational speed. That tradeoff becomes especially visible in payments, executive support, and third-party administration, where business leaders want fast turnaround but attackers benefit from any shortcut.
There is no universal standard for this yet, but current best practice is evolving toward risk-based approval tiers. Lower-risk requests may use a documented manager review, while high-risk requests should require two independent checks and a channel that is outside the attacker’s likely control. For example, a vendor bank-change request might need a known-call-back number plus a ticket reference, whereas a privileged access request may require approval from both the system owner and security operations.
Edge cases matter:
- executive impersonation often bypasses normal scepticism, so approvers need explicit pause-and-verify rules
- multi-step attacks may first change contact details, then exploit the updated record to approve the next request
- automated routing should not be the only safeguard because workflow tools can still carry fraudulent intent
The broader lesson is that authenticity of the message is not the same as legitimacy of the request. An attacker only needs one approval that is accepted as normal to turn a convincing impersonation into a completed change.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Separates approval authority from request intake for high-risk actions. |
| OWASP Non-Human Identity Top 10 | NHI-03 | High-risk approvals often expose compromised identities and over-privileged accounts. |
| NIST AI RMF | Supports governance around identity, accountability, and risky automated decision paths. |
Require independent verification before granting access or authorising sensitive business changes.
