If you're still operating from the Azure portal, now is the time to transition and unify your SIEM and XDR experience.
By onboarding to the Defender portal, your SOC gains a single pane of glass across Microsoft security signals—blending the best of Sentinel’s analytics and hunting capabilities with Defender’s correlation engine, automation, and threat intelligence.
Key benefits include:
🔹 Unified incident queue
All incidents—whether triggered by Sentinel analytics rules or Defender signals—are merged into one view with built-in alert correlation across domains like email, identity, endpoint, and cloud.
🔹 Streamlined triage and investigation
Your analysts can now work from one interface, using filters, hunting queries, and entity context that span both SIEM and XDR data. The interface eliminates fragmented alert views and improves the attack narrative.
🔹 Advanced hunting with integrated data
Continue using KQL for Microsoft Sentinel data—but now enriched with Defender XDR context. While some schema changes apply (e.g., SecurityAlert table visibility), all existing queries still function.
🔹 Modern automation engine
Automation rules are now governed by the Defender engine. You’ll need to review latency, trigger behavior, and potential playbook limitations in the Defender context.
🔹 Multitenancy at scale
Support for MSSPs is enhanced through the Defender multitenant portal, with visibility across customers and workspaces. Combine with Azure Lighthouse and Microsoft Entra B2B for delegated access. (GDAP is not supported for Sentinel data.)
📌 Important architectural considerations before onboarding:
➡️Data policies shift from Sentinel’s to Defender’s—especially around storage, residency, and retention.
➡️Sentinel’s Fusion engine is disabled post-onboarding; Defender XDR handles incident correlation.
➡️Incident rules in Sentinel must now account for updated alert provider names, incident URLs, and new metadata fields in the Microsoft Graph API.
➡️Bookmarks, manual incident creation, and incident task tracking are only supported in the Azure portal.
➡️The Content hub and CI/CD integrations (YAML/JSON) remain supported—just updated for the Defender context.
🔁 Once transitioned, your Microsoft Sentinel data continues to reside in Log Analytics, but the front-end experience and incident lifecycle are fully governed by Defender.
Ready to transition? Start here:
📺Watch the videos: https://www.youtube.com/playlist?list=PL3ZTgFEc7Lyska6WLWBzc8sob-kYA2jPj
📖Read the docs: https://learn.microsoft.com/en-us/azure/sentinel/move-to-defender
Follow me on LinkedIn: José Lázaro | LinkedIn
#MicrosoftSentinel #DefenderXDR #UnifiedSOC #SIEM #XDR #MicrosoftSecurity #SOCModernization #SecurityAutomation #AdvancedHunting #MSSP #AzureSecurity #IncidentResponse #SecurityArchitecture #CyberDefense
In Sentinel, I'm able to decide which connectors to pull in events from (ie, not to pull in DLP incidents). I don't seem to have that same ability once I'm connected in the Unified Experience.
We have a separate team that generates hundreds of alerts per day for DLP policies that randomly get correlated with items we're looking at as Security Operations... and when we close our investigation, we close their alerts and mess up their stats and workflow.
If only we had a way to filter these out so they didn't get correlated. Similar to the toggle button we were given for IRM...