Defender XDR and Sentinel: what to collect, and what to ignore

The most common question I am asked about these two products is whether an organisation needs both. The answer depends on what is outside the Microsoft estate, and the reasoning is worth setting out, because the wrong answer is expensive in one direction and blind in the other.

The problem: overlapping scope, different jobs

Microsoft Defender XDR is a detection and response product across the Microsoft estate: endpoints, identities, email and collaboration, cloud applications and cloud workloads. It provides its own telemetry, its own detections, correlation of related signals into incidents, and automated response — all without you designing a data pipeline.

Microsoft Sentinel is a security information and event management platform. It ingests from anywhere, you write the analytics, and you pay by data volume. Its value is breadth and correlation across sources Defender does not see.

The clearest way to hold the distinction: Defender XDR gives you detections you did not have to write, across sources you did not have to connect. Sentinel gives you the ability to connect and correlate anything, at a cost proportional to volume.

Microsoft has been consolidating the experience so that Sentinel and Defender XDR are used together in a single portal, which makes the products feel closer than their commercial models are. Check the current state of that integration when you plan, because it has moved repeatedly.

The decision

Defender XDR alone is sufficient when the estate is essentially all Microsoft — Windows endpoints, Entra ID, Microsoft 365, Azure — you have no regulatory requirement for long retention of arbitrary logs, and there is no significant non-Microsoft security telemetry that needs correlating. A surprising number of mid-sized organisations are in this position and are paying for a Sentinel workspace that adds little.

Add Sentinel when you have meaningful non-Microsoft sources — firewalls, network devices, third-party identity providers, line-of-business applications, operational technology — or a retention obligation that exceeds what Defender XDR holds, or a genuine need for custom correlation across sources.

The mistake to avoid is deploying Sentinel and connecting everything because it is possible. Ingestion is the cost, and a workspace collecting verbose telemetry nobody queries is a recurring bill for data with no consumer.

Exposure: what to collect, in priority order

Turn on the Defender products properly first

Before ingesting anything, get the native products configured. This is free capability that organisations routinely under-use:

• Defender for Endpoint on every endpoint and server, in active rather than passive mode where possible. Its process telemetry is also what lets you avoid duplicating verbose process logging into a SIEM, as discussed in Windows event logs worth forwarding.
• Defender for Office 365 for email and collaboration.
• Defender for Identity on domain controllers. This is the one most often missing, and it is the product that detects the Active Directory attacks — delegation abuse, reconnaissance, credential theft patterns — that nothing else in the stack sees.
• Defender for Cloud Apps for the application and session layer.
• Defender for Cloud for Azure resource posture and workload protection.

Each produces detections without you writing anything.

Then connect to Sentinel, in this order

First, the free or low-cost high-value connectors. Entra ID sign-in and audit logs, Office 365 activity, Defender XDR alerts and incidents. Microsoft has historically provided certain data sources without ingestion charge for qualifying licences — check what applies to you, because it materially changes the economics.

Second, the sources Defender does not see. Firewalls, VPN concentrators, network devices, third-party identity and email security products, and any line-of-business application that matters. This is Sentinel’s actual purpose.

Third, selectively, raw Windows events. The narrow list in the event log article, filtered at the source, tiered so domain controllers are verbose and ordinary workstations are not.

What to be cautious about: full endpoint process telemetry duplicated from Defender for Endpoint, verbose informational logs from every system, and anything you cannot name a detection or an investigation use for.

Use the ingestion tiers deliberately

Log platforms now offer tiers below the standard analytics tier for high-volume data that is searched occasionally rather than alerted on continuously. Verbose network and process data is the natural candidate: you keep it for investigation, you do not pay analytics rates for it, and you accept reduced query performance and feature support.

Getting this tiering right is usually a larger cost lever than any decision about which connectors to enable.

Hardening: making the detections useful

Start with the built-in analytics rules and templates. Do not write custom rules until the supplied ones are tuned. Most organisations have more value available in tuning than in authoring.

Tune aggressively. An analytics rule producing ten false positives a day trains the team to close incidents without reading them, which is worse than not having the rule. Either tune it so the rate is manageable, or disable it and be honest about that.

Alert on the things that should never happen. These are the highest-quality detections and they need no tuning:

• A sign-in by an emergency access account, as covered in emergency access accounts.
• The security audit log being cleared.
• A change to the Conditional Access baseline or its exclusion groups.
• A new application permission grant, per application consent.
• A new member of a highly privileged directory group.

Enable user and entity behaviour analytics if licensed, and use watchlists to mark your Tier 0 accounts and systems so that activity involving them is prioritised.

Detection and response ownership

The part that gets least attention and matters most: who receives an incident, out of hours, and what are they authorised to do?

A detection that reaches nobody is not a detection. Before expanding collection, establish:

• Which incidents page a human, and which wait for the morning.
• Who is on call, and how the incident reaches them.
• What they may do without further approval — isolate a device, disable an account, revoke sessions. Automated response is valuable exactly because it acts before a human can, and it needs authorisation agreed in advance.
• What the escalation path is when it is genuinely serious.

Automated investigation and response in Defender XDR, and playbooks in Sentinel, are how the routine cases get handled without waking anyone. Configure them deliberately, starting with low-risk actions, and review what they did.

Validation

• Generate a test detection and confirm it becomes an incident, reaches the right person, and arrives within an acceptable time. Use a controlled, approved test, and repeat it periodically.
• Check connector health on a schedule. Connectors stop silently, and a source that stopped reporting three months ago is a gap nobody noticed.
• Confirm coverage: which endpoints are actually onboarded to Defender for Endpoint? The answer is never all of them, and the missing ones are where the problem will be.
• Review ingestion by source monthly against what it is producing in detections. A source costing a lot and generating nothing is a candidate for a cheaper tier or removal.
• Run a tabletop exercise. The question is not whether the alert fires; it is whether the organisation responds usefully when it does.

Honest limits

These products detect and respond. They do not prevent, and an organisation with excellent detection and poor identity hygiene is detecting attacks that better configuration would have made impossible. The preventive work in the rest of this series — tiering, Conditional Access, credential protection, attack surface reduction — is what reduces the number of incidents. Detection is what catches the ones that get through.

They also do not provide an analyst. A Sentinel workspace with excellent rules and nobody reading the incidents is an expensive log archive, and that is a more common outcome than anyone likes to admit.

Verification and limits

The scope distinction between Defender XDR and Microsoft Sentinel, the Defender product family, Sentinel’s ingestion-based commercial model, the existence of lower-cost ingestion tiers, and the ongoing portal consolidation were checked against current Microsoft documentation on 20 September 2026. The collection priorities, the decision framework and the ownership questions are my own practice.

Nothing here was deployed for this article. Enabling connectors incurs ingestion cost immediately and at a rate proportional to volume — enable incrementally, measure, and confirm current pricing, free-data entitlements and tier behaviour before committing to a design. Portal integration and connector behaviour in this area change frequently.

References

• What is Microsoft Defender XDR?
• What is Microsoft Sentinel?
• Microsoft Sentinel data connectors
• Plan costs and understand Microsoft Sentinel pricing and billing