Is M365 Security All It's Hyped Up to Be?

Microsoft would like you to believe that an E5 licence is a security strategy.

Defender XDR. Sentinel. Entra ID Protection. Purview. Auto attack disruption. On paper, it’s the most integrated security ecosystem on the market — and on paper, they’re not wrong.

But I’ve spent years operating M365 security in production environments, running incident response through its tools, and building custom detections where the defaults fall short.

The reality is more nuanced than the marketing deck.

If you’re making security decisions based on what Microsoft says E5 does rather than what it actually does in practice, you’ve got gaps you don’t know about.

Where It Delivers

Credit where it’s due. Dismissing M365 security outright is as wrong as accepting the marketing uncritically.

Defender for Endpoint

Automated investigation and remediation is best-in-class when configured properly. An alert fires, Defender investigates the process tree, correlates related alerts, and in many cases remediates autonomously — isolating files, killing processes, quarantining threats — without an analyst touching it.

For organisations that have tuned their automation levels, this reduces analyst workload on commodity threats significantly.

Sentinel’s KQL Engine

The most flexible detection authoring platform available at this price point.

KQL is powerful, readable, and expressive enough to build detection logic ranging from simple threshold alerts to complex behavioural baselines. No other SIEM at this tier gives you that level of control over your detection logic.

Conditional Access

More granular than most organisations will ever need. Device compliance, location, risk level, application, authentication context, session controls — you can build access policies that adapt in real-time to the risk profile of each authentication attempt.

The problem is never “can Conditional Access do this?” It’s “has anyone actually configured it beyond the basics?”

Automatic Attack Disruption

This one deserves special mention.

Defender detects an active attack, correlates signals across email, identity, and endpoint, and automatically contains the compromised user or device mid-attack. This capability didn’t exist two years ago and it materially changes containment speed for attacks that match its detection patterns.

Where It Falls Short

This is the section Microsoft won’t write. It’s also the section that matters most.

The Detection Coverage Gap

Sentinel ships with over 200 analytics rule templates. Sounds comprehensive — until you look at what they actually cover.

The defaults cluster around well-known, high-volume techniques: brute force, impossible travel, known malware hashes, basic anomaly detection.

What’s missing is more telling.

The default rules cover commodity attacks well. But mailbox rule abuse, OAuth consent phishing, cross-tenant lateral movement, data staging, and Entra ID privilege escalation? Minimal to zero out-of-the-box coverage.

Then there’s the noise problem.

Enable all the default rules and your SOC drowns in false positives within a week. The “impossible travel” rule alone generates dozens of alerts from mobile networks, VPN split tunnels, and legitimate travel.

Most teams either tune it badly or disable it entirely. Neither is acceptable.

Custom detection engineering isn’t optional in Sentinel. It’s the entire point of the platform. If you’re running default rules and calling it done, you’ve bought a professional-grade kitchen and stocked it with microwave meals.

The Licensing Trap

M365 security capabilities vary dramatically between licence tiers. Microsoft doesn’t go out of its way to make this obvious.

These aren’t incremental differences. They’re fundamentally different security postures.

An E3 environment lacks risk-based Conditional Access, has no automated investigation in Defender for Endpoint, can’t monitor OAuth apps through Cloud App Security, and doesn’t get the identity protection signals that make Entra ID genuinely useful as a security tool.

The add-on SKU structure makes it worse — individual features purchased separately create a patchwork of capabilities that’s difficult to audit and easy to misconfigure.

First question when assessing M365 security posture: not “what tools do we have?” but “what licence are we actually on, and what’s excluded?”

The Fragmented Admin Experience

Microsoft markets M365 security as integrated. Operationally, it’s distributed across at least five admin portals.

A single investigation can require jumping between three or four of them. There is no single pane of glass despite years of Microsoft promising convergence.

This isn’t just inconvenient — it creates operational blind spots.

Settings in one portal can conflict with or override settings in another. A transport rule in Exchange can bypass a DLP policy in Purview. A Conditional Access exclusion in Entra can undermine a compliance policy in Intune.

Without deliberate cross-portal governance, inconsistencies accumulate silently.

Incident Response Limitations

Defender XDR’s incident correlation is good for straightforward attack chains — linking a phishing email to a compromised identity to endpoint activity.

Where it breaks down: complex, multi-stage attacks.

An attacker who moves from email compromise to identity abuse to SharePoint data staging to cloud app pivot will generate alerts across workloads that sometimes get correlated into a single incident — and sometimes don’t.

When they don’t, you’re manually hunting across CloudAppEvents, EmailEvents, IdentityLogonEvents, and DeviceProcessEvents, stitching the kill chain together yourself.

Auto attack disruption has the same limitation. Excellent when the attack matches a known pattern. Silent when it doesn’t — and sophisticated attackers deliberately operate outside known patterns.

The tooling supports incident response. It doesn’t automate it. If your IR plan assumes Defender XDR will handle complex attacks without human intervention, you’re going to learn that lesson during an incident — the worst possible time.

The Secure Score Illusion

Secure Score is presented as a measure of your security posture. In practice, it measures how many Microsoft-recommended configurations you’ve enabled.

These are very different things.

The score rewards breadth of configuration. Security requires depth of operational capability.

Secure Score is a useful checklist for baseline hygiene. It is not a measure of security maturity, and it should never be reported to leadership as one.

Five Questions That Tell You Where You Actually Stand

Before reading the verdict, answer these honestly. They take 60 seconds and they’re worth more than your Secure Score.

1. How many of your Sentinel analytics rules did your team write vs enable from templates? If the answer is “mostly templates” — you’re running detection on autopilot. The defaults miss the attacks that matter most in your environment.

2. Can you name three M365 attack techniques your current detection rules do NOT cover? If you can’t — you haven’t mapped your coverage against ATT&CK. You have blind spots you don’t know about.

3. When was the last time an analyst investigated a Sentinel alert and found a true positive? If it’s been weeks — your signal-to-noise ratio is broken. You’re generating alerts nobody trusts.

4. Do you know which security features your licence tier excludes? If you’re not certain — check before your next renewal. The gap between E3 and E5 is not incremental, it’s structural.

5. If an attacker compromised a mailbox right now, how many portals would your analyst need to open to investigate it? If the answer is more than two — your investigation workflow has friction that costs you time during incidents.

Score yourself: 4–5 confident answers = you’re operating the platform well. 2–3 = you have known gaps to close. 0–1 = the marketing deck is doing more work than your security operations.

The Verdict

M365 security is the best integrated platform available for organisations in the Microsoft ecosystem.

That statement is true. And it’s not enough.

The tooling is genuinely powerful. Sentinel’s detection engine, Defender XDR’s correlation, Entra ID’s access controls, automatic disruption — these represent a real step change from where the industry was five years ago.

But “operating properly” is doing a lot of work in that sentence.

It means custom detection engineering, not default rules. Understanding your licence tier’s actual gaps. Cross-portal configuration governance. Manual hunting skills for the incidents automation can’t handle. Treating Secure Score as a starting point, not a destination.

Microsoft has built a sports car. Most organisations are driving it in first gear with the parking brake on.

The tooling isn’t the problem.

The assumption that tooling equals security is.

Next post: the KQL queries that tell you whether your Sentinel deployment is actually detecting anything — or just running rules against empty tables.

We publish weekly on making security work in practice. If that’s useful, subscribe below.