Running Microsoft Defender XDR and Microsoft Sentinel side by side gives your SOC two powerful tools. Running them as two separate queues gives analysts two places to miss something.
The better model is a unified SecOps experience: Defender XDR correlates alerts across endpoint, identity, email, SaaS apps, and cloud workloads, while Microsoft Sentinel adds SIEM coverage, long-term retention, multicloud data, custom detections, and SOAR. Microsoft documents this integration as a way to bring Defender XDR incidents, alerts, entities, and advanced hunting events into Sentinel, with incident synchronization between portals when you use the connector (Microsoft Defender XDR integration with Microsoft Sentinel).
In this guide, you’ll configure the integration the practical way: choose the Defender portal as the primary incident experience, connect Defender XDR data to Sentinel, stream Microsoft Defender for Endpoint raw events into Sentinel tables, and build detections and playbooks that work across products.
Prerequisites
Before you start clicking buttons, make sure you have the right access and licenses. Microsoft lists the core requirements for manually configuring the Defender XDR connector in the Azure portal as a valid Microsoft Defender XDR license, Security Administrator or equivalent tenant permissions, read/write permissions on the Microsoft Sentinel workspace, and membership in the same Microsoft Entra tenant as the workspace (Stream data from Microsoft Defender XDR to Microsoft Sentinel).
You’ll also need:
-
A Microsoft Sentinel workspace.
-
Microsoft Defender XDR turned on for the tenant.
-
Microsoft Defender for Endpoint onboarded if you plan to stream endpoint advanced hunting events.
-
Permission to install Content hub solutions in Microsoft Sentinel.
-
Permission to create analytics rules, automation rules, and playbooks.
One important planning note: Microsoft says Microsoft Sentinel in the Azure portal will no longer be supported after March 31, 2027, and customers will be redirected to Microsoft Sentinel in the Microsoft Defender portal (Microsoft Sentinel in the Microsoft Defender portal). If you’re designing a new operating model today, use the Defender portal as the default analyst experience unless you have a hard reason not to.
Step 1: Pick Your Integration Model
There are two ways to think about this integration.
The first model is the modern unified portal approach. You onboard Microsoft Sentinel to the Microsoft Defender portal and work incidents, alerts, hunting, and Sentinel configuration from https://security.microsoft.com. Microsoft says Sentinel is generally available in the Defender portal, including for customers without Defender XDR or an E5 license, and that the Defender portal provides the unified SIEM and XDR experience (Microsoft Sentinel in the Microsoft Defender portal).
The second model is the older Azure portal connector approach. You install the Microsoft Defender XDR solution from Sentinel Content hub, open the Microsoft Defender XDR data connector, and manually enable incident, alert, entity, and event collection. This model is still useful for existing workspaces that have not moved fully to the Defender portal.
Here’s the simplest decision:
-
New SOC workflow? Use the Defender portal.
-
Existing Sentinel workspace still operated from Azure? Enable the Defender XDR connector now, then plan the portal transition.
-
Hybrid transition period? Keep runbooks explicit about which portal owns each task until analysts are fully moved.
Step 2: Use the Defender Portal as the Primary Incidents Queue
The biggest operational win is not a table or a query. It’s giving analysts one incident queue.
In the Defender portal, go to Investigation & response —> Incidents & alerts —> Incidents. This queue can show Microsoft Sentinel incidents together with Defender XDR incidents when Sentinel is onboarded to the Defender portal. Microsoft describes this as part of the Defender portal’s unified experience, where Microsoft Sentinel data is ingested together with the organization’s security data and SecOps teams analyze and respond in one place (Microsoft Defender XDR integration with Microsoft Sentinel).
If your workspace is already onboarded to the Defender portal, Microsoft says the Defender XDR connector is automatically set up for you. The manual connector steps are not required in that case (Stream data from Microsoft Defender XDR to Microsoft Sentinel).
If your team still uses Sentinel in the Azure portal, configure the connector manually:
-
Open Microsoft Sentinel in the Azure portal.
-
Select your workspace.
-
Go to Content management —> Content hub.
-
Install the Microsoft Defender XDR solution.
-
Go to Configuration —> Data connectors.
-
Open the Microsoft Defender XDR connector page.
-
Enable Connect incidents and alerts.
-
Select the recommended option to turn off Microsoft incident creation rules for the integrated Defender products to avoid duplicate incidents.
-
Save the connector configuration.
Microsoft’s connector documentation includes this validation query for Defender XDR incidents in Sentinel:
“`plain text
SecurityIncident
| where ProviderName == “Microsoft XDR”
Under normal operating conditions, Microsoft says Defender XDR incidents typically appear in the Sentinel UI and API within five minutes after they’re generated in Defender XDR. Ingestion into the `SecurityIncident` table can take a few more minutes ([Microsoft Defender XDR integration with Microsoft Sentinel](https://learn.microsoft.com/en-us/azure/sentinel/microsoft-365-defender-sentinel-integration)). ## Step 3: Understand What Syncs Between Defender XDR and Sentinel Once incidents are connected, don’t treat the integration as a one-way log feed. Microsoft documents bidirectional synchronization between the Defender portal and Sentinel for Defender XDR incidents. Changes to certain incident fields are synchronized after the change is applied, though you might need to refresh the portal to see the latest values ([Microsoft Defender XDR integration with Microsoft Sentinel](https://learn.microsoft.com/en-us/azure/sentinel/microsoft-365-defender-sentinel-integration)). For analysts, that means: - An incident can be triaged in Defender XDR and reflected in Sentinel. - An incident can be managed in Sentinel and reflected in Defender XDR. - Defender XDR correlation can merge or update incidents as the attack story changes. - A Sentinel incident can link back to its parallel Defender XDR incident. For engineers, it means you should stop building automation that assumes Sentinel alone owns the incident lifecycle. Use stable conditions such as severity, provider, product name, entities, tags, tactics, or custom details. Avoid brittle conditions based only on incident title. Microsoft specifically warns that Defender XDR’s correlation engine automatically names incidents and recommends using criteria other than incident name for automation rule conditions, such as tags ([Microsoft Defender XDR integration with Microsoft Sentinel](https://learn.microsoft.com/en-us/azure/sentinel/microsoft-365-defender-sentinel-integration)). Also remember the 150-alert behavior. Microsoft says Sentinel incidents can contain a maximum of 150 alerts. Defender XDR incidents can have more; if an incident with more than 150 alerts is synchronized, Sentinel shows `150+` and links to the Defender XDR incident for the full set ([Microsoft Defender XDR integration with Microsoft Sentinel](https://learn.microsoft.com/en-us/azure/sentinel/microsoft-365-defender-sentinel-integration)). ## Step 4: Stream Defender for Endpoint Raw Events into Sentinel Incidents give you the story. Raw events give you the evidence. The Defender XDR connector can stream advanced hunting events from Defender XDR components into purpose-built tables in your Sentinel workspace. Microsoft calls these a type of raw event data and says the tables use the same schema as the Defender portal advanced hunting schema, making it easier to copy existing Defender hunting queries into Sentinel ([Microsoft Defender XDR integration with Microsoft Sentinel](https://learn.microsoft.com/en-us/azure/sentinel/microsoft-365-defender-sentinel-integration)). In the connector page, enable **Connect events**, then choose the tables you want to collect. For Microsoft Defender for Endpoint, common tables include: - `DeviceInfo` for device inventory and OS information. - `DeviceNetworkInfo` for network adapters, IP addresses, MAC addresses, networks, and domains. - `DeviceProcessEvents` for process creation events. - `DeviceNetworkEvents` for network connections. - `DeviceFileEvents` for file creation, modification, and other file system activity. - `DeviceRegistryEvents` for registry changes. - `DeviceLogonEvents` for sign-ins and device authentication events. - `DeviceImageLoadEvents` for DLL loading events. - `DeviceEvents` for multiple endpoint event types, including security-control events. A practical starting point is to enable the endpoint tables your SOC actually hunts with every week. If you turn on everything without a use case, you’ll pay to ingest data nobody uses. Microsoft notes that Defender XDR alerts and incidents that populate `SecurityAlert` and `SecurityIncident` are ingested and synchronized at no charge, but other data types, including advanced hunting tables such as `DeviceInfo`, `DeviceFileEvents`, and `EmailEvents`, are charged ([Microsoft Defender XDR integration with Microsoft Sentinel](https://learn.microsoft.com/en-us/azure/sentinel/microsoft-365-defender-sentinel-integration)). Also watch for unsupported data. Microsoft specifically calls out Defender Vulnerability Management tables such as `DeviceTvmSoftwareInventory` and `DeviceTvmSoftwareVulnerabilities`: they can appear in the schema for autocomplete and discoverability, but TVM data isn’t ingested into Sentinel workspaces. Query TVM data in Defender XDR Advanced Hunting or build a custom ingestion path if Sentinel must use it ([Stream data from Microsoft Defender XDR to Microsoft Sentinel](https://learn.microsoft.com/en-us/azure/sentinel/connect-microsoft-365-defender)). Validate event flow with a small query: ```plain text DeviceProcessEvents | take 10
Then test a slightly more useful query:
“`plain text
DeviceProcessEvents
| where Timestamp > ago(24h)
| summarize ProcessEvents=count() by DeviceName
| top 20 by ProcessEvents desc
If you get no data, check three things before blaming KQL: the connector table selection, Defender for Endpoint onboarding health, and whether enough time has passed for new events to arrive.
## Step 5: Build Cross-Product Detections
Once Defender endpoint events and Sentinel data live in the same workspace experience, you can start writing cross-product detections. For scheduled Sentinel analytics rules, Microsoft recommends designing and testing the KQL query first, making sure the query returns `TimeGenerated`, then creating a scheduled query rule from **Microsoft Sentinel —> Configuration —> Analytics** in the Defender portal or **Configuration —> Analytics** in the Azure portal ([Create scheduled analytics rules in Microsoft Sentinel](https://learn.microsoft.com/en-us/azure/sentinel/create-analytics-rules)).
Here’s a starter detection pattern that correlates suspicious endpoint process execution with sign-in activity. Adjust table names and fields to match the connectors you have enabled:
```plain text
let Lookback = 1h;
let SuspiciousProcesses = DeviceProcessEvents
| where TimeGenerated > ago(Lookback)
| where FileName in~ ("powershell.exe", "pwsh.exe", "cmd.exe", "wscript.exe", "cscript.exe")
| where ProcessCommandLine has_any ("-enc", "DownloadString", "FromBase64String", "Invoke-WebRequest")
| project TimeGenerated, DeviceName, AccountUpn, FileName, ProcessCommandLine, DeviceId;
let RecentSignins = SigninLogs
| where TimeGenerated > ago(Lookback)
| project SigninTime=TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ResultType;
SuspiciousProcesses
| join kind=leftouter RecentSignins on $left.AccountUpn == $right.UserPrincipalName
| project TimeGenerated, DeviceName, AccountUpn, FileName, ProcessCommandLine, IPAddress, AppDisplayName, ResultType
That rule is intentionally simple. The point is to show the workflow:
-
Start from an endpoint behavior table.
-
Join with identity, cloud, firewall, or SaaS logs already in Sentinel.
-
Map entities such as account, host, and IP address in the analytics rule wizard.
-
Test with current data before saving the rule.
-
Create incidents from alerts unless you have a specific reason not to.
If your workspace is onboarded to the Defender portal, Microsoft says the Defender portal’s correlation engine is responsible for alert correlation. Alert grouping settings are accepted as initial instructions, but the final grouping can differ from what you configured in the rule (Create scheduled analytics rules in Microsoft Sentinel). Build your analyst process around incident quality, not perfect one-rule-to-one-incident mapping.
Also evaluate Defender custom detections. Microsoft now describes custom detections in Microsoft Defender as the best way to create new rules across Microsoft Sentinel SIEM and Defender XDR for a unified SOC experience, while Sentinel analytics rules remain available (Microsoft Defender XDR integration with Microsoft Sentinel). A good rule of thumb is:
-
Use Defender custom detections for Defender-native, near-real-time detections and response actions.
-
Use Sentinel analytics rules when you need Sentinel-only data sources, complex joins, SIEM content templates, or workspace-specific incident logic.
Step 6: Automate with Rules and Playbooks
Detection without response just creates a prettier queue.
Microsoft Sentinel automation has two main parts: automation rules and playbooks. Automation rules manage incident handling from a central place. They can tag, assign, or close incidents; trigger playbooks; automate responses across multiple analytics rules; and create task lists for analysts. Playbooks are built on Azure Logic Apps and can run response or remediation workflows automatically or on demand (Automation in Microsoft Sentinel).
A practical first automation rule for the unified SOC is a tagging rule:
-
Go to Microsoft Sentinel —> Configuration —> Automation.
-
Create an automation rule that runs when an incident is created.
-
Scope it to incidents where the provider or product identifies Microsoft Defender XDR.
-
Add a tag such as
defender-xdrorunified-soc. -
Assign the incident to your Tier 1 queue or SOC group.
-
Add analyst tasks such as “Review Defender incident graph,” “Check endpoint timeline,” and “Confirm user risk.”
Then add a playbook for enrichment, not destructive remediation. For example, a Logic Apps playbook can post to Teams, open a ticket, enrich IPs with threat intelligence, or collect asset owner information. Keep device isolation, account disablement, and mailbox actions behind a manual approval step until you have strong false-positive controls.
If you’re transitioning to the Defender portal, read the automation differences carefully. Microsoft notes that, after onboarding, the Updated by field has different supported values, and if multiple changes are made to the same incident in a 5-10 minute period, a single update is sent to Sentinel with only the most recent change (Automation in Microsoft Sentinel). That matters if your automation depends on every intermediate incident update.
Step 7: Verify the SOC Workflow End to End
Don’t call the integration done just because the connector says connected. Run a full analyst-path validation.
Use this checklist:
-
Create or identify a low-risk test alert in Defender XDR.
-
Confirm the incident appears in the Defender portal incident queue.
-
Confirm the synchronized incident appears in Sentinel if you’re still validating Azure portal behavior.
-
Run the
SecurityIncidentquery forProviderName == "Microsoft XDR". -
Run a sample
DeviceProcessEventsorDeviceNetworkEventsquery. -
Confirm entity mapping shows useful users, hosts, and IP addresses.
-
Trigger a test automation rule and confirm the expected tag, owner, task, ticket, or notification.
-
Close the test incident and confirm status synchronization in the other portal if both portals are in use.
Document what analysts should do in one page: where to start, which portal links to trust, how to pivot to advanced hunting, and when to run a playbook manually.
Final Thoughts
The Defender XDR and Microsoft Sentinel integration is not just a connector. It is an operating model.
Use the Defender portal as the unified incident queue. Let Defender XDR correlate Microsoft security alerts into richer incidents. Stream the Defender for Endpoint raw event tables you actually hunt with into Sentinel. Use Sentinel analytics rules where you need SIEM data and cross-source joins. Use Defender custom detections where Defender-native detection and response is the better fit. Tie it together with automation rules and Logic Apps playbooks that enrich and route incidents without surprising analysts.
Do that, and your SOC gets fewer swivel-chair investigations, better context, and a cleaner path from signal to response.
