Phishing that begins with a compromised trusted third party rather than a clearly malicious sender. The attacker uses existing business trust to increase the chance that users will open the message, click a link, or submit credentials to a convincing login page.
Expanded Definition
Supplier-driven phishing is a form of social engineering that exploits an established vendor, contractor, or service-provider relationship to make a message appear routine and trustworthy. The attacker may compromise the supplier’s mailbox, billing system, support portal, or collaboration account, then send messages that fit the normal business context well enough to bypass user suspicion and sometimes even weak filtering. In security terms, the threat is less about the wording of the lure and more about the abuse of inherited trust across organisational boundaries.
Definitions vary across vendors, but the core pattern is consistent: the attack originates from a trusted third party or from infrastructure that appears to belong to that third party. That makes supplier-driven phishing especially relevant to identity security, because the recipient is often being manipulated into handing over credentials, approving a payment, or accepting an MFA prompt for what looks like a legitimate business interaction. NIST’s NIST Cybersecurity Framework 2.0 is useful here because it frames the need to govern external dependencies, identity assurance, and response readiness rather than treating email threats as isolated events.
The most common misapplication is treating supplier-driven phishing as ordinary spam, which occurs when security teams focus only on sender reputation and ignore compromise of a trusted supplier account or domain.
Examples and Use Cases
Implementing defences against supplier-driven phishing rigorously often introduces workflow friction, requiring organisations to balance faster supplier communication against stronger verification steps for payments, credential requests, and account changes.
- A finance team receives an invoice from a long-standing logistics partner, but the partner’s mailbox has been compromised and the payment details now point to attacker-controlled accounts.
- A help desk employee gets a password reset request that appears to come from a managed service provider using familiar terminology and branding, but the request is a pretext for account takeover.
- An executive assistant is sent a document-sharing link from a supplier contact whose collaboration account has been hijacked, leading to credential capture on a convincing login page.
- A procurement team is asked to update bank details for a contractor after a “vendor onboarding” email that matches previous correspondence style, even though the domain has been subtly altered.
- Security teams can use MITRE ATT&CK style threat mapping to understand the follow-on techniques that commonly appear after the initial trust abuse, even though ATT&CK is not a glossary definition source.
Why It Matters for Security Teams
Supplier-driven phishing matters because it compresses several risk domains into one event: email security, third-party risk, identity verification, and business process trust. When the attacker is already inside a supplier account or has convincingly cloned a supplier workflow, normal user awareness training often fails unless it is backed by verification controls, strong authentication, and process-level checks for high-risk actions. Security teams also need to account for Non-Human Identity exposure, because compromised supplier integrations, service accounts, and API credentials can become the foothold that makes the phishing campaign look authentic in the first place.
Controls that support this term are usually found in broader governance and identity guidance such as CISA social engineering guidance and identity assurance practices that validate who is actually requesting a change, not merely which mailbox delivered it. The operational lesson is that trusted relationships must be continuously verified, especially where payment, access, or sensitive data transfer is involved. Organisations typically encounter the cost of supplier-driven phishing only after a trusted vendor message has already triggered a fraud, credential theft, or account compromise, at which point the trust boundary becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the technical controls, and DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-01 | The CSF addresses third-party risk and trust boundaries relevant to supplier-driven phishing. |
| NIST SP 800-63 | IAL2 | Identity assurance helps verify requests tied to supplier interactions and account changes. |
| OWASP Non-Human Identity Top 10 | Supplier compromises often abuse non-human accounts, tokens, and integrations to make phishing credible. | |
| NIST AI RMF | The AI RMF is relevant where AI-assisted phishing or supplier automation affects trust decisions. | |
| DORA | DORA highlights operational resilience and third-party dependency risk in critical digital services. |
Inventory supplier dependencies and govern high-trust communications through third-party risk controls.
Related resources from NHI Mgmt Group
- Why do AI-driven phishing attacks make passwordless authentication more important?
- Why do AI-driven phishing attacks still succeed when organisations use modern authentication?
- How should security teams handle AI-driven phishing in identity workflows?
- Why does AI-driven phishing change identity security decisions?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
