Microsoft Sentinel Is Leaving the Azure Portal: Planning Your Move to Defender

After March 31, 2027, Microsoft Sentinel is no longer supported in the Azure portal. Anyone who opens it there will be redirected to the Microsoft Defender portal, which becomes the only place to run Sentinel. You don’t need Microsoft Defender XDR or an E5 licence to use it there, and Microsoft states the move itself has no extra cost: you keep paying for Sentinel consumption as you do today.

Your workspace, your data and your analytics rules survive the move. What changes is the console, how incidents are correlated, how some automation behaves and, optionally, how permissions are managed. For a mid-sized team without a large SOC, the risk is not the onboarding click. It is automation and runbooks that assume the Azure portal’s behaviour. Plan to connect your workspace this quarter and finish the cut-over by the end of February 2027, so you have a month of slack before the deadline.

What actually changes in the Defender portal

The table below is based on Microsoft’s transition guide and feature comparison.

Area	Azure portal today	Defender portal
Incidents	Separate Sentinel incident queue	Unified incident queue under Investigation & response. The incident provider is always “Microsoft XDR”, and the Defender correlation engine can merge incidents and rename existing ones
Analytics rules	Configuration > Analytics, with the Fusion rule doing multistage correlation	Same rules, wizard and API. Fusion is disabled and the Defender XDR engine handles correlation. Rules set to create alerts only, with incident creation off, are not visible
Automation rules and playbooks	Logic Apps playbooks triggered by automation rules	Still Logic Apps, but the “Incident provider” condition is removed, the incident Description field is gone, and a rule can take up to 10 minutes to run
Hunting	Logs page and Sentinel hunting	Advanced hunting runs your existing KQL, tables and functions. Bookmarks stay in Microsoft Sentinel > Threat management > Hunting
Workbooks	Azure workbooks	The same Azure workbooks, under Microsoft Sentinel > Threat management
Permissions	Azure RBAC	Azure RBAC keeps working. Unified RBAC can be activated per workspace, after which it becomes the source of permissions
Multiple workspaces and tenants	Workspace manager, Azure Lighthouse	One primary and several secondary workspaces per tenant. Workspace manager is not available. Multiple tenants are handled in the Defender multitenant portal
Long-term data	Log Analytics tiers	Optional Microsoft Sentinel data lake, created in the same region as your primary workspace

Two rows carry most of the risk. Alert grouping settings still appear in your rules, but the Defender engine now decides which alerts share an incident. And anything that reads incident fields, from automation rules to ticketing integrations, may see different values after onboarding.

What stays the same, and what to verify

Sentinel keeps storing data in your Log Analytics workspace. Non-Microsoft data connectors keep running, analytics rules keep their logic, and workbooks behave as they did. Billing for ingestion and retention is unchanged by the move.

Three items deserve a check with your privacy or risk owner before you connect:

• Data policies. In the Defender portal, Microsoft Defender XDR’s data storage, retention and sharing policies apply, even to Sentinel data. Compare them with Sentinel’s if you have residency commitments.
• Customer-managed keys. If you use CMK, log data and Sentinel content stay CMK-encrypted, but alerts and incidents are no longer CMK-encrypted after onboarding. The Sentinel data lake does not support CMK.
• Microsoft security alerts. With Defender XDR, alerts from Microsoft security products arrive through the Defender XDR connector. Some fields change, and by default Entra ID alerts below High severity aren’t ingested. Check any query or rule that reads the SecurityAlert table.

A three-phase plan to finish before March 2027

Phase	When	Outcome
1. Connect and run side by side	Late November to December 2026	Workspace connected, primary chosen, analysts working incidents in the Defender portal
2. Fix automation and integrations	January to mid-February 2027	Automation rules, playbooks, API calls and ticketing sync tested against Defender behaviour
3. Retrain and cut over	By the end of February 2027	Runbooks rewritten, permissions model decided, Azure portal no longer used for Sentinel

Phase 1: Connect the workspace and run both portals

Start with permissions, because onboarding fails quietly without them. You need at least Security Administrator in Microsoft Entra ID, plus either an unconditional Owner assignment at the subscription or User Access Administrator with Microsoft Sentinel Contributor. Without them, the workspace simply doesn’t appear in the Defender portal. We grant these just in time through Privileged Identity Management. Onboarding also assigns Microsoft Sentinel Contributor to the Microsoft Threat Protection and WindowsDefenderATP apps in the subscription, so expect those in your next access review.

With more than one Sentinel workspace in the tenant, choose the primary deliberately. The Defender XDR connector attaches to the primary only, and standalone connectors for Microsoft security products such as Defender for Endpoint and Entra ID Protection are disconnected from secondary workspaces during onboarding. The data lake, if you add it later, is created in the primary workspace’s region.

Then connect under System > Settings > Microsoft Sentinel and let analysts work incidents in the Defender portal while the Azure portal is still available. Pick one portal for incident work, though. Comments edited in the Azure portal don’t sync to the Defender portal, and incidents created manually in the Azure portal, or by a playbook or the API, aren’t synchronized to the Defender portal either.

This is also the moment to line up posture management. From October 27, 2026, Microsoft recommends the Defender portal for managing Azure posture in Defender for Cloud, which we covered in Defender for Cloud’s free CSPM becoming opt-in. Moving Sentinel and posture work into one console in the same cycle means one set of runbooks and one round of training.

Phase 2: Fix automation, rules and integrations

The most common gap we find when we review Sentinel automation is rules that depend on fields the Defender portal changes. Work through this list for every automation rule and playbook:

• Incident titles. Correlation can rename existing incidents. Microsoft recommends conditioning on the analytics rule name, plus tags, instead of titles.
• Incident provider. The condition is removed and every incident reports “Microsoft XDR”, so a rule scoped to Sentinel incidents may now fire on Defender XDR incidents too.
• Description field. The SecurityIncident table no longer includes Description. Automation conditioned on it stops working, and ticketing integrations such as ServiceNow lose the incident description.
• Updated by. “Microsoft 365 Defender” is replaced by “Other” in existing rules.
• Timing. Automation can run up to 10 minutes after an incident is created or updated, and several changes to one incident within 5 to 10 minutes arrive as a single update. Workflows that react to each status change need retesting.
• Manual playbooks. Running a playbook manually on an alert or an entity isn’t currently supported in the Defender portal.

Then check the rules. Alert-only rules won’t show up, so turn on incident creation where analysts need the output. Microsoft security incident creation rules are deactivated on onboarding to prevent duplicates.

Finally, the API. If a ticketing system or report calls the Sentinel SecurityInsights API for incidents, the response changes: providerName becomes “Microsoft XDR” and a new providerIncidentUrl links to the Defender portal. Microsoft recommends the Microsoft Graph security API for unified incidents.

Phase 3: Retrain the team and cut over

One incident can now hold alerts from endpoints, identities, email and your Sentinel rules, with an attack story to follow. Microsoft notes this can require broader analyst knowledge, and for a small team that is the real cost of the move. Give each analyst a few weeks of real incidents in the Defender portal, and rewrite runbooks against the new navigation: Incidents sit under Investigation & response, and Logs becomes Advanced hunting.

Decide on permissions last. Your Azure RBAC assignments keep working after onboarding, so Unified RBAC is optional. Activate it only when it fits: it doesn’t support the Microsoft Sentinel Playbook Operator, Automation Contributor or Workbook Contributor roles, and it can’t assign Sentinel permissions to service principals. Once it’s active for a workspace, manage Sentinel permissions in the Defender portal, because changes made in the Azure portal can cause sync errors. Our Practical Guide to Azure Cloud Security Posture includes the identity and access checklist we use to review who should hold these roles.

If a partner or MSP runs your SOC, the cut-over date belongs in their plan too. Multi-tenant access moves to the Defender multitenant portal, and GDAP with Azure Lighthouse isn’t supported for Sentinel data in the Defender portal, so delegated access may need to move to Microsoft Entra B2B. Azure Lighthouse is still required for cross-workspace queries across tenants. We discuss how to split that responsibility in in-house, MSP or Microsoft partner.

If you run Sentinel without Defender XDR

Many mid-sized organizations chose Sentinel as their SIEM without Microsoft’s full XDR stack, often for the reasons in Azure Sentinel vs traditional SIEM. The move still applies. Without Defender XDR, the Incidents and Advanced hunting pages show only Sentinel data, and Microsoft Security Exposure Management, custom detection rules and the Action center are limited or unavailable. Keep building detections as Sentinel analytics rules.

Where to start

This week, list who holds the onboarding roles, how many Sentinel workspaces you have and which one should be primary, and every automation rule, playbook and integration that reads incident fields. That inventory shows how big the move really is.

Techrupt’s Azure security consulting team can run the onboarding and the automation review with you, so the cut-over happens in February and not in the last week of March. Book a consultation and we’ll go through your workspace and automation together.