Why do secure email gateways miss phishing campaigns that use legitimate third-party services?

Secure email gateways miss these campaigns because they are built around static rules, keyword checks, and allowlists. That model works poorly when attackers send from a trusted service instead of an obviously malicious domain. Without behavioral analysis, the gateway cannot judge whether the message content, sender relationship, or request is inconsistent with normal organizational activity.

Why static SEG logic fails against trusted third-party senders

Secure email gateways are strongest when the signal is obvious, for example a bad sender domain, a known malicious attachment, or a reused phishing pattern. They struggle when the message is delivered through a legitimate service because the transport path, reputation, and delivery infrastructure can look normal even when the intent is malicious. That creates a blind spot around context, not just content.

Most SEG stacks still lean on deterministic checks, such as domain reputation, keyword matching, attachment scanning, and allowlists. Those controls can be useful, but they are poor at judging whether a request is socially plausible for the recipient, whether the sender relationship fits normal business activity, or whether the message is abnormal only when viewed across the user’s communication history.

That gap is why campaigns that abuse SaaS notifications, form tools, document sharing platforms, or compromised business accounts often arrive as valid mail. The gateway sees a message from a trusted service and may give it a pass, while the real abuse is in the workflow, the impersonated relationship, or the instruction embedded in the content.

What a gateway cannot infer from legitimacy alone

A legitimate sending service can hide the attacker’s real objective. The service may be used to host the lure, relay the message, or terminate the sender side of the interaction, while the phish itself points the user toward credential theft, payment diversion, token capture, or a fake login flow. This means the security decision cannot be based only on whether the sender infrastructure is reputable.

The better question is whether the request is consistent with normal organizational behavior. A reset notice, document share, invoice prompt, or approval request can be technically valid and still be suspicious if it arrives unexpectedly, uses unusual urgency, or asks for an action that does not fit the recipient’s role. Behavioral analysis matters because the maliciousness is often in the relationship, timing, and request path rather than the sending host.

Legitimate third-party services also create asymmetric trust. Organizations often trust the platform, but attackers only need one weak tenant, abused integration, or stolen account inside that platform to exploit the trust automatically granted to its outbound mail. That is why reputation-only filtering is a weak proxy for safety in modern phishing.

What defenders should change in practice

Successful detection usually requires layering sender authentication, content inspection, user context, and post-delivery response rather than expecting the SEG to solve the problem alone. When a message comes from a trusted service, the control question should shift from “Is this sender known?” to “Is this request expected, authorized, and consistent with normal business workflow?”

For this reason, mailbox-layer detection, identity telemetry, and user reporting often matter as much as the SEG. The organization needs to see whether the same service account, workflow, or integration is being abused across many recipients, whether the message links to an unusual destination, and whether the recipient is being pushed to authenticate outside normal channels. NHIMG’s State of Non-Human Identity Security is useful here because third-party services, tokens, and delegated access are often the trust edge that phishing campaigns exploit. For a concrete abuse pattern, see MailChimp Breach and Salesloft OAuth token breach.

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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-05 — Third-Party and Supply Chain Identity Risk	Third-party services are the trust edge abused in these phishing campaigns.
	NHI-03 — Secrets and Credential Management	Phishing via trusted services often aims to steal tokens, keys, or login material.
Recommendation — Assess third-party identity trust and restrict delegated access paths to reduce phishing abuse. Protect and rotate credentials exposed through email-based phishing paths.
NIST CSF 2.0	DE.CM — Continuous Monitoring	Behavioral analysis and anomaly detection are needed when static SEG rules fail.
	PR.AA — Identity Management, Authentication, and Access Control	The attack exploits trusted access and authentication paths beyond sender reputation.
Recommendation — Monitor email, identity, and workflow anomalies to detect trusted-service phishing. Strengthen authentication and access checks so message legitimacy is not inferred from sender reputation alone.
CIS Controls v8	8 — Audit Log Management	Mailbox and identity telemetry are needed to spot abuse that SEG filtering misses.
Recommendation — Collect and review email and identity logs to surface suspicious service-based delivery patterns.
MITRE ATT&CK	T1566 — Phishing	The subject is a phishing technique that abuses trusted delivery infrastructure.
	T1583 — Acquire Infrastructure	Attackers leverage legitimate third-party platforms as delivery infrastructure.
Recommendation — Map trusted-service lures to phishing detections and user-reporting playbooks. Track abuse of legitimate services as part of attacker infrastructure acquisition and staging.
NIST SP 800-63	5.2 — Authenticator Lifecycle Management	Phishing often aims to capture authentication material used outside the SEG decision.
Recommendation — Use phishing-resistant authenticators and lifecycle controls to limit stolen-credential reuse.

Practitioner Guidance

What to verify: Treat legitimate third-party delivery as a trust signal, not a clearance decision. Verify whether the message aligns with a known workflow, expected sender relationship, and expected destination before trusting the platform reputation.

What to measure: Track how often suspected phish bypass the SEG but are later caught by mailbox rules, user reports, or identity telemetry. If those detections are carrying the load, the gateway is over-relying on static reputation logic.

Common mistake: Do not tune allowlists so broadly that they suppress scrutiny for an entire service category. That often converts a trusted platform into a high-confidence delivery channel for phishing.

Practitioner takeaway: The control objective is not to block every trusted service, it is to detect when a trusted service is being used in an untrusted way, which usually requires context beyond the SEG itself.