1.3.3. The Unified Security Operations Platform
💡 First Principle: Two consoles means two queues, two hunting experiences, and an analyst who has to mentally correlate between them. Unifying XDR and SIEM in one portal removes that tax: one incident queue, one correlation engine, one advanced hunting experience across both data sets.
Microsoft's answer is the Microsoft Defender portal (security.microsoft.com) as the single operating surface. When you connect a Sentinel workspace to the Defender portal, Sentinel incidents and Defender XDR incidents appear in one queue, alerts from both are correlated together, and advanced hunting can query XDR tables and Sentinel tables side by side.
A few operational consequences recur in exam scenarios. Incidents synchronize, so changing status, owner, or classification in one view changes it everywhere. Defender XDR's correlation engine becomes responsible for incident creation for Sentinel alerts too, which changes how some legacy Sentinel incident-creation settings behave (2.5). And Microsoft has announced that Sentinel's experience in the Azure portal retires on March 31, 2027, so the Defender portal is the strategic home for day-to-day operations. Configuration of some Azure resources behind Sentinel, such as the workspace itself, data collection rules, and Logic Apps playbooks, still happens in Azure.
⚠️ Exam Trap: Unified does not mean merged retention. The XDR tables keep 30 days unless you ingest them into Sentinel and set retention there; Sentinel tables follow their own per-table settings. Questions asking how to "keep Defender for Endpoint data for one year for hunting" are testing this distinction.
Reflection Question: An analyst closes an incident in the Defender portal that originated from a Sentinel analytics rule. What happens to that incident's status in Sentinel, and why does that synchronization matter for SOC metrics such as MTTR?
