Sentinel in the Defender portal brings SIEM and XDR together in preview

For the past few months I've noticed a lot more customers running Microsoft 365 and Azure asking about Sentinel in the Defender portal. Since Microsoft opened the preview that integrates Microsoft Sentinel into the unified Defender portal, plenty of SOC teams have taken an interest in having SIEM and XDR in one place. The appeal is easy to understand. Incidents, hunting and investigation all live in a single portal, and the line between SIEM and XDR starts to fade. Getting from the preview announcement to something you can rely on every day is another matter, though. You'll hit practical limitations, permission issues and changes to your processes along the way.

The connection supports one workspace and needs permissions on both sides

The first thing to know about connecting Sentinel in the Defender portal is a hard limit: during the preview you can connect only one Sentinel workspace per tenant at a time. Multiple workspaces aren't supported, so you have to choose carefully. You do the onboarding in the Defender portal settings, following the steps in the Microsoft documentation. This isn't a switch you just flip. You need admin permissions in both Sentinel and the Defender portal, and the required RBAC roles have to be mapped in each. In my projects, teams regularly trip over permissions that don't line up – you need owner or contributor rights in both Sentinel and Defender XDR before everything works properly. If that's missing, you'll end up with a partial integration at best.

Unified incidents end the alert silos for SOC teams

The part that matters most is that Sentinel alerts and incidents now appear as unified incidents in the Defender portal, right next to Defender XDR detections. Incident responders no longer have to jump back and forth between portals, and attack correlations that used to be split between SIEM and XDR become visible. The unified incident view groups alerts from Sentinel analytics rules and Defender detectors together. During the preview, however, not every action syncs cleanly. Closing, assigning or deleting incidents can behave differently in Sentinel and in the Defender portal, and in a few SOCs I've seen this cause actions to be duplicated or missed.

Tip: If you already run Logic Apps or automation playbooks in Sentinel, check your mappings and status flows again. While the preview integration is still changing, it's easy to overlook a status change or handle the same incident twice.

If Defender XDR is already in place for you, I'd read both the Defender XDR intro post and the official onboarding guide. They explain the awkward spots you may run into during the preview and offer practical workarounds.

Advanced hunting finally queries across both platforms

This is the change I like most. With the upgraded KQL engine, analysts can use advanced hunting in the Defender portal to query Sentinel and Defender XDR tables together. You can test a hypothesis against device, identity and custom log data from both sides. Many of the SOCs I've worked with have asked for this for a long time. Say you want to find out whether an "adminuser" account shows up in both endpoint events and server logs:

union DeviceEvents, SecurityEvent
| where Timestamp > ago(1d)
| where AccountName == "adminuser"
| project Timestamp, AccountName, DeviceName, EventID, ReportId

A query like this gives you one view across endpoints and server logs. Microsoft Learn lists all supported tables and has tips on the syntax.

Analytics rules, automation and workbooks stay separate during the preview

For now, you still manage Sentinel's analytics rules, automation (Logic Apps/Playbooks) and workbooks in Sentinel. The Defender portal preview is about incidents and hunting, not about writing rules or building automation. If you want to update an analytics rule or adjust an automated response, you go back to the Sentinel portal. Sentinel workbooks don't show up in the Defender portal yet either. Analytics, automation and reporting still require Sentinel permissions and the original interface. A lot of SOCs expect a fully unified experience, and that's simply not what the preview delivers yet.

These are the main preview limitations as of June 2024:

• Only one Sentinel workspace per tenant
• Sentinel workbooks not shown in Defender portal
• Analytics rules and automation must be managed in Sentinel
• Roles must be assigned in both Defender and Sentinel separately
• Incident assignment/status isn't always perfectly synchronized

Before I get to my recommendations, it's useful to picture how incidents flow. The diagram below shows how alerts from both platforms end up as unified incidents in the Defender portal.

flowchart TD
    SentinelRules["Sentinel Analytics"] --> SentinelAlerts["Sentinel Alerts"]
    DefenderDetectors["Defender Detectors"] --> DefenderAlerts["Defender Alerts"]
    SentinelAlerts --> UnifiedIncidents["Unified Incidents"]
    DefenderAlerts --> UnifiedIncidents
    UnifiedIncidents --> PortalView["Defender Portal"]

Figure: How alerts from Sentinel and Defender feed into unified incident management in the Defender portal (preview)

The preview works, but it needs careful coordination in practice

Integrating Sentinel into the Defender portal moves things a good way toward a unified SOC, but the preview has its caveats. Needing roles on both sides and incidents that only partly sync can catch out experienced teams too. I'd pilot it in a non-production environment first and look closely at incident status mapping, permissions and automation flows. If different teams look after Sentinel and Defender XDR, agree on clear ownership, or you'll end up with duplicate work or missed alerts. I'm optimistic about where this is heading. Until it reaches GA, though, you'll only get real value out of it with extra coordination and close monitoring.