Microsoft 365 and legacy SEG overlap leaves advanced email gaps

At a glance

What this is: This analysis argues that legacy SEGs layered on Microsoft 365 often add overlap rather than independent protection, leaving identity-based and text-only email attacks exposed.

Why it matters: IAM and security teams need to distinguish baseline mail hygiene from behavioural detection, because account takeover, vendor fraud, and BEC can bypass controls that only inspect known indicators.

By the numbers:

• Abnormal customers see an average of 462 advanced attacks per month bypassing Microsoft native controls per 1,000 mailboxes.
• 76% of Abnormal customers now run without a third-party SEG.
• 800+ organisations have migrated over 3.5 million mailboxes to the native+AI model.

Context

Microsoft 365 email security works best when organisations understand which threats are already covered natively and which require a different detection model. The problem in this article is not email filtering in general, but the governance gap created when a legacy SEG remains in place as if it still adds a distinct security layer.

That overlap matters because many teams disable parts of Microsoft’s native stack while preserving older inspection logic that was built for spam, malware, and known bad indicators. The result is often duplicated baseline protection, higher cost, and a false sense of defence in depth against identity-based and context-heavy attacks.

For IAM and security practitioners, the question is whether the email stack is detecting known malicious payloads or interpreting behaviour, intent, and communication context. The article’s core claim is that modern email risk now sits at that boundary, not in simple mail hygiene.

Key questions

Q: Where do legacy SEGs fail when Microsoft 365 already handles baseline email protection?

A: They fail when the threat is clean, contextual, and identity-driven rather than malware-driven. If the gateway is built to spot known bad indicators, it will struggle with BEC, vendor fraud, and account takeover that reuse legitimate language, valid accounts, and trusted workflows.

Q: Why do duplicated email controls not always improve defence in depth?

A: Because defence in depth depends on independent coverage, not two tools inspecting the same signals. If both controls are tuned for spam, malware, and known threat indicators, the organisation gains redundancy and cost, but little extra protection against modern social engineering.

Q: How can security teams tell whether their SEG is still adding value in Microsoft 365?

A: Check whether it catches threat classes that Microsoft’s native controls do not already cover, especially behavioural attacks that have no malicious payload. If the SEG mainly duplicates baseline filtering, it is probably compensating for a perceived gap rather than a real one.

Q: What should organisations do when email attacks are becoming more identity-based?

A: Move some of the detection burden from static message inspection to behavioural analysis across senders, recipients, vendors, and workflows. That makes it easier to identify abuse that looks technically clean but is operationally suspicious.

Technical breakdown

Why legacy SEGs miss text-only attacks

Legacy secure email gateways were designed around known bad indicators: signatures, sandboxes, URL reputation, and attachment analysis. That model works reasonably well against commodity malware and bulk phishing, but it weakens when the message is clean, personalised, and socially engineered. Business email compromise, vendor fraud, and account takeover often look legitimate at the technical layer because the abuse sits in the wording, the workflow reference, or the relationship context, not in a malicious file or link. Once that happens, inspection-based controls lose much of their value because they are looking for artefacts the attacker no longer needs to provide.

Practical implication: evaluate whether your mail controls can detect intent and context, not just payloads.

What defense in depth means for Microsoft 365 email

Defense in depth is only real when layers are independent. If Microsoft 365 and a legacy SEG both inspect the same signals in the same way, the organisation gains redundancy, not additional coverage. Microsoft handles foundational protection for spam, malware, and other known threat techniques, while a behavioural layer looks for anomalies in sender behaviour, vendor relationships, device patterns, and internal communication drift. That distinction matters because the point is not more inspection. It is different inspection logic, so one layer can catch what the other is structurally blind to.

Practical implication: map each layer to a distinct detection function before deciding both are necessary.

How behavioural AI changes email threat coverage

Behavioural AI shifts detection from content-only review to baseline deviation analysis across employees, partners, and devices. That matters for attacks that arrive through trusted accounts, legitimate platforms, and business-realistic wording. In identity terms, the security problem is not simply that a message is malicious. It is that the sender, recipient relationship, and transaction pattern may all appear valid. Behavioural models can flag that mismatch, which is why they are better suited to low-volume, high-impact attacks than static inspection pipelines. This is especially relevant where the attack path depends on human trust rather than executable malware.

Practical implication: use behavioural detections to complement, not duplicate, native mail hygiene and perimeter inspection.

Breaches seen in the wild

• Gitloker GitHub extortion campaign: Phishing via GitHub notifications tricked developers into authorising malicious OAuth apps; Gitloker then wiped repos and demanded contact.
• Meta AI Instagram Account Takeover: 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

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

Legacy SEG overlap is a control architecture problem, not an email volume problem. The article describes a common failure mode where organisations keep two tools that are both optimised for known threats and then assume they have created stronger defence in depth. In practice, that produces redundancy around baseline filtering while leaving the highest-value attacks under-covered. The implication for practitioners is that overlap must be judged by detection logic, not by the number of products in the stack.

Text-only social engineering is now a governance issue for identity teams. BEC, vendor fraud, and account takeover do not need malware to succeed when they can borrow legitimate context and valid relationships. That shifts the control question from message inspection to trust interpretation across users, vendors, and workflows. The implication is that email defence has become part of identity governance, because the abuse path is often the relationship itself.

Behavioral context is the named concept that separates independent coverage from duplicate inspection. Microsoft 365 can cover foundational mail hygiene, but behavioural context identifies when a technically clean message is operationally suspicious. That distinction should shape how teams evaluate email security vendors, especially where legacy SEGs force routing patterns that weaken the native stack. The implication is that practitioners should measure whether a layer adds new detection semantics, not just another dashboard.

The economics of email security now favour eliminating duplicated controls. The article’s cited operating experience suggests that organisations can reduce manual triage and still improve coverage when they remove the second layer that only rechecks the same signals. That does not mean every SEG is obsolete in every environment, but it does mean the burden of proof has shifted. The implication for security leaders is to justify every overlapping layer against a specific detection gap.

Identity-based email attacks expose the limits of signature-driven governance assumptions. The assumption that a risky message will look risky in a technical sense was designed for a different era of email abuse. That assumption fails when attackers use legitimate accounts, trusted platforms, and contextually correct language. The implication is that email governance now needs a control model built around behavioural deviation and business context, not just malicious content identification.

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.

What this signals

Behavioral context is now the differentiator in email security. Teams that still evaluate email controls by spam catch rates or payload inspection are measuring an older threat model. The practical shift is toward detecting abnormal relationships, workflow references, and sender behaviour that signal abuse even when the message is technically clean.

Legacy SEG overlap should be treated as an architecture decision, not a comfort blanket. If Microsoft 365 already covers the baseline threat layer, the remaining question is whether the third-party SEG adds distinct detection semantics or only duplicates an existing control path. Security leaders should be prepared to remove tools that increase complexity without improving coverage.

Identity teams should treat email abuse as part of trust governance. Vendor impersonation and account takeover succeed because organisations trust the communication context, not because the message contains obvious malware. That makes mail security a governance issue for identities, relationships, and business workflows, not just a filtering problem.

For practitioners

• Map detection logic by threat class Separate baseline hygiene controls for spam, malware, and known payloads from behaviour-based detections for BEC, vendor fraud, and account takeover. If both products are covering the same message signals, the stack is redundant rather than layered.
• Review SEG dependence on Microsoft 365 routing Check whether the legacy SEG forces mail flow around native Microsoft protections or disables parts of the Microsoft stack. That routing pattern often weakens the native layer before it adds any distinct capability.
• Measure false-positive and triage burden Compare manual review volume, alert quality, and response time before and after SEG overlap. A duplicated control should reduce risk without creating a second queue of low-value alerts.
• Prioritise behavioural detections for identity-based mail abuse Tune controls to flag suspicious relationships, vendor impersonation patterns, and abnormal communication context where no payload exists to inspect. This is where legacy inspection models are weakest.
• Reassess third-party SEG value against native coverage Document which threats the SEG catches that Microsoft 365 does not already cover, then retire overlap that adds cost without changing the attack surface.

Key takeaways

• Legacy SEG overlap in Microsoft 365 often creates duplicated baseline controls rather than independent defence in depth.
• Advanced email attacks such as BEC, vendor fraud, and account takeover exploit context and trust, which static inspection models miss.
• The strongest improvement is usually to add behavioural detection where native mail hygiene ends, not to stack more of the same filtering logic.

Key terms

• Behavioural email detection: A detection approach that looks for patterns in sender behaviour, message timing, language change, and downstream user interaction rather than relying only on signatures. It is designed to catch attacks that mutate quickly. For identity programmes, its value is in finding the moment an email becomes an access risk.
• Defense in depth: Defense in depth is the practice of stacking independent controls so one failed check does not expose the whole system. In App Router authentication, that means verifying identity in middleware, route handlers, and data access logic, because each layer protects a different part of the request path.
• 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.

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.