Ran a head-to-head for monitoring SaaS apps (think O365, Salesforce, Box). The marketing says they're converging, but the implementation gaps are real. Sentinel loses if you just turn it on.
The core issue: Defender XDR (formerly Microsoft 365 Defender) has deep API hooks Sentinel can't match natively. Sentinel sees the processed alerts, not the raw telemetry. You're blind to the full kill chain.
Example: A compromised user session in O365.
* **Defender XDR** sees: Initial logon, anomalous PowerShell execution, mailbox forwarding rule added, exfiltration attempt. One incident.
* **Sentinel** sees (via the connector): Maybe one "Medium severity alert" from Defender. You miss the context.
To get parity, you must build it yourself. This means extra cost and complexity.
```kql
// Example: Trying to reconstruct a session in Sentinel
SecurityAlert
| where ProviderName contains "Microsoft 365 Defender"
| extend ExtendedProperties = parse_json(ExtendedProperties)
| where isnotempty(ExtendedProperties["AdditionalData"])
```
You're writing KQL to parse JSON blobs from another MS product. It's inefficient.
Pricing is the other trap. Ingesting all Defender raw data into Sentinel is prohibitively expensive for most. You're forced to choose between fidelity and cost.
Bottom line:
* For **Microsoft SaaS monitoring only**, Defender XDR's integrated detection is more complete and operationally simpler.
* Sentinel is your **SIEM** for cross-platform correlation (AWS, other clouds, on-prem). Use the "Microsoft 365 Defender" connector for **incident integration**, not as your primary data source.
* Do not assume Sentinel's Microsoft connectors give you full visibility. They don't. You are buying an aggregation and correlation layer, not the detection layer.
Least privilege is not a suggestion.
Interesting. I've always wondered about the "single pane of glass" promise for the Microsoft stack. So if you just use the standard connector, you're basically getting the condensed conclusions, not the raw evidence. That makes alert tuning and root cause a lot harder.
This feels like a data model problem. If Sentinel can't natively ingest the raw Defender telemetry tables, you're stuck playing catch-up. Is there any roadmap talk about them actually merging the backends, or will it always be a connector?
The pricing trap is real, too. Ingesting the raw logs for a large org seems like it could double the bill easily.
Your point about the processed alerts versus raw telemetry hits on the biggest hidden cost, I think: investigation time. If my team gets a condensed alert in Sentinel, they have to jump into Defender anyway to understand it. That's duplicated effort and breaks the workflow.
When you mention building parity yourself, that's where the real TCO spikes. Beyond the ingestion costs, you're paying for the security engineer's hours to write and maintain those KQL reconstructions. That's a recurring operational expense they don't show on the pricing sheet.
Is there a specific clause in the Defender or Sentinel licensing you've found that addresses this gap? I'm wondering if Microsoft considers this integrated behavior or if the docs quietly offload the integration work to the customer.
Trust but verify - especially the pricing page.
Exactly, and that inefficiency you're pointing out is where my team lives. We've ended up building a middle layer in Logic Apps just to parse and enrich those Defender alerts before they hit Sentinel. It's basically a custom connector they didn't provide.
We even had to pull in the Microsoft Graph Security API separately to fetch the raw telemetry Defender has, stitch it together, and then forward the unified data to Sentinel. Adds latency, but at least the analysts get the full story.
It feels like paying twice for the same data - once for the Defender portal view, and again for the engineering time to rebuild it elsewhere.
That Logic Apps middle layer is a perfect example of the operational tax this gap imposes. You've essentially built a data pipeline they advertise as pre-built.
> It feels like paying twice for the same data
That's the real kicker. You pay for the Defender seat/license for the telemetry, then pay for Sentinel ingestion (and the Logic Apps/API processing) to get a usable form of it. The cost isn't just double licensing, it's the platform services and labor to connect them.
I've seen similar workarounds using Azure Functions, but they all add the latency you mentioned. That delay can be critical for some live response scenarios. It's a trade-off between completeness and speed that shouldn't exist inside a single vendor's "integrated" stack.
CompareKing
This is exactly the kind of detail I was hoping to find. Thank you. The part about seeing just one "Medium severity alert" in Sentinel, while Defender has the full story, makes the connector feel a bit misleading.
I'm in the middle of evaluating these tools right now, and the pricing aspect you cut off at the end is my biggest worry. Everyone talks about license costs, but the engineering time to build those reconstructions seems like a permanent, hidden line item.
So when you say you have to build parity yourself, does that include setting up the data collection rules to pull the raw telemetry, or is that even possible with the standard license? I'm nervous about getting the contract signed and then finding out the real integration is an extra project.