Vendor Email Compromise: What VEC Is and How to Stop It

The invoice arrives on a Tuesday, in a thread you have been reading for three years. Same supplier, same account manager, same signature block with the same slightly outdated phone extension. It references the correct purchase order. It follows a conversation your team started last week about a delivery date. Partway down, in a paragraph that reads like routine administration, there's a note that the company has moved to a new banking provider and remittance should go to an updated account.

There is nothing to detect. No attachment, no link, no malware, no misspelled domain. SPF, DKIM, and DMARC all pass, because the message really did come from your supplier's mail server. Your email gateway sees an established correspondent with years of clean reputation. Your accounts payable clerk sees a familiar name in a familiar thread and updates the vendor record. The supplier's mailbox, meanwhile, was compromised eleven weeks ago, and everything since then has been reconnaissance.

This is vendor email compromise, and it occupies a strange position in most security programs. Email security is scoped to your domain. Identity controls are scoped to your accounts. Third-party risk management is scoped to your suppliers' control posture. Vendor email compromise lives in the space between all three, in the commercial relationship itself, and in most organizations that space has no owner.

Key Takeaways

• Vendor email compromise is business email compromise that borrows a supplier's identity rather than an executive's, and in its most effective form it arrives from a genuine, fully authenticated mailbox with real conversation history behind it.

• Third-party involvement appeared in 48% of breaches in Verizon's 2026 Data Breach Investigations Report, up from 30% the previous year, a 60% increase after the figure had already doubled the year before that.

• Email authentication, secure email gateways, and multi-factor authentication each fail against VEC for structural reasons rather than because they're configured badly. Every one of them is scoped to an asset or boundary the attack never crosses.

• Vendor questionnaires, SOC 2 reports, and security ratings assess a supplier's control posture at a point in time. VEC attacks the payment relationship, which sits outside what those instruments measure.

• The controls that reliably stop it are financial and procedural: out-of-band verification on every bank-detail change, dual approval, separation of duties, and correlation between mailbox events and finance-system changes.

What Vendor Email Compromise Actually Is

Vendor email compromise is a form of business email compromise in which the identity being abused belongs to a supplier, law firm, payroll provider, managed service provider, property agent, or any other external party you transact with. The fraud mechanics are familiar. What changes is whose trust the attacker spends.

Three terms get used interchangeably in this space, and keeping them separate makes the defensive picture much clearer.

Account takeover is the compromise mechanism. It describes the moment an unauthorized party gains the ability to use a mailbox or cloud identity as its owner: reading mail, searching history, sending messages, altering forwarding rules, holding a valid authenticated session.

Business email compromise is the fraud operation. It's social engineering aimed at people who move money or handle sensitive processes, and it can be built on a hijacked mailbox, a lookalike domain, display-name impersonation, a phone call, or a video meeting. The FBI recognizes compromised email, telephone numbers, and virtual meeting platforms as elements of modern BEC. The full picture of how BEC attacks are structured, including the scheme types and the psychology they exploit, is a separate discussion.

Vendor email compromise is the case defined by whose trust is borrowed. It's BEC where the trusted party is external to your organization.

VEC runs in two modes, and they demand different responses. In the first, the attacker genuinely controls the supplier's mailbox, which gives them a real sender, a real thread, real history, and authentication that passes cleanly. In the second, the attacker impersonates the supplier from outside using a lookalike domain, a homograph character, or a display name that matches while the underlying address doesn't. The second mode is more common and considerably more detectable. The first is the one that costs organizations millions.

The research burden also separates VEC from executive-impersonation BEC. Faking a CEO's urgent wire request requires knowing the CEO's name, the CFO's name, and a plausible reason for haste. Faking a supplier's invoice requires knowing the payment structure, the invoice cadence, the approval thresholds, who signs off above what amount, how this particular account manager writes, and when in the billing cycle a change would look unremarkable. That intelligence takes weeks or months to gather, which is exactly why attackers sit quietly inside a compromised vendor mailbox instead of cashing out on day one. The payoff justifies the patience.

The asymmetry is what makes this a systemic problem rather than an isolated one. One compromised supplier mailbox exposes every downstream customer at once. A mid-sized accounting firm, logistics provider, or software vendor may correspond with hundreds of organizations, each with its own payment relationship, each accustomed to receiving invoices from that address.

Why Supplier Trust Became the Growth Surface

The clearest evidence that third-party exposure has changed shape comes from Verizon's 2026 Data Breach Investigations Report. Third-party involvement appeared in 48% of breaches, up from 30% in the previous year's report. That's a 60% increase, and it follows a year in which the figure had already doubled. Few metrics in security move that fast in one direction.

The DBIR's third-party measurement combines three distinct relationship archetypes, and they're worth separating because each implies different controls:

1. A vendor in your software supply chain. Your data stayed under your control, but the initial access was made possible by a vulnerability in a vendor's product, or by that vendor shipping a backdoored build.

2. A vendor hosting your data. The initial access is against the vendor itself, and the vendor is the custodian of your data. This covers both a breach of the vendor's infrastructure and the theft of your credentials to the vendor's environment.

3. A vendor with a connection into your environment. The initial access lands on the vendor, and the attacker moves laterally into your systems through a network connection or stolen internal credentials.

Increasingly, one campaign spans several archetypes at once. The DBIR's own worked example is the 2025 activity around the Salesloft Drift integration for Salesforce: based on publicly disclosed information, OAuth tokens from the third-party application were compromised at the vendor, then used against the Salesforce platform to extract customer data. Initial access on one vendor, exfiltration from another vendor's environment, in a single operation.

Vendor email compromise fits none of those three archetypes cleanly, and that's the crux of the problem. The attacker doesn't exploit the vendor's product, doesn't access data the vendor holds for you, and doesn't move laterally into your network. There is no technical connection at all. The only thing linking the two organizations is correspondence and payment, which is precisely why VEC falls outside most third-party risk registers. It's a fourth case, mostly unnamed: the vendor you simply talk to and pay.

The finance side of the house sees the resulting fraud more clearly than the security side does. The 2026 AFP Payments Fraud and Control Survey found that 74% of organizations were affected by business email compromise during 2025, up from 63% the year before, and that 76% experienced attempted or actual payments fraud. Spoofed emails topped the list of BEC types at 85% of organizations, with more than half also reporting near-identical lookalike domains. This is a survey of treasury and finance practitioners rather than security-product customers, which makes it a useful counterweight to vendor telemetry.

The FBI's Internet Crime Complaint Center recorded roughly $3 billion in reported BEC losses during 2025, compared with about $2.77 billion in 2024. Cumulative exposed losses reported internationally between October 2013 and December 2023 exceeded $55.5 billion. The shape of the IC3 data also tells you something useful about severity: in 2024, BEC ranked second by dollar loss but only seventh by complaint volume, which describes a low-frequency crime with unusually high consequences per incident.

Two caveats belong here, because the numbers are easy to misread. The DBIR's initial-access figures shifted this year partly for methodological reasons: credential abuse fell from 22% to 13%, but the report is explicit that adding pretexting as a newly tracked vector accounts for much of the drop, and on the previous basis it would have been 16%. And the non-intentional human element reached 62% of breaches against 60% the year before, which the DBIR notes falls within its error margins. That isn't a trend.

What is a genuine finding is the arrival of pretexting as a tracked initial-access vector at 6% of breaches, with phishing steady at 16%. The DBIR draws a distinction that matters for anyone defending against VEC: phishing is asynchronous, a message that tries to alter behavior, while pretexting is synchronous, an actor on the other end of a call or thread working to convince someone in real time. The report is blunt that the countermeasures differ, and that training built around "check whether the email is external and uses proper language" doesn't transfer to a person on a call who's actively adapting.

Anatomy of a Hijacked Invoice Thread

Understanding the sequence matters because each phase offers a different intervention point, and the last one offers almost none.

Phase one: the supplier is compromised. This is ordinary account takeover, and it usually doesn't involve malware. Credential phishing remains common, but adversary-in-the-middle kits have made stolen sessions the more reliable route. An AiTM service relays traffic between the victim and the genuine authentication site, capturing both credentials and the session cookie issued after multi-factor authentication succeeds. The supplier's employee completes their MFA challenge correctly and still loses the session. Infostealer malware, malicious OAuth consent grants, device-code phishing, and help-desk manipulation that defeats strong MFA all lead to the same place.

Nothing about this phase is visible to you. It happens inside another company's tenant.

Phase two: silent reconnaissance. The attacker reads. Historical correspondence tells them which of the supplier's customers pay the largest invoices, on what cycle, through which contacts, and with what approval chain. They learn the account manager's writing habits: whether they use contractions, how they sign off, whether they attach PDFs or link to a portal. They search for terms like "invoice," "remittance," "wire," and "PO." They learn that invoices above a certain value at your organization need a second approver, and that this particular supplier's smaller monthly invoices don't.

This phase can run for weeks or months. Mandiant's M-Trends 2026 puts global median dwell time at 14 days across all intrusion types, but financially motivated mailbox access aimed at invoice fraud has every incentive to wait for the right billing cycle rather than move fast.

Phase three: persistence and concealment. To keep the real supplier from noticing, attackers modify the environment. Inbox rules move or delete replies containing keywords like "fraud," "verify," or "bank." External forwarding addresses copy relevant threads out. Sent items are deleted after the fraudulent messages go out. In some operations the attacker creates a lookalike domain at this stage and quietly transitions the conversation onto it, so that when the supplier eventually regains control of the mailbox, the thread continues without them.

The practical consequence is severe. When your AP team replies to the changed-remittance email asking for confirmation, the reply may never reach a legitimate human at the supplier. The attacker answers it.

Phase four: timing and the ask. The attacker waits for a genuine invoice cycle, then replies in-thread. The framing is almost always administrative rather than urgent: a banking provider change, a treasury consolidation, a new entity structure after an acquisition. Urgency is the tell that experienced fraudsters avoid in VEC, because the whole advantage of the vendor channel is that it doesn't need to feel exceptional. It needs to feel like Tuesday.

In multichannel operations, the email is followed by a confirming phone call. If your process says "call the supplier to verify," the attacker's goal is to be the person who answers, or to call you first. M-Trends 2026 reports that voice phishing rose to 11% of initial infection vectors, making it the second most common. A cloned voice on a confirmation call has become cheap enough to be worth the attacker's effort, though the more mundane version, a caller who simply has all the correct context, works well enough on its own.

Phase five: laundering and the closing window. Funds move through intermediary accounts quickly. Recovery odds fall steeply once the money is dispersed, which is why the FBI's guidance emphasizes contacting both the originating and receiving financial institutions immediately and filing an IC3 report rather than waiting to complete an internal investigation.

The scale this reaches is not theoretical. In the case prosecuted by the US Attorney's Office for the Southern District of New York, Evaldas Rimasauskas registered a company mimicking Quanta Computer, a genuine Taiwanese hardware supplier to both Facebook and Google, then sent forged invoices, contracts, and letters that appeared to bear corporate seals and executive signatures. The two companies paid out more than $100 million between them. Rimasauskas pleaded guilty and was sentenced to five years in prison in 2019. Toyota Boshoku's European subsidiary disclosed a loss of roughly ¥4 billion, about $37 million, to a fraudulent payment-instruction change in 2019. Ubiquiti Networks disclosed in an SEC filing that it lost $46.7 million to impersonation of an outside entity targeting its finance department, with about $8.1 million recovered at the time of disclosure.

What these cases have in common isn't a shortage of security budget. It's that the attack never went near the part of the business that budget was protecting.

Why Your Existing Controls Miss It

The uncomfortable part of vendor email compromise is that the controls which fail aren't failing because they're misconfigured. They're working as designed, on a problem shaped differently from this one.

Email authentication does what it says, and no more

SPF, DKIM, and DMARC establish that a message claiming to come from a domain was authorized by whoever controls that domain. Deployed with enforcement, they substantially reduce unauthorized use of your own domain. That's real value and worth having.

They offer nothing against a genuinely compromised supplier mailbox. The message is authentically from that domain, sent through that domain's authorized infrastructure, signed with that domain's keys. Every check passes because every check should pass. There is no authentication failure to detect, because no authentication failure occurred.

The scope limitation runs further. DMARC policy is set by the domain owner, so you have no jurisdiction over your supplier's posture, and many small suppliers, the ones most likely to be compromised and least likely to notice, run no enforcement at all. Even in the impersonation mode of VEC, DMARC is silent: a lookalike domain is one the attacker legitimately controls and can authenticate perfectly. Display-name impersonation slips through the same way.

DMARC is frequently presented as a BEC countermeasure when it's really a domain-abuse countermeasure, and the distinction matters when you're deciding what else you need.

Secure email gateways are looking for the wrong things

Gateways and filters are built around payloads, infrastructure reputation, and known-bad indicators. They inspect attachments, detonate files, evaluate URLs, score sender reputation, and check against threat intelligence.

A VEC message contains no attachment worth detonating, or a legitimate PDF invoice. It contains no URL, or a URL to the supplier's real portal. It originates from mail infrastructure with years of clean sending history to your organization. It sits inside a thread with genuine prior messages, written in a style that matches the previous forty exchanges because the attacker read all forty.

Behavioral and relationship-based email security tools exist specifically to close this gap, and they work by modelling normal communication patterns rather than scanning for badness. That's a genuinely different detection approach and worth evaluating. A traditional gateway, though, is being asked here to find a payload in a message that doesn't have one, which is a scoping problem rather than a performance one.

Your identity posture protects the wrong accounts

Phishing-resistant multi-factor authentication is one of the highest-value investments a security program can make. FIDO2 security keys and properly implemented passkeys bind authentication to the legitimate service's domain and resist the AiTM attacks that defeat push-based MFA. CISA and NIST both push organizations in this direction, and they're right to.

None of it touches vendor email compromise, because the compromised account isn't yours. Your conditional access policies, session lifetimes, OAuth consent restrictions, and help-desk verification procedures all govern your tenant. The attack path runs entirely through a mailbox in someone else's. You can require suppliers to adopt phishing-resistant authentication contractually, and for critical vendors that's a reasonable ask, but you can't verify it continuously or extend your identity controls across a boundary you have no administrative access to.

Questionnaires and ratings measure control posture, not the relationship

Third-party risk management does useful work. Security questionnaires, SOC 2 Type II reports, ISO 27001 certificates, penetration test summaries, and continuous security ratings give you a defensible view of whether a supplier runs a competent security program. For assessing whether to trust a vendor with your data, or to connect them to your network, these instruments are appropriate.

They tell you almost nothing about vendor email compromise. A supplier can hold a current SOC 2 Type II, score well on every rating platform, and have an account manager whose mailbox was compromised this morning. The report describes controls over a past observation window; the rating describes externally observable posture, mostly certificate hygiene, exposed services, and breach mentions. Neither describes the state of the specific mailbox that will email you an invoice next week.

There's also a coverage problem. Most TPRM programs tier suppliers by data sensitivity and system access, so a logistics provider or print shop that holds none of your data and touches none of your systems lands in the lowest tier, gets a light-touch assessment or none at all, and receives payments of six or seven figures. From a VEC perspective the tiering is inverted: risk follows payment volume and correspondence frequency, not data custody.

Step back and the pattern across all four is the same. Each control is scoped to an asset, a domain, a tenant, or a supplier's internal posture. Vendor email compromise attacks the relationship between two organizations, and a relationship isn't an asset anyone has been assigned to defend.

Third-Party Trust Management as a Lifecycle

If the gap is the relationship, the program has to cover the relationship end to end. That means treating third-party trust as a lifecycle with controls at each stage, and it means accepting that most of the effective controls belong to finance and procurement rather than security. Security's job here is largely to specify, instrument, and monitor controls that other functions execute.

Onboarding and vendor master data

The vendor record deserves to be treated as a security asset, because it determines where your money goes.

Verify banking details at onboarding through a channel that isn't the vendor's email. Confirm the account through the bank directly or a bank-account validation service, and check that the account name matches the legal entity you're contracting with. Mismatches between trading name, legal entity, and account holder are common in legitimate business, which is exactly what a fraudster relies on to explain an anomaly away.

Capture an independently sourced verification phone number during onboarding, store it in the vendor master record, and mark it as the number for payment verification. This single step defeats a large share of VEC attempts, and the reason is timing. Source a callback number at the moment you need it and you'll source it from the request, the signature block, or a search result the attacker may control. Source it before there's any incident and you're sourcing it from a period when nobody had a reason to manipulate it.

Restrict who can modify vendor master data, log every change with the identity of the person making it, and review that log. In many organizations the vendor master is editable by more people than the payment approval workflow is, which inverts the control.

Payment and change controls

This is where the fraud is actually stopped, and the controls are unglamorous.

No bank-detail change is accepted on the basis of email alone. State it as policy, communicate it to suppliers at onboarding so the eventual callback isn't a surprise, and remove the discretion to make exceptions under time pressure.

Verify out of band, using the number on file. Never a number contained in the request, in the signature block, or on a website reached through a link in the message. The attacker controls all of those. This is the control that most reliably breaks the attack, because it requires the fraudster to control a communication channel they generally don't.

Require both old and new account details on change forms. A fraudster with mailbox access usually knows the new account they want you to pay and may not know the old one you currently hold. It's a small piece of friction that's trivial for a legitimate supplier and awkward for an attacker.

Separate duties across the change. The person who enters a vendor banking change should not be the person who verifies it, and neither should be the person who releases the payment. Where headcount makes full separation impossible, at minimum separate verification from entry.

Apply dual approval to vendor master-data changes, not only to payments. Many organizations have strong dual authorization on outbound transfers and none at all on the record that determines where transfers go.

Impose a cooling-off period. A newly changed bank account shouldn't be payable for a defined window, and the first payment to a changed account should trigger review regardless of amount. This converts a race condition into something a human can catch.

Scale controls to amount, but not only to amount. Attackers who've read your correspondence know your thresholds and will structure requests beneath them. First-payment-to-a-new-account and any-change-to-existing-details deserve verification irrespective of value.

Correspondence and relationship monitoring

Some signals are visible in inbound vendor mail, and finance staff can be taught to notice them even though none is conclusive on its own:

• A change of remittance details arriving in a thread, particularly one that reads as administrative housekeeping rather than a formal notification.

• Reply-chain hijack indicators: quoted history that doesn't quite match your records, a thread that suddenly gains or loses participants, or a reply from a slightly different address than the one in the quoted history.

• A known contact writing from an unfamiliar geography, at unusual hours for their timezone, or with a changed signature block.

• Invoice anomalies: numbering out of sequence, an amount that breaks an established pattern, round-number totals without line-item detail, or an invoice arriving off-cycle.

• Resistance to the callback. A legitimate supplier finds verification mildly tedious. A fraudster finds it fatal and will push back, offer an alternative number, or express urgency.

Cross-system correlation

The highest-value detection signal in vendor email compromise isn't visible in any single system, which is why so few organizations catch it.

Consider two events. In your mail environment, a rule appears on an internal mailbox that files messages from a particular supplier into an obscure folder, or an inbound message from that supplier shows anomalous routing. In your ERP, the banking details for that same supplier change within a short window. Individually each is low-severity noise: a forwarding rule is usually someone organizing their inbox, and a banking change is usually a supplier switching banks. Together, scoped to the same vendor within the same few days, they describe an attack in progress. Abnormal AI has made this correlation argument publicly, and it holds regardless of which vendor makes it.

The practical requirement is unglamorous plumbing. Mailbox audit telemetry and finance-system change logs need to reach a common place, with the vendor as the join key. In most organizations these live in different tools owned by different teams with different retention policies, and nobody has ever been asked to join them. Doing so doesn't require a new product. It requires deciding that the vendor identifier is a security-relevant field and getting both log sources into the same query surface.

Set the detection rules narrowly to start: banking change plus any mailbox anomaly for the same vendor, first payment to a changed account, and payment to an account whose country differs from the vendor's registered jurisdiction.

Offboarding and standing access

When a supplier relationship ends, the security work usually stops at revoking system access, if it happens at all. Two gaps persist.

Integrations and OAuth grants outlive contracts routinely. An application authorized years ago to read mail or access files may retain a refresh token long after anyone remembers approving it. Reviewing and revoking these should be part of offboarding, not an annual clean-up project.

Dormant vendor records are a favored re-entry point. A supplier you stopped using two years ago still sits in the vendor master with valid banking details and no active correspondence to make an anomaly obvious. Deactivate records when relationships end, and require full re-verification to reactivate one.

Assign every control to a named function

The recurring failure mode in vendor email compromise is rarely a missing control. It's a control that everyone assumes someone else owns.

Write down who owns each piece: security owns mailbox telemetry, correlation rules, and the awareness program; accounts payable owns callback execution and change-form completeness; procurement owns onboarding verification and the vendor master record; treasury owns payment thresholds, cooling-off periods, and release authority. Then test the seams, because that's where this attack lives. A tabletop exercise that walks a changed remittance request through your actual people and actual systems will surface the ambiguity faster than any document review.

What NIS2, DORA, and NIST CSF 2.0 Now Require

Regulatory expectations have moved toward continuous third-party oversight, which is a problem for programs built on annual questionnaires.

NIS2 requires in-scope essential and important entities to take an all-hazards approach to risk management, with Article 21 explicitly naming supply-chain security among the required measures, including the security of relationships with direct suppliers and service providers. The directive also imposes incident-reporting obligations on defined timelines. The point worth internalizing is that reporting duties can attach to you when the compromise occurred at a supplier, if the resulting incident affects the services you deliver.

DORA applies to EU financial entities and has been in force since 17 January 2025. Among its more concrete demands is the register of information on contractual arrangements for ICT services provided by third parties, which must be maintained and made available to supervisors. DORA also sets expectations around contractual terms, exit strategies, and oversight of critical ICT third-party providers. It's the clearest existing example of a regulator treating third-party trust as a continuously maintained inventory rather than a periodic assessment.

NIST Cybersecurity Framework 2.0 added Govern as a function and placed Cybersecurity Supply Chain Risk Management within it as the GV.SC category. That placement is the interesting part. Moving supply-chain risk under Govern reframes it from a technical control set to a governance obligation with defined roles, strategy, and oversight. NIST SP 800-161r1 carries the operational depth for organizations that want the full program model.

SEC disclosure rules require US public companies to report material cybersecurity incidents on Form 8-K, generally within four business days of determining materiality. A supplier-originated incident can be material to you, and a fraudulent payment large enough to matter may also expose weaknesses in internal control over financial reporting, which carries its own reporting consequences.

The common thread across all four is an assumption of ongoing visibility into third-party exposure. A questionnaire completed at onboarding and refreshed annually does not produce that, and increasingly the frameworks say so directly.

Who Pays When the Supplier Was the One Compromised

Once a fraudulent payment lands, a commercial dispute begins that most organizations have never thought through in advance.

Four parties have a position. The supplier whose mailbox was compromised argues they never sent the instruction and are still owed for the goods. The customer who paid argues they followed the instruction that arrived through the supplier's own authenticated channel. Both banks argue the transaction was properly authorized on their side. The insurers argue about which policy wording applies.

Outcomes turn on contract language, how quickly each party notified the other, which control failures can be demonstrated, and jurisdiction. There is no universal allocation of responsibility, and anyone who states one confidently is describing a single case rather than a rule.

Three things are worth doing before you need them. Check whether your supplier contracts specify a payment-change verification procedure and state who bears the loss when it isn't followed, because a contract that's silent leaves the question to litigation. Check how your insurance policy classifies this loss, since computer fraud, funds-transfer fraud, and social-engineering fraud often carry different coverage and markedly different sub-limits, and social-engineering coverage is frequently the smallest. Expect the insurer to ask whether your documented callback procedure was actually followed, which turns your process discipline into a coverage question.

If a payment has already gone out, the sequence is time-critical: contact your bank and the receiving bank immediately to request a recall, file a report with IC3, notify the supplier through a channel you've independently verified rather than by replying to the thread, and preserve mail headers and audit logs before anyone starts cleaning up.

What Training Can and Cannot Do Here

Security awareness training occupies genuinely contested ground, and the honest version of this section is more useful than the promotional one.

The skeptical case is substantive. A Cybersecurity Dive review of more than a dozen peer-reviewed studies and meta-analyses published since 2008 concluded that commonly deployed forms of training offer small or minimal protective benefit, with some evidence that certain approaches increase susceptibility by producing false confidence. A 2025 operational study of more than 12,000 users found no statistically significant effect from the anti-phishing training tested on either click rates or reporting rates. Vendor surveys reach warmer conclusions, but they generally measure perception rather than incident reduction, and they're produced by parties with a commercial interest in the answer.

The defensible position is that training is a supporting control whose value is narrower and more specific than the category's marketing suggests.

Start with what it can't do. No amount of training will let an accounts payable clerk reliably distinguish a genuine supplier mailbox from a compromised one, because there's nothing to distinguish: the sender, the thread, and the history are all authentic. Asking humans to detect the undetectable is the design error at the heart of a lot of awareness content, and it produces both false confidence and misplaced blame.

What training genuinely improves is narrower and still worth having:

Reporting speed and willingness. The gap between an employee noticing something odd and telling someone is where most of the recoverable time lives. Training that makes reporting fast, obvious, and blame-free improves that gap measurably, and it's one of the few awareness outcomes with a clean causal path to reduced loss. It also argues for measuring reporting rate and time-to-report rather than click rate, since click rate says nothing about how quickly your AP team raises a hand.

Procedural adherence under pressure. The callback control only works if people execute it when a supplier is annoyed, a deadline is close, and a manager is asking why the payment hasn't gone out. That's a behavioral outcome, not a knowledge one, and it responds to rehearsal rather than to content.

Resistance to synchronous pretexting. The 2026 DBIR is explicit that pretexting requires different countermeasures from phishing, because a live human adapts to whatever the target says. Its recommendation is business-oriented rules aligned to each target function, not generic message-inspection advice. A rule like "any bank change gets a callback to the number on file, no exceptions, and I'm authorized to say no" survives an adaptive caller in a way that "check for spelling errors" never will.

That points to how rehearsal should be scoped. Target the roles that actually approve and release payments: accounts payable, procurement, treasury, and finance leadership. Rehearse the specific scenario, which is a remittance change arriving inside a known thread rather than a generic credential-harvesting lure. And rehearse the confirming phone call, not just the email, because the call is where the callback control is attacked directly.

On that last point, the 2026 DBIR reported that median click success in simulated voice- and text-centric campaigns ran 40% higher than in email simulations. That comes from a small sample of 35 campaigns and describes simulation performance rather than real-world attack success, so it shouldn't be over-read. It does suggest that programs which only ever simulate email are rehearsing the easier channel.

5 Best Cybersecurity Awareness Platforms for Social Engineering Detection

A scoping note before the list. None of these platforms detect vendor email compromise on the wire. They build the human detection and reporting layer that sits on top of the payment controls described above. Detection tooling is an adjacent category, covering behavioral email security products such as Abnormal, Darktrace, Mimecast, Microsoft Defender for Office 365, and Proofpoint's email security line, and it solves a different part of the problem. Buying awareness training instead of payment controls is the most common way organizations get this wrong.

Judged for this problem specifically, the question to ask a platform is narrow: can it rehearse a vendor-thread scenario against the finance roles that approve payments, can it rehearse the confirming phone call, and does it measurably improve reporting behavior?

The five below are listed alphabetically.

Brightside AI

Brightside is a Swiss awareness platform built around simulation realism rather than content volume, and its template organization maps unusually well onto this topic. The phishing library is categorized by attack type, including dedicated vendor impersonation and business email compromise categories, by department fit including Finance & Accounting and Legal & Compliance, and by vendor type, which distinguishes your own vendors from widely trusted brands. That lets you aim a supplier-thread scenario at the specific roles that approve remittance changes rather than at the whole company.

Its hybrid attack mode combines a live AI voice call with a trackable phishing email in one coordinated campaign, which is the closest available rehearsal for the pattern described earlier: an invoice arrives, then someone calls to confirm the new account details. The vishing simulator supports configurable caller personas, tactics such as pretexting and authority impersonation, adjustable urgency and tone, and custom voice cloning from a short recording. Simulations are scored against the NIST Phish Scale, and the platform reports an NIST-weighted failure rate rather than a raw click rate. A Report Phishing add-on for Gmail and Google Workspace closes the loop to real reporting, with routing that distinguishes genuine threats from training simulations and least-privilege access limited to the single message an employee reports.

Pros

• Vendor impersonation and BEC template categories, filterable by department and vendor type

• Hybrid voice-plus-email campaigns rehearse the confirming call, not just the message

• Custom voice cloning and configurable social engineering tactics for realistic pretexting rehearsal

• NIST Phish Scale alignment and NIST-weighted failure-rate reporting

• One-click Report Phishing add-on with simulation-aware routing

Cons

• Not a broad human risk suite; narrower content library than the large platforms

• No detection, filtering, or real-time monitoring capability, by design

• Report Phishing add-on currently covers Gmail and Google Workspace

Hoxhunt

Hoxhunt builds adaptive phishing programs fed by threat intelligence, with difficulty that adjusts per user based on prior performance, and it puts unusual emphasis on reporting as the primary measured behavior rather than click avoidance. That aligns well with the argument above about where training value actually sits. Its remediation workflows connect user reports into security operations, so a reported message becomes a triage item rather than a training statistic. The gamified model produces high participation rates, which matters for finance teams that treat security training as an interruption. Voice-specific rehearsal is less developed than at the simulation specialists.

Pros

• Reporting behavior treated as the primary metric

• Adaptive per-user difficulty informed by real threat intelligence

• Strong SOC integration turning user reports into actionable triage

• High engagement rates in practice

Cons

• Enterprise-weighted pricing and rollout effort

• Less depth in voice and multichannel rehearsal

• Adaptive model needs time and volume before it tunes well

KnowBe4

KnowBe4 is the largest platform in the category by content volume and market presence, with an extensive template library, mature campaign automation, broad language coverage, and compliance training that many organizations need anyway. For a buyer who wants one vendor covering awareness, compliance, and phishing simulation across a large distributed workforce, the breadth is the argument.

For the specific problem in this article, breadth cuts both ways. The template library includes vendor and invoice-themed lures, but the platform's design centre is high-volume, broadly targeted simulation rather than bespoke scenarios built around your actual supplier relationships and approval chains.

Pros

• Largest content and template library in the category

• Mature automation and campaign management at scale

• Very broad language and compliance coverage

• Wide range of integrations

Cons

• Volume-oriented rather than scenario-oriented design

• Less suited to bespoke vendor-thread rehearsal for small finance teams

• Administrative surface is heavy for smaller security teams

Proofpoint

Proofpoint's awareness product is strongest where it's coupled with the company's email security estate, because training targeting can then be driven by who's actually being attacked rather than by role assumptions. Its "very attacked people" concept identifies individuals receiving genuine targeted pressure and enrols them into adaptive learning paths, which is a materially better targeting signal than a static org chart, and its suspicious-message reporting and triage tooling is mature. For a VEC program that threat-informed targeting is genuinely useful: if your AP team is receiving elevated supplier-themed pressure, the platform can act on it rather than waiting for an annual training cycle.

Pros

• Training targeted by real threat telemetry rather than role assumptions

• Identification of the individuals under actual targeted pressure

• Mature reporting and abuse-mailbox triage workflows

• Deep integration with a wider security stack

Cons

• Strongest only when you already run Proofpoint email security

• Heavier to deploy and justify as a standalone awareness purchase

• Content is broad rather than tailored to specific supplier scenarios

SoSafe

SoSafe builds its programs on behavioral science, with an emphasis on measuring behavior change rather than completion rates, and it has strong European footing. For organizations working through NIS2 obligations, its compliance-oriented reporting and GDPR-conscious data handling reduce friction with works councils and data protection officers, a consideration that rarely appears in feature comparisons but frequently determines rollout timelines in Europe. Manager-level workflows push accountability into departments, which fits the ownership problem described earlier. Multichannel simulation depth is more limited than at the simulation specialists.

Pros

• Behavior-change measurement rather than completion tracking

• Strong European compliance and data-protection posture

• Manager workflows that distribute accountability into departments

• Useful reporting for NIS2-driven documentation needs

Cons

• Less multichannel and voice simulation depth

• Behavioral programs take longer to demonstrate results

• Content localization strongest in European languages

If you need a fuller evaluation across the category rather than five options judged against one threat, a broader breakdown of security awareness training platforms covers the buying criteria in more depth.