What breaks is the assumption that sender identity proves request legitimacy. Attackers can spoof or compromise an account, then use familiarity and urgency to bypass normal scrutiny. If payments, vendor changes, or access approvals depend on email alone, the organisation has turned trust into a single point of failure.
Why This Matters for Security Teams
Email is a convenient notification channel, but it is a poor approval boundary. Once a request is treated as valid because it arrived in a familiar inbox, the organisation has collapsed authentication, intent, and authorisation into one fragile control. That is exactly where phishing, mailbox takeover, and business email compromise succeed: the sender looks legitimate, the request feels urgent, and the reviewer is pressured to act fast. The problem is not email itself, but using email as if it were a trusted transaction system.
This is especially dangerous for approvals that move money, change vendors, or grant access to sensitive systems. A compromised mailbox can be used to impersonate executives, bypass segregation of duties, and create a false audit trail that appears normal until after the damage is done. NIST’s NIST Cybersecurity Framework 2.0 emphasises governance and access control, but email-only approvals weaken both in practice. NHI Management Group’s analysis of the DeepSeek breach also shows how quickly exposed credentials and trust assumptions can be abused once attackers have a foothold. In practice, many security teams encounter approval fraud only after funds have moved or access has already been granted, rather than through intentional control testing.
How It Works in Practice
Email breaks down as an approval channel because it proves delivery, not legitimacy. A message can be replayed, forwarded, spoofed, or issued from a compromised account, and the inbox itself does not validate the underlying business context. For that reason, current guidance suggests moving approvals into systems that can verify identity, intent, and policy at the moment of decision. The most reliable models use strong authentication plus an independent workflow engine, not reply-all threads or “please confirm by email” habits.
Practically, that means approvals should be tied to a durable workflow with explicit request metadata, not just a message body. The approver should see what is being approved, why, by whom, for which asset, and within what policy threshold. For higher-risk actions, step-up verification or two-person review is more defensible than relying on inbox recognition. This also supports auditability because the decision is recorded in a system of record rather than scattered across mailboxes.
- Use email for notification, but require approvals in a dedicated workflow or ticketing system.
- Bind approvals to authenticated user identity, request ID, asset, amount, and timestamp.
- Apply segregation of duties for payments, vendor changes, privileged access, and recovery actions.
- Escalate high-risk requests to step-up authentication or out-of-band confirmation.
Where the risk involves secrets or credential changes, the stakes are higher because a forged approval can unlock lateral movement. NHI Management Group’s The State of Secrets in AppSec notes how persistent secrets-management gaps keep exposure windows open long after a mistake is made. The control objective is simple: email may inform a human, but it should not be the system that authorises the action. These controls tend to break down in organisations that allow shared mailboxes, informal executive overrides, or manual exception handling because the approval path becomes indistinguishable from ordinary correspondence.
Common Variations and Edge Cases
Tighter approval controls often increase process overhead, requiring organisations to balance speed against fraud resistance. That tradeoff is real, especially in lean teams that handle urgent vendor payments, incident response, or production access requests. Current guidance suggests tailoring friction to risk rather than forcing every request through the same gate.
Some low-risk operational confirmations can still begin in email, but the final approval should move to a system that enforces identity proofing, logging, and policy checks. For example, a purchase acknowledgement might be acceptable by email if it does not trigger release of funds, while a payment release or privilege escalation should not. There is no universal standard for this yet, but best practice is evolving toward context-aware approval paths with explicit risk thresholds.
Teams should also be careful not to confuse email authentication with approval integrity. SPF, DKIM, and DMARC help reduce spoofing, but they do not stop a compromised account from approving a harmful request. For that reason, email controls and approval controls must be treated separately. A mailbox can be authentic and still be acting under attacker control. That distinction matters most when organisations route vendor onboarding, bank detail changes, and emergency access through inbox replies because those are the exact cases where attackers exploit trust, urgency, and routine.
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 | Email-only approvals weaken access governance and least-privilege enforcement. |
| OWASP Non-Human Identity Top 10 | NHI-05 | Mailbox compromise turns a trusted identity into an approval bypass path. |
| NIST AI RMF | AI RMF governance principles apply to workflow trust and decision accountability. |
Treat email accounts as NHI attack surfaces and require stronger approval controls than inbox trust.
