Vendor email compromise is reshaping BEC and finance workflows

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Abnormal AI's research: In 2026, vendor email compromise dominates business email compromise and is increasingly aimed at finance workflows, especially billing change requests.

Why it matters: IAM, PAM, and finance control teams need to treat vendor trust as an identity problem because attackers are exploiting approval chains, not just inbox access.

By the numbers:

• 61% of business email compromise is now vendor-related, according to Abnormal AI.
• Billing account update requests carry a 26.5% compromise rate, according to Abnormal AI.
• More than one in five phishing attacks, or 21.6%, now use redirect chains, according to Abnormal AI.

Context

Vendor email compromise is a form of BEC that abuses trust in suppliers, billing contacts, and routine approval paths rather than breaking into systems through obvious technical flaws. In this report, the primary control gap is not email delivery alone but the governance assumptions behind vendor change requests, payment reroutes, and human validation of familiar workflows.

The article frames a shift from technical exploitation to behavioural exploitation, where attackers invest more effort in reconnaissance because trusted relationships produce higher conversion rates. That makes this an identity and governance problem as much as an email-security problem, because the real target is the legitimacy attached to the request.

For IAM and finance teams, the issue is where identity proof, approval authority, and payment change handling intersect. Once an attacker can convincingly speak as a vendor, the security boundary moves from mailbox controls to workflow controls and verification discipline.

Key questions

Q: What breaks when vendor payment-change requests are handled like normal invoices?

A: The organisation collapses a high-risk identity event into a routine operational one. That lets attackers use familiarity as authority, reroute payments, and bypass the stronger checks that should protect changes to banking details, billing accounts, or vendor master data.

Q: Why do vendor fraud and impersonation attacks bypass legacy email defenses?

A: They bypass legacy defenses because those controls rely on signatures, known bad patterns, and repetitive indicators. AI-generated messages can be varied enough to avoid matching those rules while still sounding credible to the recipient. The weakness is not email alone, but the assumption that malicious messages will look obviously malicious.

Q: How should security teams govern billing account update requests?

A: Treat them as privileged business actions with separate approval, independent verification, and clear exception handling. The control goal is to confirm that the request really came from an authorised vendor contact and that the change is legitimate before any payment path is altered.

Q: What role should finance and IAM teams each play in vendor email compromise prevention?

A: Finance owns the workflow and approval discipline, while IAM owns identity evidence, external account validation, and access trust assumptions. The best protection comes when both teams share one control model for vendor contact changes, payment updates, and exception review.

Technical breakdown

Why vendor impersonation beats generic phishing

Vendor impersonation works because the attacker is not asking the recipient to click a random lure. They are presenting a request that already fits the recipient’s expected mental model, such as invoice handling, billing updates, or a routine contact change. That lowers friction and compresses decision time. In identity terms, the attack exploits delegated trust, where the recipient treats the request as legitimate because the relationship appears known. The article’s point is that trust signals, not malware, are now the main delivery mechanism. Practical implication: security teams should treat vendor-facing workflows as identity trust chains, not just inbox content.

Practical implication: validate the request path, not only the message content, before any payment or account change is approved.

Why billing account update requests are a high-risk workflow

Billing account update requests are more dangerous than ordinary invoice inquiries because they alter the payment destination or the account configuration that keeps payments flowing. That creates a high-value fraud opportunity and forces a stronger operational response, which is exactly why attackers prefer it. The risk is not the document itself but the authority to redirect future payments under the cover of a legitimate vendor relationship. This is where finance workflow governance and identity verification collide. Practical implication: treat payment-change requests as privileged business events that require stronger validation than routine invoices.

Practical implication: require out-of-band verification and separate approval for any request that changes where money flows.

How approval chains become the real control boundary

When attackers target vendor relationships, the decisive control is often not email filtering but the approval chain behind the transaction. If a request can move from inbox to payment action with only lightweight confirmation, the organisation has effectively made trust transferable. That creates a governance weakness across AP, procurement, and IAM because the same identity signal is being reused to authorise a financial act. The report shows attackers are optimising for exactly those paths. Practical implication: map every vendor change workflow to the approvals, identity checks, and exception paths that actually authorise it.

Practical implication: document who can approve a vendor change, what identity evidence they must check, and where exceptions are allowed.

Threat narrative

Attacker objective: The attacker wants to redirect legitimate payments or extract financial value by exploiting a trusted vendor relationship.

1. Entry occurs through vendor-related phishing or impersonation that reaches the target with a request that matches an expected workflow.
2. Credential or trust access is obtained when the recipient accepts the vendor relationship as sufficient proof and engages with the request.
3. Escalation happens when the attacker uses the approved relationship to alter billing details, payment instructions, or other finance workflow settings.
4. Impact is realised through diverted payments, fraud, and broader compromise of business email trust in vendor communications.

Breaches seen in the wild

• TruffleNet stolen AWS keys campaign 2025: TruffleNet used 800+ attacker hosts to test stolen AWS keys and check SES capacity; one compromised account sent a fake $50,000 invoice.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Vendor email compromise has become a governance problem, not just an inbox problem. When 61% of BEC is vendor-related, the attacker is abusing the credibility of a business relationship rather than merely spoofing a sender. That means the control failure sits in how organisations recognise, verify, and authorise external requests. Practitioners need to treat vendor trust as an identity asset with lifecycle controls, not an assumption baked into finance operations.

Billing change requests are a privileged workflow and should be governed that way. A request that reroutes future payments is not equivalent to a routine invoice query, because it changes a live financial control path. Abnormal AI’s data shows attackers understand that distinction and are selecting the workflow with the highest payoff. Finance teams should stop grouping payment changes with general correspondence and instead govern them as high-risk business events.

The named concept here is vendor trust transfer. The article shows that attackers are converting familiarity into authority by moving from relationship credibility to payment authority. That is a structural failure in approval design, because the organisation is allowing identity trust to flow from communication context into financial action. Practitioners should recognise that once trust is transferable, the control boundary has already been crossed.

Behavioural targeting is becoming the dominant path for BEC success. The report’s broader pattern, including redirect chains and contextual impersonation, shows that attackers are optimising for human decision-making under routine pressure. That weakens controls that focus only on technical detection and strengthens the case for workflow-specific verification. The implication is clear: governance must move closer to the point where humans authorise money to move.

Finance and IAM teams need a shared view of external identity risk. Vendor impersonation is simultaneously an email, identity, and process problem, which means siloed ownership leaves gaps between the controls. A finance approver may see a normal request while IAM sees no direct account compromise, and the attack succeeds in that seam. Practitioners should align approval policy, identity verification, and exception handling across both functions.

What this signals

Vendor trust transfer: once a supplier relationship is treated as sufficient evidence of legitimacy, attackers can move from message deception to financial authorisation. That is why vendor email compromise needs workflow-level controls, not just better filtering.

The practical shift is to separate routine correspondence from state-changing requests. Billing updates, bank detail changes, and vendor master modifications should each carry their own validation path, because the attacker’s objective is to move an approved relationship into payment control.

For teams running broader identity programmes, this is a reminder that external identity risk does not stop at SSO boundaries. Trusted relationships can be weaponised wherever approval authority is loosely coupled to the channel that delivered the request.

For practitioners

• Tighten vendor change verification Require out-of-band confirmation for any vendor request that changes billing details, bank instructions, or payment routing. Use a separately known contact path, not the reply chain in the request.
• Reclassify payment changes as privileged events Treat billing account updates as high-risk workflow steps with explicit approval, documented evidence, and exception review. Do not process them through the same control path used for ordinary invoice intake.
• Map vendor approval chains end to end Document who can initiate, review, and authorise vendor-related financial changes, then identify where identity proof is expected, where it is assumed, and where it is missing.
• Separate routine invoices from account modifications Build policy so invoice handling and billing account changes follow different controls, because the latter alters payment destination and deserves stronger scrutiny.
• Train finance teams on contextual impersonation Use real examples of vendor spoofing, internal impersonation, and workflow abuse so approvers learn to question requests that look familiar but change financial state.

Key takeaways

• Vendor email compromise now targets the trust layer of business operations, not just user inboxes or obvious phishing lures.
• Billing account update requests are a particularly risky workflow because they can redirect ongoing payments under the cover of a familiar supplier relationship.
• The right control response is to separate vendor identity verification, finance approval, and exception handling instead of treating every supplier request as routine correspondence.

Key terms

• Vendor Email Compromise: Vendor email compromise is a form of impersonation that targets supplier, contractor, or partner relationships. Attackers exploit routine vendor communication patterns to request payment changes, invoice redirection, or other sensitive actions, so identity and process verification must extend beyond internal users.
• Billing Account Update Request: A billing account update request is a change to the payment destination, account details, or financial routing associated with an ongoing supplier relationship. It is high risk because a successful change can alter future payments, making it more powerful than a single invoice scam.
• Trust Transfer: Trust transfer is the security failure that occurs when users give AI-generated output more credibility than the raw content it was based on. In practice, the assistant’s polished tone, layout, or system-like framing can make attacker-shaped content feel legitimate, which increases the chance of unsafe user action.
• Contextual Impersonation: Contextual impersonation is a social engineering technique that mimics the language, timing, and workflow of an expected business interaction. It differs from generic phishing because it relies on situational legitimacy, making it harder to block with message-level controls alone.

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 building or maturing an IAM programme, it is worth exploring.