They should treat email, identity, and fraud as one operating chain for high-risk actions. Filtering reduces volume, but it does not stop a convincing request from being acted on. The stronger model is to combine suspicious-message detection, approval governance, and response playbooks so the organisation can challenge the action even when the email itself is not obviously malicious.
When email filtering stops and fraud control starts
Email filtering is still useful, but it only addresses one part of the abuse path: message delivery. For high-risk requests, the real control question is whether the request can be trusted, not just whether the message looked suspicious. That is why teams should treat filtering as an upstream signal and pair it with identity checks, approval rules, and fraud-aware verification for the action itself.
In practice, this means separating low-risk communication hygiene from high-risk action governance. A payroll change, payment instruction, vendor-bank update, or credential reset should not be approved because the message survived the spam filter. It should be approved because the requester, the channel, the context, and the business event all align with known-good behaviour.
How the operating chain should be designed
The strongest model is to build a chain of controls that follows the request beyond the inbox. Email filtering can reduce commodity phishing, but identity controls challenge who is asking, and fraud controls challenge whether the request is unusual, coerced, or inconsistent with normal business patterns. In other words, the control surface moves from message content to requester assurance and transaction integrity.
That chain usually needs three layers. First, suspicious-message detection and mailbox protection reduce obvious malicious delivery. Second, identity and approval governance confirm that the person or system making the request is entitled to initiate it. Third, fraud controls look for anomaly patterns, such as urgent payment language, account-change requests, unusual beneficiary details, or a request arriving through an unexpected channel.
The design goal is not to eliminate all false positives. It is to make sure the organisation can pause, verify, and escalate when an email creates a high-impact instruction. For a useful identity baseline, teams can anchor their process to the Workforce Identity Security Guide, which covers the authentication and recovery steps that matter when a request must be challenged.
Why filtering alone misses convincing abuse
Filtering works best against known-bad patterns, but social engineering often succeeds without malicious technical artefacts. A well-written email can pass filters, appear to come from a trusted party, and still induce an employee to approve a transfer, disclose information, or reset access. This is why high-risk actions need controls that are independent of message reputation.
The practical weakness is that email security tools see the message, while fraud and identity controls see the transaction. When those controls are disconnected, organisations tend to overtrust the inbox. A request that looks business-like can still be fraudulent if the channel is wrong, the timing is abnormal, or the requested action breaks ordinary workflow.
That matters even more when attackers combine email compromise with downstream abuse of identity and access. The Identity Fraud Prevention Guide is a useful reference point for the kinds of account takeover and fraud-signal patterns that can sit behind a convincing request, even when the email itself does not look overtly malicious.
Risk and Threat Considerations
When teams rely on email filtering as the main defence, the residual risk shifts to business-process exploitation. Attackers do not need to beat the filter if they can persuade a person to act on a believable request, so the exposure is often approval abuse, payment diversion, credential-reset abuse, or fraudulent data release.
Failure mechanism: The message gets through a legitimate mailbox path, then the organisation treats inbox presence as a trust signal instead of verifying the request through a separate identity or fraud step. That breaks the control boundary between communication security and transaction security.
Impact: The result can be authorised-looking fraud, unauthorised access, loss of funds, account takeover, or a delayed response because the request appeared operationally plausible. For that reason, the CISA Known Exploited Vulnerabilities Catalog is a reminder that technical compromise and social compromise often meet in the same incident path, even when the initial trigger is not a vulnerability at all.
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 addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | High-risk requests need separate verification beyond message delivery. |
| NHI-05 — Overprivileged NHI | Email-driven requests often exploit excessive access on accounts and workflows. | |
| Recommendation — Require stronger verification before approving sensitive actions. Reduce standing privilege on accounts that can approve or execute sensitive actions. | ||
| CIS Controls v8 | CIS-5 — Account Management | Balancing email and identity controls depends on governing who can request and approve actions. |
| Recommendation — Enforce account and approval governance for high-risk requests. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | High-risk actions should be verified through user authentication, not mailbox trust alone. |
| AU-2 — Event Logging | Fraud-aware workflows need auditable records of requests, approvals, and overrides. | |
| Recommendation — Use strong authentication before permitting sensitive business actions. Log request, approval, and exception events for investigation and review. | ||
Practitioner Guidance
What to prioritise: Put the hardest verification on the actions that change money, access, or supplier details. If a request can create material loss without a second-channel check, it is not adequately controlled.
Decision rule: If the request is high impact, require a control that is independent of email, such as callback verification, step-up approval, or an out-of-band business confirmation. If the request is low impact, standard filtering and workflow controls may be enough.
What good looks like: Security, finance, IT, and fraud teams share the same escalation path, the same high-risk action list, and the same stop-the-line authority. That alignment is what stops a convincing message from becoming an approved transaction.
Practitioner takeaway: Treat email as a delivery channel, not a trust decision. The more costly the action, the more the organisation should verify identity and fraud indicators outside the inbox before allowing the request to proceed.
Related resources from NHI Mgmt Group
- How should security teams balance frictionless sign-in with stronger fraud controls in mobile-first identity journeys?
- How can security teams balance user experience with stronger identity controls?
- How do security teams prioritise phishing controls across email, identity, and SaaS?
- How do teams decide whether email security needs identity controls more than another gateway layer?