Trusted-workflow phishing

Phishing that abuses a legitimate business or SaaS workflow to deliver a malicious outcome through genuine infrastructure. The message may authenticate correctly, but the attacker controls the destination, request or approval path rather than the sender identity.

Expanded Definition

Trusted-workflow phishing is a social engineering pattern that exploits confidence in an established business process rather than merely spoofing a sender. Unlike conventional phishing, the message can pass authentication checks, originate from a legitimate service, or arrive through a normal collaboration channel, yet the attacker manipulates the request, approval sequence, or destination to achieve a malicious result. That makes it especially dangerous in SaaS-heavy environments where users are trained to trust workflow notifications, shared documents, ticketing systems, and approval queues.

The key distinction is that the abuse sits inside the workflow itself. A request may appear valid because the infrastructure is genuine, the branding is correct, and the sender account is real. The compromise is in the business logic: a consent flow, payment change, document share, MFA reset, or vendor approval is redirected to an attacker-controlled outcome. Definitions vary across vendors, but the security meaning is consistent: the workflow is the attack surface, not just the email.

NIST frames this kind of risk through identity, access, and governance outcomes in NIST Cybersecurity Framework 2.0, especially where trust decisions depend on process integrity. The most common misapplication is treating trusted-workflow phishing as ordinary email phishing, which occurs when defenders focus only on message filters and ignore approved pathways that can be abused from inside legitimate systems.

Examples and Use Cases

Implementing controls against trusted-workflow phishing rigorously often introduces friction in routine business operations, requiring organisations to weigh speed and convenience against stronger verification at each approval step.

• A finance approver receives a genuine SaaS notification requesting a vendor bank detail update, but the embedded link sends them to an attacker-controlled destination inside a compromised tenant.
• An IT help desk ticket arrives through a legitimate workflow and asks for an MFA reset; the process is authentic, but the requester is impersonating an employee and steering the reset to a new device.
• A document collaboration invitation is real and properly authenticated, yet the shared file contains a request to approve a payment or grant access to a sensitive workspace.
• A cloud admin receives a passwordless sign-in or OAuth consent prompt from a real application, but the consent scope grants the attacker access to mail, files, or automation tools.
• A procurement workflow in a SaaS platform routes to a legitimate approver chain, but a compromised account changes the recipient details before final approval is completed.

These scenarios are commonly documented in industry guidance on business email compromise and identity abuse, even when the attacker is operating through authentic infrastructure. The practical lesson is that the origin of the request matters less than the integrity of the workflow state. When a platform such as the NIST Cybersecurity Framework 2.0 is applied, teams should examine how trust is established at each step, not just whether the message was delivered from a real service.

Why It Matters for Security Teams

Trusted-workflow phishing is significant because it bypasses a control assumption that many security programmes still rely on: that a legitimate channel means a legitimate request. That assumption breaks down in cloud collaboration, delegated administration, automated approvals, and identity-centric services where the attacker can exploit the process after authentication has succeeded. The impact is often broader than one compromised inbox, because the workflow may lead to privilege escalation, unauthorised payment, data exposure, or downstream access to other systems.

For security teams, the issue sits at the intersection of identity governance, privileged access, and workflow assurance. If approvals are not independently verified, a valid user session can be enough to authorise harmful change. Where non-human identities and automation are involved, the risk grows further because systems may execute approved actions without human scrutiny. That makes trusted-workflow phishing relevant to NHI governance, even when the initial lure targets a person.

Organisations typically encounter the true cost only after an approved workflow has been abused and a payment, access grant, or credential reset has already completed, at which point trusted-workflow phishing becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How should security teams detect phishing that uses trusted redirect chains?
• Who is accountable for phishing defences when trusted redirects are abused?
• How should healthcare teams implement phishing-resistant authentication without slowing clinical workflow?
• Why do trusted document-signing workflows become attractive phishing targets?