Relying on employees alone creates predictable exposure because attackers only need one convincing message to get through. In this report, text-based BEC emails had a meaningful open rate and a share of recipients replied, which shows that human judgment is an unreliable final barrier. Once a reply begins, attackers can steer the conversation toward payment or account changes.
Why employee-only detection fails against BEC and vendor impersonation
BEC and vendor impersonation work because they exploit routine business trust, not just technical weakness. A convincing message can look normal enough to reach inboxes, pass a hurried read, and trigger a reply before anyone validates the request. That makes the human reviewer part of the attack path, which is why employee vigilance is useful but cannot be the only control.
The practical problem is that these campaigns aim for a fast, low-friction decision: approve a payment, redirect funds, change bank details, or reset an account workflow. If the organisation assumes every employee will spot the deception, the attacker only needs one person to be rushed, distracted, or uncertain.
When this pattern is paired with vendor spoofing or mailbox compromise, the message can carry the right context, tone, and timing to feel legitimate. That is why business process checks, payment verification, and out-of-band confirmation matter more than confidence in awareness alone.
What actually changes when the attacker gets a reply
The first reply is often the turning point. Once someone answers, the attacker can extend the conversation, introduce urgency, and steer the target toward a higher-value action than the original email asked for. This is where the incident moves from a suspicious message to an active social-engineering exchange.
At that stage, the attacker can pivot from simple impersonation to process abuse: they may request invoice redirection, push for a bank-account update, or ask the target to “confirm” credentials, approvals, or internal details. If the organisation lacks a secondary verification step, the reply creates a path to real operational loss.
This is also why detection should not stop at spam filtering. Good defence includes mailbox protection, anomaly detection for lookalike domains, verified supplier records, and payment approval controls that do not depend on email alone. MITRE ATT&CK Enterprise Matrix is useful here for mapping the follow-on abuse patterns that often accompany credential access, lateral movement, and impersonation-based intrusion.
Why the control must be process-led, not awareness-led
Employee training still matters, but it works best as a detection layer, not as the final decision point. Organisations reduce exposure when they treat BEC as a business-process integrity problem, with controls that verify who is asking, what changed, and whether the request matches an approved workflow.
For vendor impersonation specifically, the strongest practice is to verify sensitive changes through a trusted channel that is already on file, not through contact details in the message itself. That means finance, procurement, and operations teams need a clear rule for what must be rechecked before payment, bank-detail changes, supplier onboarding updates, or urgent exceptions are accepted.
For broader control design, this is a good place to reinforce email security, invoice validation, and least-privilege access around payment and vendor administration. CSA Cloud Controls Matrix provides a useful governance lens for identity, audit, and third-party control expectations, while SOC 2 Trust Services Criteria (AICPA) is often used where vendor assurance and control discipline matter to the business.
How to reduce the blast radius of BEC and vendor impersonation
The main objective is not to “train people better” and move on. It is to make any single fooled employee insufficient to complete a harmful transaction. That usually means adding step-up verification, segregating duties, and making payment or account-change approvals visible enough that anomalies are caught before execution.
Practical teams also watch for telltale conditions: a new vendor bank account, a first-time payment request, a change in reply-to behaviour, a rush to bypass process, or a message that asks for secrecy. Those are operational cues that should trigger verification rather than faster action.
For organisations that want stronger identity and access discipline around the systems used in these workflows, NIST Cybersecurity Framework 2.0 is a useful organising model for govern, protect, detect, respond, and recover, and NIST SP 800-53 Rev 5 Security and Privacy Controls helps map that discipline to access control, audit, and system integrity controls.
Risk and Threat Considerations
Reliance on employees alone creates a predictable single-point failure. BEC and vendor impersonation succeed when a trusted workflow can be nudged off its normal path, especially where urgency, routine payment handling, or supplier change requests reduce scrutiny.
Failure mechanism: The attacker exploits human trust plus weak process verification, then uses the first reply or approval to advance the conversation into a payment, account-change, or credential-abuse path.
Impact: The organisation can suffer fraudulent payments, diverted funds, vendor-account compromise, or secondary intrusion if the exchange exposes credentials or internal process details.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1656 — Impersonation | BEC and vendor spoofing depend on impersonation of trusted parties. |
| Recommendation — Map impersonation patterns to adversary tradecraft and monitor for spoofed sender and reply-chain abuse. | ||
| CIS Controls v8 | 5 — Account Management | Vendor impersonation often targets account changes and approval workflows. |
| Recommendation — Restrict and review account-change paths that can redirect payments or supplier access. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | Sensitive business changes need controlled approval and access checks, not email trust alone. |
| DE.CM-09 — Network Monitoring | Lookalike and anomalous message activity benefits from monitoring and detection. | |
| Recommendation — Require stronger access and approval controls for payment and vendor-change actions. Monitor for suspicious email patterns and unusual communication flows tied to payment requests. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Fraudulent workflow changes are easier to catch when approvals and account changes are reviewed. |
| Recommendation — Review transaction and vendor-change logs for abnormal approval patterns. | ||
Practitioner Guidance
What to prioritise: Put an independent verification step around any request that changes money movement, bank details, recipient identity, or payment urgency. If a control only asks the employee to “be careful,” it is not a sufficient barrier for this threat.
What to verify: The request should be checked against a trusted supplier record or a previously established callback method, not the email thread that delivered the request. If the message is consistent but the channel is not, treat that as a process failure until proven otherwise.
Common mistake: Teams often measure training completion instead of whether employees can safely stop a bad transaction. The better test is whether one mistaken reply can still cause material loss.
Practitioner takeaway: BEC defence is strongest when human judgment is backed by process controls that make a single convincing email insufficient to move money or change accounts.
Related resources from NHI Mgmt Group
- What happens when organisations rely on questionnaires without validating vendor security continuously?
- What happens when organisations rely on employees alone to stop phishing attacks?
- What happens when healthcare organisations rely on vendor disclosure instead of their own continuous monitoring?
- What happens when organisations rely on traditional security controls alone against deepfakes, sponge attacks, and AI-assisted impersonation?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
