Microsoft Sentinel Move to the Defender Portal: Plan Workspaces, RBAC and Automation Before March 2027

Microsoft Sentinel will no longer be supported in the Azure portal after 31 March 2027, and the move to the Defender portal changes incident handling, automation conditions and access control in ways that silently break existing SOC content. The transition costs nothing in licensing, but it is not a cosmetic portal switch: Fusion is disabled, incident providers change, some automation patterns stop working and table-level RBAC on one table no longer applies. This guide covers the official timeline, who is affected, how to find content and identities that will break, the onboarding choices for single and multiple workspaces, and how to test and roll back. It is for Sentinel engineers, SOC leads and Azure administrators. The product itself is covered in the Microsoft Sentinel Guide.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• The date moved once already. Microsoft originally set 1 July 2026, then on 29 January 2026 announced 31 March 2027 as the date after which Sentinel management in the Azure portal ends; users still in the Azure portal will be redirected.
• Automation breaks quietly. After onboarding, every incident has the provider "Microsoft XDR", the Incident provider condition is removed and SecurityIncident no longer has a Description field, so rules filtering on either stop matching.
• Correlation changes owner. The Fusion rule is disabled and Microsoft security incident creation rules are deactivated, because the Defender XDR engine now correlates alerts into incidents.
• Only one primary workspace correlates. The Defender XDR connector attaches to the primary workspace; secondary workspaces lose standalone Defender connectors and need a deliberate design.
• Identity and access shift too. Onboarding assigns Microsoft Sentinel Contributor to Microsoft first-party apps, unified RBAC cannot grant roles to service principals, and table-level RBAC on IdentityInfo stops applying.

What is changing and why

Microsoft is consolidating SIEM and XDR operations into one portal, the Microsoft Defender portal, as "unified security operations". Sentinel is generally available there, including for customers without Defender XDR or an E5 licence, and Microsoft states the transition has no extra cost beyond normal Sentinel consumption. Shared incidents and advanced hunting across SIEM and XDR data require Defender XDR licensing in the same Entra tenant.

Official timeline and current status

Status as checked on 8 November 2026: the transition is available now and the Azure portal still works for Sentinel. Microsoft's transition article was last updated in September 2026 and lists the behaviour changes above. The date has moved once, so recheck the Learn pages before locking a plan, but do not plan around a further extension.

Who and what is affected

• Every Azure-portal Sentinel workspace: all workspaces must be onboarded or will be redirected after the retirement date.
• Automation authors: automation rules using the Incident provider condition, incident titles, the Description field or the "Updated by" value Microsoft 365 Defender (which becomes Other).
• Playbook owners: Logic Apps that add or remove alerts from incidents, are triggered manually on entities, or create incidents via API.
• Detection engineers: teams relying on Fusion, Microsoft incident creation rules, or alert-only rules whose alerts analysts still review.
• Integration and API consumers: ITSM connectors, SOAR tools and reporting that read Sentinel incidents should move to Microsoft Graph unified incident APIs.
• MSSPs and multi-workspace estates: Workspace Manager users, Azure Lighthouse delegations (for Sentinel data in the Defender portal Microsoft points to Entra B2B rather than GDAP with Lighthouse), and workspaces using Private Link (AMPLS) query restrictions.

Finding affected systems and identities

1. List workspaces: enumerate every Sentinel-enabled Log Analytics workspace per tenant, its subscription, owner and data sources, and decide which will be primary.
2. Export content as code: export analytics rules, automation rules, playbooks, workbooks and hunting queries to a repository so changes can be diffed after onboarding. See the Detection as Code Guide.
3. Search automation for breaking conditions: in the exported automation rules and playbooks, look for incident provider conditions, title matches, the Description property and the Microsoft 365 Defender "Updated by" value.
4. Search KQL for breaking fields: find analytics rules, workbooks and saved queries that read SecurityIncident.Description, and Defender custom detections that use IdentityInfo fields that are renamed in advanced hunting.
5. List rule types: flag Fusion, Microsoft security incident creation rules and scheduled rules with incident creation disabled.
6. Inventory access: list Azure RBAC assignments on each workspace, custom roles, table-level RBAC (especially on IdentityInfo), Azure Lighthouse delegations, and every service principal and managed identity that playbooks and integrations use.
7. Check encryption and network: record CMK, Private Link and AMPLS settings, which change what data the Defender portal can show.

For KQL patterns that help with the content search, see the KQL for Threat Hunting Guide.

Migration options

Onboarding choices

Microsoft Learn sets the onboarding roles: Entra Security Administrator, or an unconditional subscription Owner assignment, or User Access Administrator plus Microsoft Sentinel Contributor. With more than one Sentinel-enabled workspace in the tenant, Security Administrator is also required. Changing the primary later is done under System, Settings, Microsoft Sentinel, Workspaces, Set as primary, and the Defender XDR connector moves with it.

Access control

• Azure RBAC continues: Microsoft states that Sentinel access is still managed in Azure RBAC and that changes flow to the Defender portal.
• Unified RBAC is optional per workspace: activation requires Security Administrator plus subscription Owner, or User Access Administrator and Sentinel Contributor, and assigns User Access Administrator to the MTP Unified RBAC app in the workspace. Once enabled it becomes the source of permissions and syncs to Azure RBAC.
• Service principals stay in Azure RBAC: unified RBAC cannot assign permissions to service principals. Keep automation identities on least-privilege Azure roles. See the Azure RBAC and Service Principals Guide.
• Watch for over-visibility: users with broader ARM permissions than unified RBAC permissions may see more Sentinel data, and table-level restrictions on IdentityInfo no longer apply after transition.
• Review first-party app grants: onboarding assigns Microsoft Sentinel Contributor to the Microsoft Threat Protection and WindowsDefenderATP apps in the subscription. Record these as expected so access reviews do not flag or remove them.

Content changes

• Automation rules: replace provider and title conditions with conditions on analytics rule name, tactics or tags; use the Enhanced Alert Trigger for Defender alerts.
• Alert-only rules: enable incident creation, or move the logic to a custom detection, if analysts must see the alerts.
• Correlation: review what Fusion caught and confirm the Defender XDR engine or your own rules cover those scenarios.
• Integrations: move incident sync to Microsoft Graph; note that alertProductNames needs ?$expand=alerts and that incidentUrl still points to the Azure portal.

Testing and rollback

1. Pilot a non-production workspace: onboard a test workspace in the same tenant, run representative detections and confirm incidents, automation and playbooks behave as expected.
2. Allow for delay: Microsoft notes that alerts can take up to 5 minutes to appear after onboarding and automation rules up to 10 minutes to run, so do not judge results immediately.
3. Run both views: until 31 March 2027 the Azure portal remains available, so compare incident counts and automation outcomes in both during the pilot.
4. Onboard the primary in a change window: with on-call analysts briefed on the unified queue and the new incident behaviour.
5. Measure: track incidents per day, automation rule success, mean time to acknowledge and playbook failures for two weeks before and after.
6. Rollback: a workspace can be disconnected from the Defender portal (System, Settings, Microsoft Sentinel, Workspaces, Disconnect workspace). Disconnecting also disconnects the Defender XDR connector, so reconnect it if you still want Defender XDR incidents in Sentinel. Rollback is only possible until the Azure portal retirement date.

Risks of doing nothing

• Forced, untested change: after 31 March 2027 Azure portal users are redirected, so the behaviour changes arrive without the content having been fixed.
• Automation that stops matching: enrichment, assignment and closure rules keyed to providers, titles or Description stop firing, slowing response without an error.
• Lost visibility of alert-only rules: alerts nobody can see in the Defender portal are effectively disabled detections.
• Access creep: the loss of table-level RBAC on IdentityInfo and ARM over-visibility can expose identity data to analysts who were previously restricted.
• Integration breakage: ticketing and reporting that rely on old incident APIs or Azure-created incidents fall out of sync.
• Compressed project: estates with many workspaces or tenants need months to redesign primaries, access and content; starting late leaves no time to pilot.

Framework mapping

Practitioner checklist

• Record the 31 March 2027 date in the risk register and recheck the Learn pages quarterly.
• Pick the primary workspace and document the secondary workspace design before onboarding anything.
• Export all Sentinel content to source control and search it for provider, title, Description and "Updated by" dependencies.
• Fix alert-only rules and replace Fusion coverage before onboarding the primary.
• Review Azure RBAC, table-level RBAC on IdentityInfo and service principal roles; decide whether to activate unified RBAC.
• Move ITSM and SOAR integrations to Microsoft Graph unified incident APIs.
• Pilot in a test workspace, then onboard production in a change window with a written disconnect rollback.
• Train analysts on the unified queue and incident behaviour changes before cutover.

Standards and references

• Microsoft Learn: Transition your Microsoft Sentinel environment to the Defender portal
• Microsoft Learn: Microsoft Sentinel in the Microsoft Defender portal
• Microsoft Learn: Connect Microsoft Sentinel to the Microsoft Defender portal
• Microsoft Sentinel Blog: New timeline for transitioning the Sentinel experience to the Defender portal
• Microsoft Learn: Microsoft Defender XDR unified RBAC
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Microsoft Sentinel Guide · Microsoft Defender XDR · Azure RBAC and Service Principals Guide · SIEM Migration Guide