Why do vendor account compromises bypass many email security tools?

Why This Matters for Security Teams

Vendor account compromises bypass email security because they do not look like classic phishing. The attacker is not trying to impersonate a sender from scratch; they are operating from a trusted mailbox, domain, or SaaS account that already has reputation, contact history, and often a believable thread. That means many gateway and filtering controls never see a clear malicious signature, especially when the message body is short, timely, and consistent with the vendor’s normal business pattern.

This is a non-human identity problem as much as an email problem. A compromised vendor account often carries the same practical authority as an API token or service principal: it can authenticate, inherit trust, and trigger downstream action. NHIMG research on The 52 NHI Breaches Report shows how often attackers exploit trusted identities rather than technical malware delivery. In the same vein, the Anthropic report on AI-orchestrated cyber espionage reinforces that attackers increasingly use legitimate access paths to reduce detectable noise. In practice, many security teams discover the issue only after a finance approval, invoice change, or internal credential handoff has already occurred, rather than through intentional detection.

How It Works in Practice

Once a vendor mailbox, ERP account, or support portal login is taken over, the attacker benefits from inherited legitimacy. Email controls often score the message as safe because the sender passes authentication, the reply chain is valid, and the content lacks overt indicators such as malware or a spoofed domain. The real abuse happens in the behaviour layer: unusual request timing, shifted payment details, new callback numbers, or a subtle change in how the sender frames urgency.

Operationally, defenders need to treat vendor communications as identity events, not just mail events. That means combining email telemetry with account posture, thread history, and transaction context. Current guidance suggests prioritising:

• vendor account anomaly detection across mailbox, SSO, and SaaS activity
• step-up verification for bank detail changes, password resets, and access grants
• policy checks that compare request type against historical vendor behaviour
• immutable logging for approvals, forwarding rules, OAuth grants, and inbox delegation

This is consistent with NHIMG findings in The State of Non-Human Identity Security, where 85% of organisations report limited visibility into third-party vendors connected via OAuth apps, and with the broader NHI reality described in Ultimate Guide to NHIs. These controls tend to break down in high-volume shared mailboxes and outsourced finance workflows because legitimate vendor exceptions drown out behavioural signal.

Common Variations and Edge Cases

Tighter verification often increases friction for procurement, accounts payable, and customer support, so organisations have to balance fraud resistance against operational speed. That tradeoff is especially visible when the vendor is real, the request is expected, and the attacker only changes one detail, such as routing instructions or contact ownership.

Best practice is evolving for edge cases where the account is legitimate but the workflow is not. A vendor can be compromised through password theft, OAuth token abuse, session hijacking, or inbox rule manipulation, and each path may require a different control. There is no universal standard for this yet, but practitioners increasingly pair email security with identity governance, vendor risk review, and short-lived approval steps for sensitive requests.

One practical lesson is that threat actors often target trust chains instead of message content, which is why defense-in-depth matters more than spam scoring alone. NHIMG’s 52 NHI Breaches Analysis and the State of Secrets in AppSec both point to a broader pattern: once an attacker gains a legitimate credential or token, downstream controls often assume trust that no longer exists.

Related resources from NHI Mgmt Group

• Why do traditional email security tools miss payload-less BEC attacks?
• What should teams prioritise when evaluating behavioural email security tools?
• Why do fraudulent invoices and wire requests bypass traditional security tools?
• How should security teams handle vendor email compromise in enterprise environments?