This question comes up in almost every engagement. The team has Defender, somebody has proposed Microsoft Sentinel, and nobody can explain in one sentence what the second one adds. Then the cost estimate arrives and the conversation stops.
The two are not competing products, and choosing between them on price is the wrong frame. They answer different questions.
What each one is for
Defender XDR correlates signals across the Microsoft estate. Identities, endpoints, email, cloud apps and Azure workloads feed a single investigation surface, and the correlation is done for you because Microsoft owns both ends of the signal. It is deep, opinionated, and it only knows about what Microsoft can see.
Microsoft Sentinel is a SIEM. It ingests whatever you send it, keeps it for as long as you pay to keep it, and lets you write detections and investigations across all of it. It is broad, unopinionated, and it knows about whatever you teach it.
So the real question is not which product. It is whether the things you need to see are inside the Microsoft boundary or outside it.
The cases where Defender XDR alone is enough
If the estate is genuinely Microsoft end to end, if the retention you need is short, and if nobody is asking you to correlate Microsoft signals with a firewall, a line of business application or an operational technology network, then Defender XDR on its own is a defensible answer. It is already licensed, the detections are maintained by Microsoft, and the correlation quality is high.
I have told organizations to stop there. Adding a SIEM they have nobody to run costs money and buys a dashboard.
The cases where you need Sentinel
Sentinel earns its place when at least one of these is true:
- You have meaningful sources outside the Microsoft estate that must be correlated with what is inside it
- Regulation or contract requires retention longer than the Defender portal keeps
- You need custom detections for your own applications and your own business logic
- You need to hunt across historical data, not just investigate current incidents
- You are running a SOC that needs one queue, one case model and one reporting line
That last one is underrated. The strongest argument for Sentinel is often operational rather than technical. A team that works in one place works better than a team that works in four.
The part that changed
Microsoft has been consolidating the experience so that Sentinel is reached through the Defender portal rather than as a separate destination. That matters for how a team works day to day, and it removes one of the older objections about context switching.
It does not change the underlying decision. You are still choosing how much to ingest, how long to keep it, and who is going to act on it. The portal is presentation. The commitment is data and staffing.
How I decide
I start from the incidents the organization actually needs to detect, written as sentences rather than as product names. Then I ask which signals would have to be in one place for each of those to be caught. If every one of those signals is Microsoft, the answer is Defender XDR. If a single sentence needs a non-Microsoft source next to a Microsoft one, that is the case for Sentinel, and it is worth building properly rather than half.
Then I look at ingestion, because that is where the cost lives. Most Sentinel bills I see are large because everything was sent by default, not because the organization decided to send it. Deciding what not to ingest is part of the design, and skipping that step is how a reasonable SIEM becomes an unreasonable invoice.
Get those two answers right and the product question answers itself.