Why do employees keep engaging with vendor impersonation attacks?

Why This Matters for Security Teams

vendor impersonation succeeds because it targets routine business trust, not just weak passwords or careless clicking. Attackers mimic procurement, finance, support, and executive workflows so the request feels like part of normal operations. That makes this a governance problem as much as a phishing problem: if teams only train for obvious fraud, they miss the contextual cues that make the message believable.

For NHI and agentic environments, the same trust gap appears when service accounts, API keys, and automation agents are allowed to act on familiar workflows without strong request validation. The Ultimate Guide to NHIs shows why this matters now, and CISA’s cyber threat advisories consistently reinforce that adversaries exploit business process familiarity as readily as technical weakness. Current guidance suggests that awareness alone is insufficient when the attacker can mirror real vendor language, timing, and escalation paths. In practice, many security teams encounter repeated interaction only after payment diversion, credential theft, or downstream account compromise has already occurred.

How It Works in Practice

Vendor impersonation attacks work best when the attacker knows what a legitimate request should look like. That includes invoice timing, common approval chains, support-ticket language, and the names of actual suppliers. The message may reference a real project, route through a compromised mailbox, or use a lookalike domain to reduce suspicion. Employees engage because the request appears to fit the business context they are already used to handling.

Defending against this requires controls that verify the request, not just the sender. Security teams should combine process controls, technical validation, and escalation discipline:

• Require callback verification or out-of-band confirmation for payment changes, bank detail updates, and urgent exceptions.
• Use domain authentication, mailbox protection, and stronger sender validation to reduce spoofing and account takeover risk.
• Apply least privilege in finance and procurement so one compromised inbox cannot complete the full workflow.
• Log and review anomalous requests, especially when they reference invoices, access resets, or supplier onboarding.
• Train staff on business-process red flags, not just generic phishing indicators.

NHIMG’s 52 NHI Breaches Analysis and Ultimate Guide to NHIs are useful because they show how trust abuse often spreads once credentials or workflow access are exposed. A relevant parallel exists in AI-enabled intrusion tradecraft documented in the Anthropic report, where automation amplified the attacker’s ability to blend into normal operations. These controls tend to break down when approval paths are informal, inboxes are shared, or finance teams are pressured to act quickly without an independent verification step.

Common Variations and Edge Cases

Tighter payment and vendor controls often increase friction, requiring organisations to balance fraud prevention against operational speed. That tradeoff becomes harder in global teams, outsourced finance functions, and regions where deference to authority is culturally reinforced. Guidance suggests that there is no universal standard for this yet, so organisations should adapt controls to transaction value, vendor criticality, and local escalation norms.

The edge cases are usually process-related rather than technical. A legitimate supplier may send from a new domain after a merger, a finance approver may be travelling, or a shared mailbox may obscure the true requester. In those situations, staff need a safe way to verify without being punished for slowing down business. That is why security awareness must be paired with defined exception handling and manager-backed challenge procedures.

For broader identity abuse patterns, the OWASP NHI Top 10 and Top 10 NHI Issues help connect vendor impersonation to the wider problem of over-trusted identities and weak verification. In practice, these attacks keep succeeding where people are expected to rely on familiarity instead of independent proof, especially when the business process rewards speed more than validation.

Related resources from NHI Mgmt Group

• Why do rules-based email controls fail against modern phishing and vendor impersonation?
• What do security teams get wrong about vendor impersonation in email?
• Why do static email rules miss modern impersonation attacks?
• What breaks when employees make rapid decisions on AI-crafted vendor emails?