What is the difference between BEC and VEC for governance teams?

Why This Matters for Security Teams

Governance teams often classify business email compromise and vendor email compromise as adjacent fraud patterns, but the control problem is different. BEC targets trust inside the enterprise, while VEC targets the trust edge where suppliers, service providers, and outsourced workflows interact with internal approvals. That distinction matters because vendor relationships often sit outside the strongest IAM, PAM, and monitoring paths, even though they can still trigger payment changes, data access, or token reuse. The control gap is documented in the NHIMG research on Top 10 NHI Issues, which shows how weak lifecycle discipline and poor visibility create practical exposure across trusted identities.

For governance teams, the point is not just email security. It is identity assurance, approval integrity, and vendor-risk classification across the full trust chain. A vendor message can look operationally routine while still being the first step in fraud, lateral access, or secret harvesting, which is why guidance from NIST Cybersecurity Framework 2.0 remains relevant at the governance layer. In practice, many security teams encounter VEC only after an invoice, token, or bank-detail change has already been approved through a normal business process rather than through intentional fraud review.

How It Works in Practice

Distinguishing BEC from VEC starts with who is being impersonated and which trust path is abused. BEC typically relies on an internal identity such as a CEO, finance lead, or payroll contact. VEC uses a trusted external identity such as a supplier, MSP, SaaS provider, or logistics partner. The operational risk is that both can exploit the same human workflow, but VEC is harder to see because business teams often grant vendors implicit trust after onboarding.

In practice, governance teams should treat VEC as an identity-and-process issue, not just an email-filtering issue. Current best practice is to verify:

• who is authorised to request changes on behalf of the vendor,
• whether the request path matches the approved contract and known contacts,
• whether payment, routing, or access changes require out-of-band confirmation,
• whether the vendor has standing credentials, tokens, or delegated access that outlive the task.

The NHIMG Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because many VEC incidents are enabled by weak lifecycle controls around third-party credentials, shared mailboxes, API tokens, or delegated workflows. That is where identity governance meets fraud prevention. Organisations that have poor visibility into vendor-connected accounts should also align with the evidence in The State of Non-Human Identity Security, which highlights major blind spots around third-party access and credential rotation.

Where this guidance breaks down is in highly decentralised procurement and finance environments, because informal approval chains and exception-based vendor handling make it difficult to enforce one consistent verification standard.

Common Variations and Edge Cases

Tighter vendor verification often increases friction for finance, procurement, and operations, so organisations have to balance fraud resistance against business speed. That tradeoff becomes sharper when external parties are long-standing partners, because staff may assume recognition equals legitimacy.

One common edge case is when BEC and VEC overlap. An attacker may first compromise an internal mailbox and then use it to impersonate a vendor, or compromise a vendor account and then pivot into internal approvals. In these cases, the distinction matters less than the control response: verify the requester, verify the change, and verify the destination independently. Another nuance is that some vendor interactions are now machine-driven through integrations, not human email threads. Best practice is evolving here, and there is no universal standard for this yet, but governance teams should treat API keys, service accounts, and delegated app permissions as part of the same trust boundary.

The NHIMG Ultimate Guide to NHIs — Regulatory and Audit Perspectives helps frame why auditors increasingly expect evidence of vendor identity controls, not just fraud training. For broader identity context, Ultimate Guide to NHIs — What are Non-Human Identities is useful when vendor access is mediated by credentials, tokens, or automated workflows rather than by named individuals. These controls tend to break down when vendor exceptions are approved informally because the exception path becomes the real policy.

Related resources from NHI Mgmt Group

• What is the difference between attack surface management and NHI governance?
• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between human IAM controls and NHI governance?
• How should teams choose between SaaS-first and ERP-first identity governance models?