Microsoft Defender XDR in 2026: The Unified Portal, Sentinel Convergence, and the Agentic SOC

Executive Snapshot

Corrections to the original version of this article

This article was first published against Microsoft's then-current announcements. Three of those claims have since proved wrong or misleading.

The July 2026 redirect is not happening as described. That claim came from Microsoft's July 2025 announcement, which now carries an explicit note: this date has been extended. The only date Microsoft stands behind is 31 March 2027. The real automatic-onboarding behaviour applies to a narrower group — tenants that onboarded their first Sentinel workspace after 1 July 2025 with subscription Owner or User Access Administrator permissions — per What's new for unified security operations.

"No workspace limit" was true but misleading, for reasons covered below. And "Copilot chat with expanded agentic triage" was vendor framing, not a shipped state: both the Defender chat experience and the agent that triages more than email are labelled preview in Microsoft's own docs, which have replaced the third-party newsletter originally cited here.

The big picture: one console, one real deadline

For years, Microsoft security teams lived in two worlds — the Defender portal for XDR (endpoints, identities, email, cloud apps) and the Azure portal for Sentinel (SIEM, Log Analytics, automation). Those have converged into one unified security operations experience, and the Azure portal side now has an end date: 31 March 2027. Microsoft moved that cutover once already after feedback from customers running Sentinel at scale, so migrate when your automation and RBAC are ready, not when a banner appears.

What the unified portal actually merges — and what it does not

The merge is genuine at the incident and hunting layer. Defender XDR alerts and Sentinel analytics-rule alerts land in one queue, the correlation engine stitches them into single incidents, and advanced hunting queries Defender and Sentinel Log Analytics tables side by side. Entity pages for users, devices, and IP addresses consolidate into one view spanning both.

Several things stay put. Log Analytics remains the storage and query engine behind Sentinel — the front end unified, the backend did not. Playbooks are still Azure Logic Apps, authored and billed in Azure. Azure RBAC on workspaces is still managed from the Azure portal and flows through rather than being replaced. Defender for Cloud's alerts and incidents integrate into the portal, but that integration is about detections, not about relocating posture management.

Some Azure-portal features do not exist on the other side. Workspace Manager is gone, replaced by repository-based content deployment or the multitenant portal. Bookmarks are absent from advanced hunting, surviving only in the Sentinel-specific hunting page. Similar incidents is unsupported, and creating an automation rule from an incident — or adding an entity to threat intelligence from one — remains Azure-portal-only.

Primary and secondary workspaces: the constraint behind "no limit"

The Defender portal supports one primary workspace and an unlimited number of secondary workspaces per tenant. That sounds like every workspace gets the same treatment. It does not.

Only the primary workspace's alerts correlate with Defender XDR data. Secondary workspaces create incidents from their own data only, and the Defender XDR connector attaches to the primary alone. If XDR data flowed into several workspaces before the move, it now flows into one — and any rule or automation in the others that depended on it stops working until you configure table ingestion explicitly.

Onboarding also auto-disconnects standalone connectors on secondary workspaces: Defender for Office 365, Entra ID Protection, Defender for Cloud Apps, Defender for Endpoint, and Defender for Identity. That is deliberate de-duplication, since those alerts are tenant-scoped. Inventory your other standalone Microsoft connectors first, because Microsoft only handles that list.

A few capabilities are primary-only: the Workbooks page shows primary-workspace data, and in advanced hunting, custom detections and API queries are limited to the primary. Microsoft's guidance is to make the primary your global SOC workspace.

What breaks: automation, APIs, and the fields your tooling depends on

This is where migrations actually hurt, and it is worth reading Microsoft's transition guide in full before touching production.

The SecurityIncident table loses its Description field. Any automation rule keying off it stops working, and incidents pushed into ServiceNow arrive with an empty description. The Updated by field drops Microsoft 365 Defender and rewrites existing rules to Other. The Incident provider condition becomes meaningless because every incident now reports Microsoft XDR — so rules you scoped to Sentinel-only incidents start firing on Defender incidents too. Scope by analytics rule name or tag instead.

Timing changes too. Defender incidents can take up to five minutes to reach Sentinel, and automation rules up to ten minutes to run after an incident is created or updated. Multiple changes inside a five-to-ten-minute window collapse into one update carrying only the latest state, so any workflow that assumed it would observe every transition needs rethinking.

On the API side, prefer the Microsoft Graph security API for incidents and alerts. The Sentinel SecurityInsights API still serves analytics and automation rules, but the incident response body changed: providerName becomes Microsoft XDR, a new providerIncidentUrl carries the Defender-portal deep link, and alertProductNames now requires ?$expand=alerts.

Two RBAC details belong on your change-approval record rather than in a post-migration surprise. Onboarding assigns the Microsoft Sentinel Contributor role to the Microsoft Threat Protection and WindowsDefenderATP service principals in your subscription. And IdentityInfo becomes a native Defender table with no table-level RBAC support — if you restrict access to it that way today, the control disappears.

The agentic SOC, stated precisely

Vendor "agentic" language is marketing until it maps to a feature with a documentation page and a status label. Here are the labels.

The Defender chat experience — the open-prompt Copilot panel in the top navigation — is preview. It is page-context aware and proposes a step-by-step plan you approve or reject before it acts. The older embedded Copilot skills (incident summary, guided responses, script analysis, device and identity summaries, the KQL query assistant) are a separate, longer-shipping set.

The Security Alert Triage Agent is preview. It is the same agent previously sold as the Phishing Triage Agent, extended to more workloads. Email and collaboration triage is generally available; cloud alerts (containers first) and a short list of identity alerts (password spray, BEC-related inbox rules, post-password-spray compromise) are preview. It does act autonomously: a false-positive verdict resolves the alert, while a true-positive verdict leaves the incident open for a human. It closes noise, not threats — that is the honest version of "keep a human on consequential decisions."

All of it requires a Security Copilot workspace with provisioned SCU capacity, which is not bundled with E5. Each triage workload then carries its own licence: Defender for Office 365 Plan 2 for email, Defender for Cloud plus Defender for Containers for cloud alerts, and Entra ID P2 plus Defender for Identity plus Defender for Cloud Apps for identity. Setup needs the Security Administrator role in Entra ID, unified RBAC activated for those workloads, and a dedicated agent identity.

The identity risk score is real and also preview: each identity gets a 0-100 score on its detail page in Defender for Identity's Identity Security dashboard, with contributing factors and a percentile comparison. Microsoft does not publish the weighting, so treat it as a triage hint, not an auditable control.

Threat intelligence after the MDTI retirement

Microsoft retired Microsoft Defender Threat Intelligence as a standalone product on 1 August 2026, converging it into Defender and Sentinel. If your runbooks still treat an MDTI subscription as a separate thing to buy or renew, they are out of date.

In the Defender portal, threat intelligence lives under Intel management. Threat analytics is available to Defender XDR customers; Intel Profiles and Intel Explorer are gated on MDTI entitlement, which now arrives through Defender or Sentinel licensing rather than a standalone SKU. Intel projects is deprecated — link indicators to a case instead.

Licensing: who needs what

Three tiers, and conflating them is the most common budgeting error.

Sentinel in the Defender portal needs neither Defender XDR nor E5. Microsoft states plainly that transitioning costs nothing extra and you keep being billed for Sentinel consumption only. A SIEM-only shop moves and sees a Sentinel-only portal.

Unified security operations — one correlated queue across SIEM and XDR — requires Defender XDR licensing, with that account in the same Entra tenant as Sentinel. This is where the correlation engine, attack story graph, and blast radius analysis come from. If you are still weighing E3 against E5, start with the Microsoft 365 licensing comparison.

Agents and Copilot are a third, separate purchase in SCUs, with per-workload licences on top.

Two hunting queries worth running before you migrate

Run these after onboarding a test workspace, and again in production. They answer the parity question — is the same telemetry still arriving — without assuming anything about your rule set. First, inventory which services and detection technologies actually populate the unified queue:

AlertInfo
| where Timestamp > ago(30d)
| summarize Alerts = count() by ServiceSource, DetectionSource, Severity
| sort by Alerts desc

Then find the accounts drawing alerts from the widest set of sources — the cross-domain cases the merged queue exists to surface:

AlertInfo
| where Timestamp > ago(7d)
| project AlertId, ServiceSource
| join kind=inner (
    AlertEvidence
    | where isnotempty(AccountUpn)
    | project AlertId, AccountUpn
) on AlertId
| summarize Alerts = dcount(AlertId), Sources = make_set(ServiceSource) by AccountUpn
| top 25 by Alerts

Both tables are documented in the advanced hunting schema reference and carry Sentinel alerts once a workspace is onboarded. Compare the ServiceSource breakdown before and after: a source that disappears is usually a standalone connector that onboarding disconnected.

A sequenced migration plan

flowchart TD
    A[Inventory workspaces, rules, playbooks, connectors, RBAC] --> B[Choose the primary workspace deliberately]
    B --> C[Audit automation for Description, Incident provider, Updated by]
    C --> D[Rehearse on a secondary workspace]
    D --> E[Run parity queries: sources, volumes, entities]
    E --> F[Onboard primary, migrate automation, retrain analysts]
    F --> G[Optional: license Security Copilot, pilot triage agent]

The detail the diagram hides is in steps one to three. Inventory must reach past workspaces and rules to standalone Microsoft data connectors and every automation rule referencing Description, Incident provider, Updated by, or an incident title. Choosing the primary workspace is an architecture decision, not a wizard default — it is the only one that correlates with Defender XDR, and changing it later moves the XDR connector with it. And automation gets fixed before onboarding, not after: rescope rules from incident provider to analytics rule name or tags, and confirm your ticketing integration does not depend on the incident description.

Rehearsing on a secondary workspace gives you a real trial without risking the correlated queue. Retraining matters more than teams expect: unified triage can collapse tier 1 and tier 2 work, but it demands broader knowledge per analyst. Add AI last — provision SCUs, start the triage agent on email alerts where it is GA, and measure its verdicts against analyst judgement before extending it.

If your analytics rules and playbooks need work first, start with our guide to building Sentinel analytics rules and playbooks. Incidents involving sensitive data also pull in Purview, so have DLP configured for endpoint and email before the merged queue starts routing those cases to you.

The bottom line

The console merge is real and worth doing: one incident queue, one hunting surface, correlation you cannot get by running two portals. The AI layer is further from ready than the marketing suggests, and it costs extra. What will actually bite during migration is unglamorous — a missing field in an automation rule, a disconnected connector on a secondary workspace, a table-level RBAC control that quietly stops applying. Inventory now, rehearse on a secondary workspace, fix your automation, and cut over on your own timeline well before 31 March 2027.

Further reading

• Connect Microsoft Sentinel to the Microsoft Defender portal (Microsoft Learn)
• Transition your Microsoft Sentinel environment to the Defender portal (Microsoft Learn)
• Multiple Microsoft Sentinel workspaces in the Defender portal (Microsoft Learn)
• Deploy AI agents in Microsoft Defender (Microsoft Learn)
• MDTI is converging into Microsoft Sentinel and Defender XDR (Microsoft Community Hub)

Image credit: Daderot via Wikimedia Commons (CC0 / public domain).