Unified Secops Platform

Unified SecOps Platform (Microsoft Defender portal)

The unified security operations platform consolidates SIEM (Microsoft Sentinel), XDR (Microsoft Defender XDR), Microsoft Security Copilot, Microsoft Defender Threat Intelligence, and Microsoft Security Exposure Management into a single experience in the Microsoft Defender portal (security.microsoft.com).

When to use

Standardising the SOC on one portal, unifying the incident queue across SIEM and XDR signals, and reducing context-switching for analysts.

Do not use this skill for:

• Workspace, data connector, or analytics rule design only (use sentinel)
• Endpoint/identity/email/cloud-app investigation only (use defender-xdr)
• Threat-hunting query writing only (use sentinel for KQL guidance)

Pick the right starting question

Rule of thumb: if your SOC has Sentinel and Defender XDR, you should be in the unified portal. The Azure Sentinel portal is the legacy surface; new investments land in the Defender portal first.

Approach

1. Confirm prerequisites - A Microsoft Sentinel workspace, Microsoft Defender XDR onboarded with at least one Defender product, the required Entra and Sentinel RBAC roles for the onboarding admin, and tenant alignment between the Sentinel workspace and the Defender XDR tenant. Verify: the workspace and Defender XDR are in the same tenant; the admin holds Microsoft Sentinel Contributor + a Defender XDR security role.
2. Pick the primary workspace - Only one Sentinel workspace can be the primary in the unified portal per tenant. If you run multiple workspaces, decide which carries the unified experience and which remain Azure-portal-only. Plan migrations accordingly. Verify: workspace inventory documents which is primary and the rationale.
3. Onboard Sentinel to the Defender portal - From the Defender portal, connect the Log Analytics workspace. Onboarding is non-destructive to existing Sentinel content (analytics rules, hunting queries, playbooks) but changes where analysts work. Verify: Defender portal → Investigation & response shows incidents from both Sentinel analytics rules and Defender XDR detections.
4. Validate the unified incident queue - Incidents and alerts from Sentinel and Defender XDR merge into one queue with shared entities, enabling single-pane triage. Confirm Sentinel incidents that previously stood alone now correlate to XDR alerts where appropriate. Verify: an end-to-end test attack (e.g. simulated phishing + sign-in anomaly) creates one correlated incident, not two.
5. Use unified advanced hunting - Query both Sentinel and XDR tables together with KQL in the Defender portal hunting experience. Retire duplicate hunting queries that only existed to bridge the two surfaces. Verify: a hunting query joining a Defender table (e.g. DeviceLogonEvents) and a Sentinel table runs in one window.
6. Layer in cross-cutting capabilities - Add Security Copilot for inline AI assistance, Threat Intelligence for IOC management, and Exposure Management for attack-surface and attack-path insight. Each adds value but each adds licence/SCU cost - sequence by SOC pain. Verify: each capability has a named SOC use case before enabling, not just a toggle flip.
7. Validate RBAC end-to-end - Defender portal unified RBAC governs access to the merged experiences. Map existing Sentinel and Defender role assignments to the unified model and confirm no role escalation or unintended access has appeared. Verify: a least-privilege analyst sees only their assigned workloads in both incident queue and hunting.
8. Migrate analyst workflow - Update runbooks, shift links, and training to point at the Defender portal. Treat the Azure Sentinel portal as legacy for analyst day-to-day.