TL;DR: 70% of its customers have fully moved away from secure email gateways, as legacy SEG controls continue to miss attack types that are increasing and Microsoft 365 expands native security capabilities, according to Abnormal AI. The shift shows email defence is now a control-design problem, not just a filtering problem.
At a glance
What this is: This on-demand webinar argues that legacy secure email gateways are being displaced by newer email security models because they miss increasingly common attack paths.
Why it matters: It matters because identity, access, and mailbox security teams need to understand where legacy email controls end and where modern detection, identity protection, and platform-native controls must take over.
By the numbers:
- 70% of Abnormal customers have fully moved away from their secure email gateways.
👉 Read Abnormal AI's webinar on the SEG migration and email security lessons
Context
Secure email gateways were built to filter malicious messages at the perimeter, but that model breaks down when attacks increasingly arrive through trusted identities, cloud mailboxes, and other channels that sit beyond simple URL-and-attachment inspection. For identity and access teams, the real issue is not email alone but the trust boundary around user accounts, mailbox access, and the downstream paths attackers use after the first click.
This webinar frames the SEG migration as a governance problem as much as a security one. When the native controls in Microsoft 365 expand and legacy controls miss more of the attack chain, practitioners have to decide which protections belong in the mail platform, which belong in identity controls, and which are no longer sufficient as stand-alone defenses.
Key questions
Q: How should security teams decide whether to keep a secure email gateway?
A: Treat the decision as a control-coverage exercise, not a brand preference. Keep a SEG only if it adds unique prevention or response value against the attack paths your native mail platform and identity controls do not already cover. If it mainly duplicates quarantine and filtering, it may be operationally expensive without materially improving resilience.
Q: Why do secure email gateways struggle with identity-linked attacks?
A: Because many modern email attacks are not obvious at delivery time. They rely on mailbox context, compromised accounts, trusted services, or post-delivery user interaction, which means content-based inspection alone cannot see the full chain. That makes the boundary between email security and identity security much more important.
Q: What signals show that email security should move beyond the gateway layer?
A: Look for repeated failures on impersonation, thread hijacking, malicious forwarding, and account compromise after delivery. If your incidents keep starting in email but ending in identity abuse, the gateway is no longer the right primary control surface. You need mailbox-native and behavioral controls as part of the stack.
Q: Who should own response when an email attack turns into account compromise?
A: Ownership should be shared, but accountability must be explicit. Messaging, identity, and endpoint teams each touch part of the problem, yet one function needs authority to coordinate containment, user recovery, and mailbox hardening. Without that, email incidents linger long after the initial malicious message is blocked.
Background and context
Why legacy secure email gateways miss modern attacks
A secure email gateway inspects messages before or as they enter the inbox, looking for malicious links, attachments, sender anomalies, and known signatures. That model works best when the threat is obvious at delivery time. It struggles when attackers use identity-aware tactics such as living off trusted cloud services, benign-looking threads, or payloads that only become malicious after delivery. In practice, the control is strongest at filtering known bad content and weakest when the threat depends on user context, mailbox state, or follow-on identity abuse.
Practical implication: evaluate email security against post-delivery and identity-linked attack paths, not only pre-delivery message filtering.
How Microsoft 365 native security changes the control stack
Native email security expands the control plane closer to the mailbox and identity itself, which changes the economics of relying on a separate gateway. When the platform already has richer telemetry, mailbox context, and policy enforcement, some SEG functions become redundant while others remain useful as layered detection. The architectural question is not whether a gateway can still filter mail, but whether it adds enough unique signal, response speed, and governance value to justify separate operational overhead.
Practical implication: map each SEG function to an equivalent or better native control before deciding whether the gateway still earns its place.
Behavioral detection versus gateway filtering
Behavioral email security shifts the emphasis from static content inspection to patterns of sender behavior, mailbox interactions, and user compromise indicators. This is a different control philosophy from the SEG model. Instead of asking whether the message looks bad, it asks whether the communication fits known malicious behavior over time. That matters because many current attacks use legitimate infrastructure, compromised accounts, or conversation hijacking that do not trigger simple content-based rules.
Practical implication: add behavioral detections where the control must see identity misuse, not just malicious content.
NHI Mgmt Group analysis
Legacy email gateways are a shrinking control boundary, not a complete defence layer. The article’s core claim is not that email security is obsolete, but that the point of enforcement has moved. Once attacks depend on identity context, mailbox state, or trusted cloud services, a gateway’s pre-delivery inspection no longer captures the full risk. Practitioners should treat SEG coverage as one layer in a broader identity-aware email defence model.
Mailbox compromise is increasingly an identity problem, not a content problem. The valuable insight here is that email attacks now often succeed by abusing the trust relationship around the account, not by defeating signature-based message checks alone. That makes mailbox access, session control, and downstream privilege the real governance surface. Security teams should stop measuring email defence only by message-block rates and start measuring how far an attacker can move after delivery.
Native platform controls change the economics of SEG dependency. Microsoft 365’s expanded capabilities matter because they shift detection closer to the identity and mailbox layer where the threat now lives. That does not eliminate the need for layered control, but it does force a harder question: what unique risk does a separate SEG still reduce that the platform does not already address? Practitioners should use that answer to justify, shrink, or retire legacy gateways.
Identity and email governance now overlap enough that ownership has to be explicit. Email security decisions can no longer sit only with messaging teams if the attack path ends in account takeover, token abuse, or persistence in collaboration tools. The control gap is often organizational as much as technical: no one owns the full chain from delivery to compromised identity to business impact. Practitioners should assign accountability across mail, identity, and endpoint domains together.
From our research:
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to The State of Secrets in AppSec.
- Organisations maintain an average of 6 distinct secrets manager instances, which fragments governance and weakens centralized control.
- For a broader NHI lens, see Ultimate Guide to NHIs , Key Challenges and Risks for the governance conditions that let control gaps persist.
What this signals
Segmentation in email security is moving from perimeter filtering to identity-aware governance. The practical signal for practitioners is that email defence now has to account for mailbox access, session abuse, and user behaviour, not just message reputation. Teams that still measure success by blocked phish counts will miss the real issue, which is how far an attacker can progress after a message reaches the inbox.
With 43% of security professionals already concerned about AI systems learning and reproducing sensitive information patterns from codebases, the broader trend is clear: trust boundaries are collapsing across email, identity, and content generation. That makes platform-native controls and behavioural detection more relevant to the operating model than standalone gateways.
Practitioners should use the migration away from SEG tooling to revisit ownership across mail security, identity response, and user protection. Where one team owns the gateway and another owns the account, attackers inherit the seams. The programme signal is not simply tool consolidation, but the need to align control ownership with the real attack chain.
For practitioners
- Map SEG coverage to real attack paths Test whether your current gateway catches credential harvesting, thread hijacking, and trusted-service abuse, not just malicious attachments and links. Score failures by the point in the chain where the message becomes dangerous.
- Compare native mailbox controls against gateway functions Inventory what Microsoft 365 already enforces for quarantine, detonation, impersonation detection, and post-delivery response, then remove duplicate SEG functions where the platform provides equivalent control.
- Add behavioral detections to email governance Prioritise anomalies such as unusual forwarding, impossible travel linked to mailbox access, and conversation takeover patterns that content filters do not reliably catch.
- Define ownership across mail and identity teams Set a named owner for the end-to-end chain from message delivery to identity compromise, including triage, containment, and mailbox recovery when an email attack becomes an access incident.
Key takeaways
- Legacy secure email gateways are no longer sufficient as the sole control layer when attacks depend on identity context and post-delivery abuse.
- The migration away from SEG tooling reflects a broader shift toward mailbox-native, behavioral, and identity-aware defence models.
- Practitioners should measure email security by how far an attacker can progress after delivery, not only by how many messages are blocked.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | SEG migration affects how access and mailbox trust are enforced. |
| NIST Zero Trust (SP 800-207) | The article shifts email defence toward continuous trust validation. | |
| NIST SP 800-63 | Account compromise and session abuse connect directly to digital identity assurance. |
Strengthen authentication and recovery paths where email attacks become identity incidents.
Key terms
- Secure Email Gateway: A secure email gateway is a control that inspects inbound and outbound email for malicious content, suspicious links, and policy violations before messages reach users. It is strongest at filtering known bad patterns, but it is weaker when attacks depend on trusted accounts, mailbox context, or post-delivery interaction.
- Mailbox Compromise: Mailbox compromise is the takeover or misuse of an email account so an attacker can read, send, forward, or manipulate messages as a legitimate user. In practice, it turns email into an identity abuse path, because the account itself becomes the trusted surface the attacker controls.
- Behavioral Email Detection: Behavioral email detection uses patterns of sender activity, message relationships, and account behaviour to identify suspicious communication that content scanning may miss. It focuses on how an attack behaves over time, which makes it useful against impersonation, thread hijacking, and compromised-account activity.
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 Great SEG Migration: Lessons Learned from Replacing 100 SEGs. Read the original.
Published by the NHIMG editorial team on 2026-06-26.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org