Why third-party secure email gateways are losing value

At a glance

What this is: This analysis says third-party secure email gateways are losing marginal value because modern cloud email attacks arrive clean, authenticate successfully, and are better caught with identity and behaviour signals after delivery.

Why it matters: For IAM, NHI, and human identity teams, the issue is where trust is evaluated: at the perimeter, or against live identity and behavioural evidence that matches how cloud email attacks unfold.

Context

Third-party secure email gateways were built for a threat model dominated by attachment malware and obvious malicious indicators. In cloud email, the primary risk has shifted to identity abuse, vendor impersonation, and behaviour-driven manipulation that can look legitimate at arrival.

That shift matters for identity governance because email trust is now entangled with user identity, vendor identity, and message provenance. A control stack that only evaluates risk at ingress will miss threats that only become visible after delivery, when context, replies, and multi-step social engineering reveal the attack.

The practical question is whether the gateway still adds unique security value once native cloud filtering and behavioural detection are already in place. In many environments, the answer depends less on habit and more on whether the control is solving a current identity problem or preserving an older network-era assumption.

Key questions

Q: What breaks when secure email gateways are the main email security control?

A: When SEGs are treated as the main control, organisations often miss identity-based phishing, internal impersonation, and outbound leakage driven by human error. The gateway may still block commodity spam, but it cannot fully govern user action, recipient context, or account compromise. That leaves a gap between message delivery and actual risk reduction.

Q: Why do native cloud email controls reduce the value of third-party gateways?

A: Because Microsoft 365 and Google Workspace already handle spam, known malware, and basic phishing for many organisations. Once those controls cover the commodity threat set, the gateway must justify itself on the remaining edge cases rather than on duplicate filtering.

Q: How should security teams measure whether a secure email gateway is still effective?

A: Measure how often it blocks real threats, how much analyst time it consumes, and how many false positives it creates. A control that detects some phishing but overwhelms teams with graymail can still be operationally weak. The most useful metric is whether detection improves while triage effort falls.

Q: Should organisations replace perimeter email filtering with post-delivery detection?

A: They should if their dominant email risk comes from clean-text attacks that unfold through identity and behaviour rather than payloads. Post-delivery detection is better suited to cloud email because it can use user context, sender history, and message sequence to find abuse after the inbox.

Technical breakdown

Why clean-text attacks evade perimeter email controls

Modern business email compromise, vendor fraud, and credential phishing often contain no payload, no exploit, and no obvious malware. That makes them poor fits for controls that rely on static signatures, attachment detonation, or reputation alone. SPF, DKIM, and DMARC can all pass while the content still carries social engineering risk, because those checks authenticate the message path, not the sender’s intent or the legitimacy of the request. In cloud email, adversaries also use compromised mailboxes and multi-step conversations that unfold across messages and platforms, which means the malicious decision point may not exist in the first email at all.

Practical implication: Treat message arrival as an incomplete trust signal and shift inspection toward identity, context, and conversation sequence.

Why native cloud filtering changes the SEG equation

Microsoft 365 and Google Workspace already absorb a large share of spam, known malware, and commodity phishing before a third-party SEG adds much extra value. Once native filtering is doing that baseline work, the SEG has to justify itself by catching the harder cases, not the easy ones. The article’s core argument is economic as much as technical: when native controls and modern behavioural detection cover most routine threats, the remaining gateway value is offset by tuning, allowlisting, false-positive triage, and licensing overhead.

Practical implication: Measure SEG value against residual threat coverage, not against the total volume of blocked mail.

How API-based detection changes email security architecture

API-integrated email security platforms inspect identity and behaviour continuously instead of freezing risk decisions at the perimeter. That matters because cloud email attacks often emerge over time, after delivery, when the recipient response, vendor relationship, or account activity reveals the pattern. This is a different control model from the SEG, which makes a judgement at the point of entry and then stops. The architectural shift is from mail-flow inspection to post-delivery analysis, where identity signals, vendor communication patterns, and anomalous behaviour are treated as primary evidence.

Practical implication: Design email security around continuous detection and response, not one-time perimeter verdicts.

Threat narrative

Attacker objective: To manipulate a trusted recipient into revealing credentials, transferring funds, or accepting a fraudulent request without triggering perimeter detection.

1. Entry occurs through clean-text BEC, vendor fraud, or credential phishing that arrives from legitimate infrastructure and passes SPF, DKIM, and DMARC.
2. The message leverages trusted identity, authentic-looking wording, and multi-step social engineering rather than a payload or exploit to create opportunity for abuse.
3. Impact comes when the recipient acts on the message, enabling credential theft, fraudulent payment, or broader account compromise without gateway-detectable malware.

Breaches seen in the wild

• CircleCI breach 2023: Malware stole a CircleCI engineer's SSO session; attackers exfiltrated customers' CI/CD secrets and keys, forcing a platform-wide rotation.
• EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Third-party SEG value is collapsing because the control is tied to a false premise: that email risk is best judged at arrival. That premise held when malware attachments and signature matching dominated the threat model, but it fails when the abuse path is identity, trust, and conversation rather than payload. The implication is that email security governance must be evaluated on how well it understands live identity signals, not on how much mail it quarantines.

Native cloud filtering has become the baseline, not the differentiator: Microsoft 365 and Google Workspace now absorb enough commodity spam, malware, and basic phishing that many standalone gateway functions overlap with controls already present in the stack. When a control becomes redundant, the real question is whether it still covers a distinct failure mode or simply adds routing friction and analyst toil. Practitioners should treat overlap as a governance issue, not an architectural accident.

Identity and behaviour are now the decisive email-security variables: BEC, vendor fraud, and credential phishing succeed because the message looks legitimate in isolation and only becomes suspicious when read against sender history, user behaviour, and business context. That makes the security problem broader than mail security and closer to trust governance across human identity, vendor identity, and account activity. Teams that do not connect those signals will keep defending the wrong layer.

Post-delivery detection is the right control plane for cloud email: modern attacks often unfold after the inbox, not before it. A control that can continue to assess content, identity, and response patterns after delivery is better aligned to cloud operation than one that only scores a message at ingress. Practitioners should re-evaluate email security around ongoing verification rather than static perimeter judgment.

Identity blast radius in email is now larger than the mailbox itself: once a message induces a credential handoff, payment action, or vendor trust decision, the security event crosses into IAM, fraud, and supply chain governance. That broader blast radius means email security can no longer be managed as a siloed messaging problem. Practitioners need cross-domain ownership that treats email as an identity control surface.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Post-delivery detection is becoming the control boundary that matters: perimeter inspection still has a role, but cloud email threats increasingly reveal themselves only after the message lands and the interaction begins. That means security teams need continuous correlation across message content, user behaviour, and vendor context rather than a single yes-or-no verdict at ingress.

Native cloud filtering should be treated as the new baseline: if the platform already removes most spam, known malware, and basic phishing, a third-party SEG must prove distinct value on the remaining attack patterns. Teams that do not re-baseline their email architecture will keep paying for duplicate controls and false-positive handling.

For practitioners

• Map SEG coverage against native cloud controls Inventory what Microsoft 365 and Google Workspace already block in your environment, then isolate which remaining threats the third-party gateway uniquely stops. If the overlap is high and the residual value is low, you have evidence for consolidation rather than assumption.
• Validate behavioural detection before retiring the gateway Run modern email security in parallel with the existing SEG and compare detections on BEC, vendor impersonation, and credential phishing cases that pass authentication checks. Use real attacker patterns, not generic spam, to test whether the new layer catches what the gateway misses.
• Reduce allowlisting and false-positive churn Measure how much analyst time is spent maintaining gateway policy, allowlists, and quarantine triage versus investigating real identity-abuse events. If the operational cost is rising while detections are duplicative, the SEG is consuming security capacity rather than preserving it.
• Shift email governance toward identity signals Require security operations to correlate sender identity, user behaviour, vendor relationships, and post-delivery activity before treating a message as safe. That correlation is what surfaces clean-text attacks that perimeter inspection alone will miss.

Key takeaways

• Third-party secure email gateways struggle when attacks arrive as legitimate, clean-text messages that rely on identity abuse instead of payload delivery.
• The practical issue is not whether email still needs filtering, but whether perimeter controls add anything beyond native cloud protections and behavioural detection.
• Teams should re-evaluate email security around post-delivery identity signals, because that is where modern BEC, vendor fraud, and credential phishing become visible.

Key terms

• Secure Email Gateway: A secure email gateway is a control layer that inspects email before it reaches users and can also inspect outbound mail. It filters malicious content, enforces policy, and reduces exposure to phishing, malware, and data leakage, but it does not replace identity governance or account monitoring.
• Business email compromise: A form of social engineering where an attacker impersonates a trusted person or domain to manipulate payment, change banking details, or extract sensitive information. It often succeeds without malware because the attacker targets process trust and human judgement instead of technical controls.
• Post-delivery detection: Post-delivery detection is the ability to identify malicious or risky email activity after a message has reached a mailbox. It matters because many modern attacks are not obvious at delivery time, so defenders need telemetry from user interaction, mailbox rules, and account behaviour to spot abuse before business impact occurs.
• Identity-centric detection: Identity-centric detection is the practice of interpreting security alerts through identity context such as role, privilege, and expected behaviour. It helps analysts separate routine activity from suspicious access patterns and improves the accuracy and speed of triage.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.