How can organisations reduce the risk of request-based fraud through email?

Why This Matters for Security Teams

Request-based fraud through email succeeds when people treat a familiar message thread as proof of authority. The core problem is not the inbox itself, but the way approvals get decoupled from independent identity verification. Attackers exploit urgency, impersonation, and business context to make a request feel routine, then use that trust to push payments, change bank details, reset credentials, or expand access. That is why guidance aligned to the NIST Cybersecurity Framework 2.0 emphasizes protective controls around identity, authorisation, and response, not just message filtering. It also aligns with the patterns described in Top 10 NHI Issues, where weak verification and over-trust in standing access create predictable failure points. In practice, many security teams encounter email-driven fraud only after a payment has been routed, a mailbox rule has been added, or a privileged request has already been approved.

One practical indicator of the wider control gap is that only 44% of developers are reported to follow security best practices for secrets management, showing how often identity and approval hygiene lag behind policy intent in real environments, according to The State of Secrets in AppSec.

How It Works in Practice

Effective controls make email a notification channel, not an approval channel. That means the request can arrive by email, but the authorisation must happen in a separate workflow with independent identity proof, strong audit logging, and context-aware approval rules. For sensitive actions, organisations should require out-of-band verification through a known channel, such as a call-back to a pre-registered number, a portal login with phishing-resistant MFA, or a second approver who has no conflict of interest.

Common practical steps include:

• Separating request submission from approval so the approver is not validating the same email thread they received.
• Using pre-approved templates for payment changes, credential resets, and privilege changes.
• Applying least privilege so a single approved request cannot cascade into broad access.
• Flagging high-risk language such as urgency, secrecy, or bank-detail changes for mandatory review.
• Logging the independent identity check, the approving user, and the business context for later review.

This approach is strongest when paired with the identity and access discipline described in Ultimate Guide to NHIs — Why NHI Security Matters Now, because attackers often combine email fraud with stolen credentials or abused service accounts once the first request lands. The operational model is simple: email can initiate a workflow, but it should never be sufficient evidence that the requester is authorised to move money or alter access. These controls tend to break down in shared mailboxes and fast-moving finance or IT service desks because staff shortcut the second-channel verification when volume spikes.

Common Variations and Edge Cases

Tighter verification often increases friction, so organisations have to balance fraud resistance against business speed, especially for time-sensitive payments and executive requests. There is no universal standard for exactly which requests must always require out-of-band approval, so current guidance suggests starting with the highest-impact actions and tuning by risk.

Edge cases matter. Shared mailboxes can obscure who actually requested the change. Mobile-only teams may struggle with callback verification if number validation is weak. Delegated assistants and executive support staff can create legitimate exception paths that fraudsters try to imitate. B2B partners can also complicate matters when requests arrive from a trusted domain but do not come from a trusted person. In those situations, organisations should rely on pre-enrolled approver lists, step-up authentication, and business-process rules rather than domain trust alone. The DeepSeek breach and other identity-led incidents show how quickly trust assumptions can fail once one account or channel is compromised. Mature programmes treat email as one signal among many, not as the source of truth for authorisation.

Related resources from NHI Mgmt Group

• When should organisations escalate email risk into identity and fraud controls?
• How can organisations reduce the impact of vendor fraud in email workflows?
• How should security teams reduce invoice fraud risk in email workflows?
• How should security teams reduce vendor email compromise risk in finance workflows?