Look for payment-change requests, urgent invoice revisions, or banking updates from senders that are technically authenticated but inconsistent with normal supplier behaviour. A passing SPF, DKIM, or DMARC result does not prove legitimacy. The clearest warning sign is a request that matches a business process but not the sender’s usual pattern.
Why Authentication Success Does Not Mean the Sender Is Genuine
Authentication checks whether the message came from an infrastructure path that can present valid SPF, DKIM, or DMARC alignment. It does not prove that the person or organisation behind the message is the expected supplier, nor that the request fits normal vendor behaviour. When impersonation succeeds, the message often looks technically clean while the business context is still wrong.
That is why the strongest signal is not a failed control but a mismatch between the request and the supplier’s ordinary patterns. A payment update, invoice correction, or banking change can all be legitimate workflows, yet the attacker wins by mimicking the workflow while changing the destination, urgency, or approval path.
What Behavioural Mismatches Usually Expose the Impersonation
Look for requests that are plausible in form but abnormal in timing, tone, or process. Payment-change requests that arrive outside the normal renewal cycle, invoice revisions that bypass the usual contact chain, or banking updates sent from a mailbox that is technically authenticated but unfamiliar to the receiving team all deserve scrutiny.
Other warning signs include pressure to act quickly, refusal to use established vendor portals, minor but persistent deviations in wording, and a sender who seems aware of just enough internal detail to sound credible. The key point is that the email can pass a technical gate while still failing the supplier-relationship test.
In practice, this means the detection question is not “did authentication pass?” but “does this request match what we already know about this supplier’s normal business process?” That distinction matters because attackers often use a valid domain, a compromised mailbox, or a trusted sending service to get through the first layer of defence.
Where the Control Breaks Down in the Real World
Authentication can be true for the transport path and still useless as a trust indicator when the sender account, third-party mailbox, or compromised business system is being abused. That is why vendor impersonation frequently rides on legitimate mail infrastructure, compromised supplier accounts, or lookalike communications that preserve enough technical authenticity to avoid obvious filtering.
The practical failure mode is overreliance on a single trust signal. A clean authentication result may lower spam confidence, but it should not override financial or operational verification when the message asks for sensitive changes. If the request alters payment instructions, supplier ownership, or banking details, the verification standard should be higher than normal email hygiene checks.
For a broader identity and access perspective, the same pattern shows up whenever a trusted account or token is used in a way that the business does not expect. The issue is not only whether the sender can authenticate, but whether the authenticated sender still has legitimate authority to ask for the action being requested. Good operational practice is to separate message authenticity from request legitimacy.
Risk and Threat Considerations
Vendor impersonation is dangerous because it converts a trusted supplier relationship into a fraud channel. Attackers do not need to break SPF, DKIM, or DMARC if they can persuade staff to trust a message that fits the workflow but not the supplier’s normal behaviour.
Failure mechanism: The attacker preserves enough technical legitimacy to pass email checks, then introduces a business-process change, such as a new bank account or revised invoice, where the receiver is least likely to challenge the request.
Impact: Organisations can make fraudulent payments, redirect funds, or create downstream reconciliation problems before the deception is detected. The longer the normal vendor relationship has existed, the easier it is for a convincing but abnormal request to slip through.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Authenticated senders still need authority checks for trusted business actions. |
| Recommendation — Require separate verification for high-risk requests beyond email authentication. | ||
| OWASP ASVS | V10 — OAuth and OpenID Connect | Identity assertions can be technically valid while the requester is still untrusted. |
| Recommendation — Validate that authenticated identity matches the expected business actor before acting. | ||
| CIS Controls v8 | CIS-5 — Account Management | Vendor impersonation often exploits trusted accounts and changed payment paths. |
| Recommendation — Verify and control account-related changes with out-of-band confirmation. | ||
Practitioner Guidance
What to verify: Treat any change to payment details, invoice destination, or banking coordinates as a verification event, not an email-handling task. Confirm the request through a previously trusted channel, using contact details already on file rather than details supplied in the message.
Decision rule: If the message passes authentication but asks for a business-critical change, do not clear it on the basis of email trust alone. Escalate to finance, procurement, or supplier-management owners when the request is unusual, urgent, or inconsistent with the vendor’s normal cadence.
Practitioner takeaway: Authentication can validate the message path, but only business-context checks can validate the request itself, which is why impersonation often succeeds first in process, then in email.
Related resources from NHI Mgmt Group
- Why do secrets stay dangerous even when they are no longer actively used?
- Why do poisoned tenant attacks work even when email authentication passes?
- Why do SaaS supply chain attacks keep succeeding even when organisations have vendor review processes?
- How should security teams defend against vendor-account phishing that passes normal email authentication checks?