Subscribe to the Non-Human & AI Identity Journal
Home FAQ Threats, Abuse & Incident Response What do organisations get wrong about BEC training…
Threats, Abuse & Incident Response

What do organisations get wrong about BEC training programs?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated June 27, 2026 Domain: Threats, Abuse & Incident Response

They treat training as the primary detection layer instead of a backup control. Training helps people slow down and report suspicious requests, but AI-generated BEC can be personalised enough to defeat visual scrutiny. Organisations need workflow verification and behaviour-based detection to reduce dependence on human judgement.

Why This Matters for Security Teams

Business email compromise succeeds when training is treated as the main control instead of one layer in a broader verification process. Attackers do not need to defeat every employee; they only need one convincing message at the right moment, especially when payroll, invoice approval, vendor banking changes, or executive escalation are already routine. AI-generated phishing and impersonation now make that easier by improving language quality, personalization, and timing. Guidance from the NIST Cybersecurity Framework 2.0 makes clear that awareness is necessary, but it does not replace process controls, logging, and response paths. NHIMG research points to the same gap in a different form: the DeepSeek breach demonstrates how exposed information can scale quickly once attackers gain access to the right account or system, and the lesson translates directly to BEC. The issue is not whether staff can spot obvious fraud. It is whether the organisation has built a workflow that still holds when the message looks credible enough to pass casual scrutiny. In practice, many security teams discover that training only reduced low-effort scams, while the real loss came from a single well-timed payment or vendor-change request that followed the approved process exactly until it was too late.

How It Works in Practice

Effective BEC defence works best when training is framed as a reporting and hesitation aid, not as a decision engine. Employees should be taught to pause on out-of-band payment changes, request changes to bank details, urgent wire instructions, gift card demands, and executive tone-shift messages. But the operational control is the verification workflow that follows, not the employee’s subjective judgment. A practical BEC program usually combines:
  • Dual-channel confirmation for payment or banking changes, using known contact details rather than the message thread.
  • Pre-approved callbacks for finance, procurement, and payroll actions.
  • Behaviour-based detection for unusual sender patterns, reply-chain anomalies, and sudden domain lookalikes.
  • Least-privilege mail and finance workflows so one compromised inbox cannot authorize a payment end to end.
  • Rapid reporting paths that let employees escalate suspicious requests without penalty.
The State of Secrets in AppSec shows how organisations often overestimate their own control maturity, which is a useful warning for BEC too: confidence in awareness programs is not the same as evidence of resilience. The right question is whether the request can be independently verified when the attacker has already convinced the recipient. External guidance from NIST Cybersecurity Framework 2.0 supports layered controls across identify, protect, detect, respond, and recover, which is exactly what BEC programs need. These controls tend to break down when finance approvals are informal, executive exceptions are common, or payment workflows are embedded in chat and email without a separate verification path.

Common Variations and Edge Cases

Tighter verification often adds friction to urgent business processes, so organisations have to balance speed against the risk of fraudulent approval. That tradeoff is real, especially in small teams where the same people handle intake, approval, and release. The biggest edge case is executive impersonation. Training often fails here because staff know the process but feel pressure to comply when the request appears to come from a senior leader. Best practice is evolving, but current guidance suggests that high-risk requests should trigger process-based verification regardless of hierarchy. Another common failure is overreliance on simulated phishing scores. A high completion rate does not mean the organisation can resist a well-crafted BEC attempt. Industry guidance also differs on how much weight to place on user reporting versus automated mail controls. There is no universal standard for this yet, but the direction is clear: training should feed detection, not substitute for it. The most resilient programs pair awareness with payment approval controls, mailbox hardening, and alerts for anomalous behaviour. That combination is especially important when attackers use long-lived trust relationships, vendor impersonation, or a compromised internal account that makes the request look routine. The lesson from NHIMG research is consistent across threat types: once attackers can operate inside trusted communication channels, human judgment alone becomes an unreliable final control.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.ATTraining is a supporting control, not the primary BEC detection layer.
NIST CSF 2.0DE.CMBehaviour-based detection is essential when phishing bypasses human review.
NIST CSF 2.0PR.ACAccess and approval limits reduce the blast radius of compromised inboxes.

Monitor for anomalous mail and payment activity, then alert on suspicious request patterns.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on June 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org