Only if the legacy control still reduces abuse without forcing blunt policy tradeoffs. If it cannot inspect post-delivery risk, cannot handle trusted-app phishing well, and keeps creating operational drag, then it is not protecting the business efficiently. Modernisation should be judged by fit, continuity, and measurable reduction in incident workload.
Why This Matters for Security Teams
The question is not whether email security still matters after moving to Microsoft 365. It does. The real issue is whether a legacy Secure Email Gateway still reduces meaningful risk, or whether it only adds another layer that duplicates native controls, slows response, and creates blind spots after delivery. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it frames security as a control objective, not a product category.
Security teams often assume a SEG is either fully required or fully obsolete. That is too simplistic. Microsoft 365 can provide strong filtering, authentication, and investigation workflows, but those capabilities do not automatically eliminate the need for third-party inspection if the organisation has specific threat exposure, regulatory constraints, or historically weak mailbox abuse patterns. The decision should be based on control coverage, not inertia.
The operational risk is that duplicated email controls can produce alert fatigue, mail flow exceptions, and inconsistent policy enforcement across cloud and on-premises paths. In practice, many security teams encounter the real limits of their SEG only after trusted-app phishing, token theft, or post-delivery link abuse has already created business impact, rather than through intentional control validation.
How It Works in Practice
A sensible evaluation starts by mapping what the SEG actually does that Microsoft 365 does not already do well. That usually includes URL rewriting, attachment sandboxing, impersonation protection, inbound reputation filtering, outbound data loss controls, and some level of message trace or quarantine workflow. The question is whether those functions are still adding distinct value, or whether they are simply restating what Exchange Online Protection and Microsoft Defender for Office 365 already cover.
Current guidance suggests testing controls against real attack paths instead of feature lists. For example, a strong email security posture should account for credential theft, malicious OAuth consent, BEC-style social engineering, and post-delivery compromise. MITRE’s MITRE ATT&CK is useful for connecting email ingress to downstream techniques such as valid account abuse and phishing. If the SEG cannot materially improve detection, containment, or response for those paths, it is difficult to justify its complexity.
Operationally, teams should compare the legacy SEG and Microsoft 365 across a few practical questions:
- Does the SEG inspect content after delivery, or only at the perimeter?
- Can it handle trusted-app phishing, URL detonation limits, and impersonation variants without excessive false positives?
- Does it integrate cleanly with SIEM, SOAR, and incident response workflows?
- Does it create mail routing exceptions that weaken availability or user trust?
For governance, CISA email security guidance is a useful reminder that layered defenses must be validated against abuse cases, not just deployed as policy defaults. These controls tend to break down when mail flows are highly hybrid, because routing complexity makes it difficult to prove which platform actually inspected the message and which one merely forwarded it.
Common Variations and Edge Cases
Tighter email filtering often increases operational overhead, requiring organisations to balance protection against delivery friction and support burden. That tradeoff matters most in regulated environments, merger integrations, and businesses with large external collaboration footprints. Best practice is evolving here, and there is no universal standard that says every legacy SEG should be removed the moment Microsoft 365 is adopted.
Some organisations keep a SEG for outbound inspection, advanced DLP, or specialised compliance workflows. Others retain it temporarily during migration because it still handles legacy journaling, encryption, or transport routing that has not yet been rebuilt natively. In those cases, the SEG should be treated as a transitional control with a defined retirement or revalidation plan, not as permanent architecture by default.
There is also an identity bridge worth calling out. Microsoft 365 email abuse often becomes an identity problem as soon as attackers harvest credentials, hijack sessions, or abuse privileged mailboxes. Where that happens, the right question is not only whether the SEG works, but whether the environment has enough identity telemetry, MFA strength, and privilege governance to stop abuse after the first click. That is where NHI and IAM controls start to matter alongside email security.
In short, keep the legacy SEG only when it demonstrably closes a gap that Microsoft 365 does not already close, and retire it when it mainly adds routing complexity, duplicated cost, or policy conflict. The clearest signal is whether it measurably reduces incident workload without weakening user productivity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.PT | Email security tools are part of protective technology and control architecture. |
| NIST AI RMF | Security tooling decisions should be governed by measurable risk and lifecycle oversight. | |
| MITRE ATT&CK | T1566 | Phishing is the core attack path that email controls must detect and disrupt. |
Establish governance to evaluate whether the control still reduces risk and operational burden.
Related resources from NHI Mgmt Group
- How should security teams decide whether to keep a legacy SEG with Microsoft 365?
- Should organisations keep classic PAM if they are moving to dynamic access controls?
- How can organisations tell whether Microsoft 365 controls are actually working?
- How should teams decide which email security controls to keep when Microsoft and an SEG overlap?
