Vendor email compromise exposes the limits of legacy email security

At a glance

What this is: This is an analysis of vendor email compromise and the finding that trusted, authenticated vendor messages can still drive high employee engagement and repeated abuse.

Why it matters: It matters because IAM, NHI, and human identity programmes all depend on knowing which relationships can be trusted, and VEC shows that authentication alone does not prove legitimacy.

By the numbers:

• 44% of employees engage with VEC attacks overall, rising to 72% at enterprises with 50,000+ staff.
• Only 1.46% of VEC attacks are reported, and 7.3% of engagements come from repeat victims.
• Telecom, energy, and hospitality sectors exceed 70% VEC engagement rates due to complex vendor networks.
• Entry-level sales reps engage with VEC 86% of the time, making response-oriented roles a primary attack surface.

👉 Read Abnormal AI's report on vendor email compromise and trust abuse

Context

Vendor email compromise is a social engineering problem that exploits trust in external business relationships rather than malware or malicious links. The core governance gap is that mail authentication can be correct while the sender intent is still hostile, which is why human response workflows become the control surface.

For identity teams, the lesson extends beyond email. Vendor relationships often carry standing business trust, operational privileges, and implicit approval paths, so a successful impersonation can trigger payment, access, or workflow decisions without ever breaking technical authentication.

That makes VEC relevant to human IAM, NHI governance, and third-party access oversight at the same time. The issue is not only whether a message passed SPF, DKIM, and DMARC, but whether the organisation can distinguish verified transport from verified trust.

Key questions

Q: What breaks when vendor email compromise is treated as ordinary phishing?

A: Traditional phishing controls focus on malicious links, attachments, and obvious spoofing, but vendor email compromise often uses trusted accounts, real conversation patterns, and business context. If teams treat it as generic phishing, they miss the trust relationship that makes the request believable. The result is weaker approval discipline around invoices, payment changes, and sensitive vendor communications.

Q: Why do vendor relationships increase the risk of payment fraud and data exposure?

A: Vendor relationships create standing trust across finance, operations, and procurement, so employees are conditioned to respond quickly. That trust can be exploited to change bank details, redirect payments, or extract data without tripping technical email controls. The risk rises when business urgency is allowed to override identity verification and out-of-band confirmation.

Q: How can security teams measure whether VEC controls are actually working?

A: Look for fewer successful interactions with suspicious vendor requests, lower repeat engagement by the same users, and faster escalation from employees who are unsure about a message. If people still act on questionable invoices or payment updates, the control design is failing at the trust layer even when mail authentication is passing.

Q: Who should own vendor trust governance when email, finance, and IAM intersect?

A: Accountability should sit across security, finance, procurement, and IAM, with clear ownership for vendor verification, payment changes, and escalation handling. If each team assumes another owns the decision, VEC attackers exploit the gap. The governing principle is simple: the workflow owner must validate the business relationship before any high-risk action proceeds.

Technical breakdown

Why SPF, DKIM, and DMARC do not stop vendor impersonation

SPF, DKIM, and DMARC answer a narrow question: did this message come through an authorised mail path and survive cryptographic checks? They do not validate whether the account behind the email is legitimate, whether the relationship is expected, or whether the request fits normal business behaviour. That is why VEC can pass standard authentication and still be malicious. The attack succeeds in the trust layer, not the transport layer, and it often uses real vendor accounts, lookalike domains, or hijacked threads to look routine.

Practical implication: supplement mail authentication with behavioural controls that inspect sender history, transaction context, and identity relationships.

How VEC turns routine workflows into attack channels

VEC works because it maps to normal business processes such as invoicing, billing updates, order confirmations, and reconciliation requests. Attackers do not need a payload if they can influence a payment destination, extract sensitive data, or redirect a response path. In practice, the email is only the trigger. The real compromise happens when an employee trusts a message enough to move money, share data, or update credentials. This is why roles built around responsiveness are disproportionately exposed.

Practical implication: harden approval and verification steps around financial and vendor-facing workflows, not just inbox filtering.

Why behaviour analytics outperforms static rule-based detection

Static rules look for known bad indicators such as malicious links, suspicious attachments, or reputation failures. VEC often contains none of those. Behaviour analytics instead compares a vendor’s normal cadence, tone, device patterns, authentication signals, and transaction flow against what is happening now. That shifts detection from content inspection to relationship inspection. In a VEC scenario, the deviation may be subtle, such as a changed payment request structure or an unusual login pattern from an otherwise familiar sender.

Practical implication: use behavioural detection on vendor communications and tie alerts to inbox, identity, and transaction metadata.

Threat narrative

Attacker objective: The attacker aims to convert trusted vendor communication into financial fraud, data exposure, or ongoing trust abuse.

1. Entry occurs when the attacker impersonates a trusted vendor through compromised accounts, lookalike domains, or hijacked email threads that appear legitimate to the recipient.
2. Escalation happens when the recipient treats the message as routine business communication and acts on an invoice, billing, or payment request without independent verification.
3. Impact follows when money, sensitive data, or operational trust is redirected, and the organisation may repeat the mistake because the interaction looked normal and went unreported.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Vendor email compromise is a trust problem disguised as an email problem. The report shows that authenticated mail can still be malicious when the business relationship is the real target. That means the control boundary is not the message header, but the trust assumption behind the workflow. Practitioners should treat vendor identity as a governed relationship, not a sender string.

Response-oriented roles are the highest-friction attack surface in VEC. Entry-level sales, account management, project coordination, and finance-adjacent roles are built for speed and continuity, which makes them easier to manipulate with plausible vendor requests. The same operating model that keeps the business moving also shortens the time available for verification. Practitioners should reassess where business urgency is overriding identity validation.

Low reporting rates turn VEC into a persistence problem, not a one-off event. With only 1.46% of attacks reported and 7.3% of engagements coming from repeat victims, the organisation is learning too slowly from exposure. That is a governance failure, not just an awareness issue. Practitioners should measure whether reporting pathways are fast enough to interrupt repeat abuse patterns.

Trust verification is now a core identity control, not a communications nice-to-have. The field still tends to separate email security, IAM, and third-party risk into different teams, but VEC exploits the gap between them. When a vendor message can drive a payment or data action, the identity of the relationship matters as much as the identity of the account. Practitioners should collapse those silos in policy and control design.

Repeated engagement shows that behavioural drift is being normalised. Once employees have seen a vendor request before, they become more likely to accept the next one, even if details have changed. That is how trust debt accumulates across external relationships. Practitioners should treat repeat engagement as a signal that verification has already failed structurally.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%, according to the same survey.
• For the broader identity governance context, read Ultimate Guide to NHIs - Key Challenges and Risks for the control gaps that recur across machine and third-party identities.

What this signals

Vendor email compromise is a reminder that identity programmes cannot stop at authentication events. When business trust is the attack surface, security teams need policy, workflow, and escalation controls that verify the relationship before a transaction moves forward.

Trust debt: repeated acceptance of suspicious vendor requests creates a compounding governance problem, because the next malicious message is more likely to look familiar. Teams should watch repeat engagement as an early warning that approval paths are too permissive and reporting is too slow.

The broader lesson aligns with third-party access governance and NHI oversight: as external ecosystems expand, identity assurance has to extend into the business process itself. That is where a link to Ultimate Guide to NHIs - Why NHI Security Matters Now helps frame the operational pressure.

For practitioners

• Add trust checks to vendor-facing workflows Require a second verification step for invoice changes, payment detail updates, and high-risk vendor requests before any action is taken.
• Use behavioural signals for vendor communications Correlate sender history, cadence changes, device patterns, and authentication metadata so that a legitimate-looking email can still be flagged when the relationship deviates.
• Target high-response roles with process controls Prioritise finance, sales, account management, and project coordination teams for tighter approval gates because these groups are most likely to act quickly on vendor messages.
• Track repeat-victim patterns as a governance metric Measure how often the same employees engage with suspicious vendor messages, then feed that pattern into awareness, workflow redesign, and escalation handling.

Key takeaways

• Vendor email compromise succeeds because it weaponises trusted business relationships, not because it defeats email authentication.
• The scale is material, with 44% overall engagement, 72% engagement in very large enterprises, and almost no reporting after the fact.
• The practical response is to govern vendor trust as a workflow control problem, with stronger verification, behavioural detection, and repeat-victim tracking.

Key terms

• Vendor Email Compromise: Vendor email compromise is a social engineering attack that impersonates or hijacks a trusted supplier relationship to trigger payment, data, or workflow actions. It succeeds by exploiting business trust rather than malware, which makes identity and process verification more important than message filtering alone.
• Trust Layer: The trust layer is the set of assumptions people and systems make about whether a request is legitimate enough to act on. In VEC, the attacker targets that layer directly, using familiar vendor language, timing, and context to bypass the human judgment that sits above technical email authentication.
• Repeat Victim: A repeat victim is a user or team that engages with the same threat pattern more than once, showing that the original incident did not change behaviour enough to stop recurrence. In identity governance, repeat victimisation is a signal that approvals, reporting, or awareness controls are not closing the loop.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Abnormal AI: Vendor Email Compromise threat report. Read the original.