Why third-party secure email gateways are losing value

At a glance

What this is: This analysis argues that third-party secure email gateways are losing marginal value because cloud email attacks now arrive as legitimate-looking text that perimeter inspection cannot reliably stop.

Why it matters: It matters because IAM, NHI, and security teams need email controls that track identity, behaviour, and delegated access patterns instead of relying on arrival-time filtering alone.

👉 Read Abnormal AI's analysis of why secure email gateways are losing value

Context

Secure email gateways were built for a different attack model, one dominated by malware payloads and signature matching at the perimeter. In cloud email environments, the primary problem is often not malicious content in the message itself, but identity abuse, vendor impersonation, and manipulation that looks legitimate when it arrives.

That shift changes the governance question for IAM and security teams. Email protection now has to account for user identity, OAuth and delegated access, and post-delivery behaviour, because threats increasingly succeed after authentication and delivery rather than through obvious malicious attachment or link indicators.

Key questions

Q: How should security teams handle clean-text phishing that passes email authentication checks?

A: They should stop treating SPF, DKIM, and DMARC as proof of safety and instead correlate message delivery with identity and behaviour signals. Clean-text phishing often succeeds because the message itself is valid while the intent is malicious. The right control posture combines mailbox telemetry, user context, and post-delivery response rather than relying on perimeter inspection alone.

Q: When does a secure email gateway add less value than native cloud email security?

A: A SEG adds less value when Microsoft 365 or Google Workspace already covers commodity spam, malware, and basic phishing, and when the remaining threats depend on identity abuse or post-delivery manipulation. In that case, gateway overhead can outweigh security benefit. Teams should measure unique detections, not just inherited filtering coverage, before keeping the layer.

Q: What do security teams get wrong about vendor impersonation in email?

A: They often assume authenticated sender infrastructure means lower risk. In reality, vendor impersonation succeeds when attackers borrow legitimate mailboxes, reuse real workflows, and make the message look operationally normal. The failure is trust calibration, not just content filtering, so defenders need workflow-aware controls and tighter handling for third-party communication paths.

Q: What should organisations do before retiring a third-party secure email gateway?

A: They should run the replacement platform in parallel, validate detection coverage on live traffic, and compare how each control handles mailbox behaviour after delivery. That approach shows whether the gateway is still providing unique value or only duplicating what the native cloud stack already does. Consolidation should follow evidence, not assumption.

Technical breakdown

Why perimeter filtering misses clean-text email attacks

Secure email gateways make a risk decision when the message arrives. That works when the threat is a known attachment, a malicious URL, or a detectable signature. It fails when the email is plain text sent from legitimate infrastructure, passes SPF, DKIM, and DMARC, and uses real business context to trigger a human action. In that model, the gateway sees a valid message, but the risk emerges only after the recipient responds, forwards, or authorises something outside the email layer. The technical shift is from content inspection to identity and behaviour analysis across the whole workflow.

Practical implication: security teams need detection that follows the message after delivery, not just controls that judge it at the perimeter.

Why identity and OAuth abuse defeat gateway assumptions

Modern email attacks often start with compromised vendor mailboxes, abused OAuth consent, or other delegated access paths rather than an obviously malicious payload. Those paths are hard for a gateway to classify because the sending infrastructure is valid and the message content can be routine. Once a trusted identity is used, the email becomes a vehicle for business email compromise, vendor fraud, or credential harvesting. This is why cloud email security increasingly depends on API-level visibility into mailbox events, identity signals, and unusual communication patterns rather than static filtering rules alone.

Practical implication: connect email security to identity telemetry so you can spot trusted accounts behaving in untrusted ways.

How API-based cloud email security changes the control plane

API-based platforms do not sit in the mail flow and do not rely on first-pass classification. They read mailbox state, user behaviour, and post-delivery changes such as forwarding, deletion, or reply patterns. That lets them identify manipulation after the message lands, which is where many modern attacks actually succeed. In practice, this creates a different control plane: one oriented around continuous assessment, remediation, and context-aware response instead of quarantine-at-arrival decisions. For cloud-native estates, that architecture aligns better with how Microsoft 365 and Google Workspace operate than a third-party SEG does.

Practical implication: validate whether your email controls can see and act on mailbox behaviour after delivery, not just on inbound traffic.

NHI Mgmt Group analysis

Perimeter email filtering is no longer the primary control boundary for business email compromise. Clean-text attacks that pass SPF, DKIM, and DMARC expose a control model built for malicious payloads, not for identity abuse and social engineering. When a message looks authentic, the decisive failure is not detection of malware but the inability to evaluate trust at the point where a human or delegated identity acts. Practitioners should treat email security as an identity problem first and a content problem second.

The governance gap is duplicate control, not just weak control. Many organisations are paying for third-party gateway overhead while native cloud filtering already handles commodity spam, malware, and baseline phishing. That leaves allowlisting, false positives, and policy maintenance doing work that no longer matches the threat profile. The result is operational drag with declining marginal security value, which forces teams to re-evaluate where the control plane should actually live.

Vendor and supply chain impersonation now exploit familiar business workflows rather than technical compromise alone. That matters because the attack succeeds by abusing trust relationships that email security tools historically treated as low-risk if the sender authenticated correctly. The named concept here is identity-conditioned email trust erosion: a condition where legitimate sender validation no longer proves safe intent. The implication is that governance has to measure trust decay across identity, behaviour, and workflow context.

Cloud email security increasingly converges with IAM telemetry, because access signals now matter as much as message signals. OAuth abuse, compromised mailboxes, and cross-platform follow-on actions are not isolated email events; they are identity events with email as the delivery mechanism. Frameworks such as the NIST Cybersecurity Framework 2.0 and the NIST SP 800-63 Digital Identity Guidelines both reinforce the need to align protection, detection, and response to identity-driven risk. Practitioners should decide whether email is governed as a standalone channel or as part of the broader identity plane.

Retiring a third-party SEG is an architecture decision, not a rip-and-replace event. The article’s staged parallel-run approach reflects a more realistic transition model: validate coverage, compare detections, then simplify routing once confidence is proven. That pattern aligns with NHI governance discipline more than with traditional gateway thinking, because it treats control retirement as lifecycle management rather than a one-time tooling swap. Teams should use that mindset when deciding whether duplication is still buying them risk reduction.

From our research:

• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to The 2024 Non-Human Identity Security Report.
• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts.
• That gap makes it worth reviewing Ultimate Guide to NHIs as teams rework identity-centred controls across email, cloud, and delegated access paths.

What this signals

Identity-conditioned email trust erosion: once attackers can borrow legitimate infrastructure, sender validation stops being a reliable proxy for safe intent. Teams should expect the control conversation to move from inbound filtering to identity-aware detection, mailbox telemetry, and workflow context.

The operational signal is that many organisations are already paying for overlapping defences they cannot fully justify. As native cloud filtering absorbs commodity threats, the remaining question is whether the third-party layer still produces detections you can measure and act on faster than the native stack.

For identity programmes, the practical shift is to treat email as one expression of a broader trust plane. If vendor mailboxes, OAuth grants, and delegated access are not part of security governance, then email security is being managed too narrowly to match current attack paths.

For practitioners

• Map email security to identity signals Correlate mailbox events, OAuth consent, forwarding rule changes, and unusual sender behaviour so the control plane reflects how clean-text attacks actually progress. Treat identity telemetry as part of email defence, not a separate team’s problem.
• Measure gateway overlap against native cloud filtering Inventory which SEG functions are already handled by Microsoft 365 or Google Workspace, then quantify where the third-party layer adds unique detection value. Use that gap analysis to justify any licensing, tuning, or routing overhead.
• Run parallel validation before changing mail flow Deploy the replacement platform alongside the existing gateway, compare detections on real traffic, and only consolidate routing after coverage and remediation behaviour are proven. This reduces migration risk and exposes false assumptions early.
• Review vendor and third-party communication paths Create explicit handling for supplier mailboxes, delegated access, and externally originating requests that match normal workflows but carry higher trust risk. The goal is to stop treating authentic infrastructure as proof of safe intent.

Key takeaways

• Clean-text email attacks expose a structural weakness in perimeter-only security, because valid-looking messages can still be the starting point for compromise.
• Native cloud email filtering now covers much of the commodity threat surface, which makes gateway overlap and operational overhead harder to justify.
• The control shift is toward identity-aware, post-delivery detection that can follow sender trust, mailbox behaviour, and delegated access patterns.

Key terms

• Secure Email Gateway: A secure email gateway is a control layer that inspects email before delivery to block spam, phishing, malware, and policy violations. In cloud environments, its value declines when threats arrive as legitimate text from trusted infrastructure and the main risk appears after delivery, not at receipt.
• Business Email Compromise: Business email compromise is a fraud pattern where attackers impersonate or hijack trusted identities to induce payments, data sharing, or authorisation. It often succeeds without malware because the message content is plausible and the real attack is manipulation of trust, process, and delegation.
• OAuth Abuse: OAuth abuse occurs when an attacker gains or misuses delegated application access to act through a trusted identity or service. The risk is that the infrastructure looks legitimate while the permissions allow silent access to mailboxes, data, or downstream workflows.
• Identity-Centric Detection: Identity-centric detection uses user, account, mailbox, and behavioural signals to identify misuse that content filters miss. It is especially relevant when attacks are text-only, authenticated, and designed to look like normal business communication until the recipient acts.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Abnormal AI: The Essential Guide to Retiring the SEG. Read the original.