Sentinel Defender portal move: runbook and checks

What changed

Learn says that after 31 March 2027, Microsoft Sentinel will no longer be supported in the Azure portal and will be available only in the Microsoft Defender portal. It also says customers using Sentinel in the Azure portal will be redirected to the Defender portal.

Learn’s overview page adds a separate point. New customers who onboard their first Sentinel workspace from July 2025, with Owner or User Access Administrator rights on the subscription, are auto-onboarded. Existing customers who create new workspaces are not.

Where things move, according to the Defender portal page:

Azure portal	Defender portal
Logs	Advanced hunting
Incidents	Investigation & response > Incidents & alerts > Incidents
Settings	System > Settings > Microsoft Sentinel
Analytics	Microsoft Sentinel > Configuration > Analytics, plus Custom detection rules
News & guides	Not available
Workspace manager	Not available

Who is affected

Anyone who uses Sentinel from the Azure portal. Pay closer attention if you have any of these:

• Automation rules or playbooks that trigger on incidents or alerts.
• Automation conditions that use incident titles, the Incident provider property or the SecurityIncident Description field.
• Several workspaces in one tenant.
• Customer-managed keys (CMK).
• Workspace Manager.
• Managed-service access through GDAP with Azure Lighthouse.
• Table-level RBAC on the IdentityInfo table.
• Incidents created by API, by Logic App playbook or by hand.

Licensing is not the blocker. Learn says Sentinel in the Defender portal is generally available, does not need Defender XDR or an E5 licence, and has no extra cost for transitioning. You keep paying for Sentinel consumption as before. If you are reviewing spend anyway, our Sentinel cost control runbook covers tiers, commitment and filtering.

Learn also says that if you onboard Sentinel without Defender services, Exposure Management, custom detection rules and the Action center are limited or unavailable.

Why it matters

The portal changes, but so does behaviour. These are the items Learn calls out that can break things quietly.

Automation

• Automation rules with alert triggers act only on Sentinel alerts. To cover Defender XDR alerts too, Learn points to the Enhanced Alert Trigger.
• The Incident provider condition is removed. Learn says existing rules then run on both Sentinel and Defender XDR incidents.
• Rules that use the SecurityIncident Description field as a condition stop working, because the table no longer has that field. External ticketing integrations such as ServiceNow lose the incident description.
• Incident names might change if correlation is applied. Learn advises against titles as conditions. Use the analytics rule name and tags instead.
• Learn says it can take up to 10 minutes from an alert or incident create or update to an automation rule running. Rapid successive changes to an incident are collapsed into one update.
• In rules, the Updated by value Microsoft 365 Defender is replaced by Other. If Defender XDR was integrated with several workspaces, data goes to the primary workspace only. Learn says to move the relevant rules there.
• Learn lists manually running a playbook on an alert or an entity as not currently supported in the Defender portal.
• Adding alerts to or removing them from incidents is not supported after onboarding, so playbooks cannot do it either.
• To run a playbook on an incident, the incident must be synced to Sentinel first. Until then you may see a “Can’t access data” message and need to refresh.
• You cannot create automation rules directly from an incident. Use the Automation page. Microsoft incident creation rules are not supported in the Defender portal.

Incidents and alerts

• Defender XDR correlation controls alert grouping and incident merging. Learn says the Fusion analytics rule is disabled on onboarding and replaced by that correlation.
• Active Microsoft security incident creation rules are deactivated on onboarding to avoid duplicate incidents.
• Alerts from analytics rules with incident creation turned off are not visible in the Defender portal.
• Incidents created through the API, by a Logic App playbook or manually from the Azure portal are not synchronised to the Defender portal.
• Learn warns that manual merges can combine incidents that were originally kept separate.

Data, keys and tooling

• With CMK, alerts and incidents are no longer CMK-encrypted after onboarding.
• IdentityInfo becomes a native Defender table without table-level RBAC.
• Alert ingestion through the XDR connector is filtered. Defender for Cloud informational alerts are not ingested. Entra ID alerts below High severity are not ingested by default, though you can configure ingestion to include all severities.
• Some fields change when alerts arrive through the XDR connector. The MDE Category property is renamed. The MDO ExtendedProperties.Status value set differs and MDO InvestigationName is not available. For MDI, CompromisedEntity is always the literal string “CompromisedEntity”. Defender for Cloud alert scope changes from subscription to tenant. Review queries, rules and workbooks that use these fields.
• Workspace Manager is not available in the Defender portal. The transition page names content as code and the multitenant portal as alternatives, and describes content as code as public preview. The repository (ci-cd) page labels only custom detection rules as Preview. Learn’s pages differ on this, so check the current status of content as code on Learn before you plan around it.
• Learn says GDAP with Azure Lighthouse is not supported for Sentinel data in the Defender portal, and points to Entra B2B instead.

Multiple workspaces

Learn’s multiple-workspace page says the Defender portal supports one primary workspace and an unlimited number of secondary workspaces per tenant. Another Learn page describes the limit as a single Entra tenant. The primary workspace can be changed.

• Defender XDR alerts and incidents sync to the primary workspace only. Other workspaces previously connected to the Defender XDR connector are disconnected and become secondary.
• Incident creation and alert correlation stay separate per workspace. Secondary workspace incidents do not include data from other workspaces or from Defender XDR.
• Creating custom detections and API queries are limited to the primary workspace. The Workbooks page shows primary workspace data only.
• The standalone connectors for Defender for Office 365, Entra ID Protection, Defender for Cloud Apps, Defender for Endpoint and Defender for Identity are automatically disconnected in secondary workspaces at onboarding. Tenant-based alerts then appear only in the primary workspace. Queries, rules, workbooks and automation in secondary workspaces that rely on them break.
• If you use Insider Risk Management alerts with Defender XDR, Learn says to connect IRM to the Defender XDR connector in the primary workspace before onboarding. Disconnect the direct Microsoft 365 IRM connector from any secondary workspace first.

Roles and permissions

Onboarding needs at least Security Administrator in Entra ID, plus either Owner (unconditional assignment at subscription scope) or User Access Administrator with Microsoft Sentinel Contributor. Our PIM baseline covers running those assignments day to day.

For workspace tasks, Learn splits it like this:

• Connecting or disconnecting a secondary workspace: Owner, or User Access Administrator plus Microsoft Sentinel Contributor.
• Changing the primary workspace, or activating or deactivating a workspace in unified RBAC: at least Security Administrator in Entra ID, plus Owner or User Access Administrator with Sentinel Contributor.

After onboarding:

• Existing Azure RBAC continues to apply. Learn says to keep managing Sentinel roles in the Azure portal, and changes are reflected in the Defender portal. Microsoft Sentinel Reader is enough to view Sentinel there.
• Learn says Microsoft Sentinel Contributor is assigned to the Microsoft Threat Protection and WindowsDefenderATP apps in your subscription. Expect to see those assignments.
• Learn’s role mapping page lists Sentinel Reader as the unified RBAC Reader role. Sentinel Responder maps to Responder, which adds Alerts (manage) and Response (manage). Sentinel Contributor maps to Contributor and Responder, which adds Detection tuning (manage).
• Microsoft Sentinel Playbook Operator, Automation Contributor and Workbook Contributor are not available in unified RBAC. Manage them in the Azure portal.
• Log Analytics granular RBAC can limit read access to specific raw data. Learn says it does not scope access to Sentinel incidents, alerts, watchlists, UEBA or TI.
• Learn warns that once you activate Defender unified RBAC, permissions in the imported roles replace the existing roles in the individual RBAC models. Treat that activation as a separate change.

Runbook

1. Confirm where you stand

   Read your tenant’s Message Center and note which workspaces are already connected to the Defender portal, if any. List every Sentinel workspace and which Entra tenant it sits in. Learn says the Defender portal supports a single Entra tenant.

2. Inventory what will behave differently

   Using the lists above, record:

   • Automation rules that use alert triggers, Incident provider, Updated by, incident titles or the Description field.
   • Playbooks that add or remove alerts on incidents, or that you run manually on alerts or entities.
   • Analytics rules with incident creation turned off.
   • Anything that creates incidents by API, Logic App or by hand.
   • Queries, rules and workbooks that use the changed XDR connector fields.
   • CMK, Workspace Manager, GDAP with Lighthouse, and table-level RBAC on IdentityInfo.

3. Choose the primary workspace

   Pick the workspace that should receive Defender XDR alerts and incidents. If you have secondary workspaces, plan for the connector disconnections described above. If you use IRM with Defender XDR, complete the IRM connector step first.

4. Line up roles

   Make sure the person onboarding holds Security Administrator in Entra ID, plus Owner (unconditional, subscription scope) or User Access Administrator with Microsoft Sentinel Contributor. If you use PIM, check the assignment type against Learn’s “unconditional” wording before the change window.

5. Onboard the workspace

   In the Defender portal go to System > Settings > Microsoft Sentinel > Connect a workspace and follow the prompts.

   If you want to keep Sentinel incident creation behaviour for XDR alerts, Learn describes a Retain Sentinel incident creation behavior for XDR alerts option. It migrates incident creation rules to Defender alert grouping rules during onboarding. Later changes to Sentinel rule grouping are not continuously synced.

   Check the result under Settings > Microsoft Defender XDR > Alert grouping.

6. Fix automation

   Move rules that depended on a secondary workspace to the primary workspace. Replace title-based conditions with analytics rule name and tags. Add the Enhanced Alert Trigger where you need Defender XDR alerts covered. Recreate anything that relied on the Description field. Learn notes that the Active playbooks tab defaults to a filter on the onboarded workspace’s subscription.

7. Sort RBAC deliberately

   Keep managing Sentinel roles in the Azure portal. Map your analysts’ roles to unified RBAC using Learn’s mapping page. Keep the three roles that unified RBAC does not carry in the Azure portal. Decide when, if at all, to activate unified RBAC.

8. Train the analysts

   Learn recommends training on the new interface, because unified triage can need broader analyst knowledge. Show people the new locations for Logs, Incidents, Analytics and Settings.

Checks

• ✓

  Every workspace is listed with its tenant, and the primary workspace is a recorded decision.

• ✓

  Automation rules still fire on a test incident, and you have allowed for the up-to-10-minute delay Learn describes.

• ✓

  No rule depends on the Description field, the Incident provider condition or incident titles.

• ✓

  Alert grouping under Settings > Microsoft Defender XDR > Alert grouping matches what you expected from your old incident creation rules.

• ✓

  Incident grouping, playbooks, routing and ticketing integrations behave as expected, and incident titles that differ from Sentinel have been reviewed.

• ✓

  Queries, rules and workbooks that use the changed XDR connector fields still return what you expect.

• ✓

  Secondary workspaces have been checked for broken queries, rules, workbooks and automation after connector disconnection.

• ✓

  Roles for analysts, engineers and playbook operators work as intended, including the three roles managed in the Azure portal.

• ✓

  API-, Logic App- or manually created incidents have been accounted for, since they do not sync to the Defender portal.

• ✓

  If you use CMK, the loss of CMK encryption for alerts and incidents has been accepted by the data owner.

Rollback

Learn gives a way out for each workspace. In the Defender portal go to System > Settings > Microsoft Sentinel > Workspaces and disconnect the workspace.

• Offboarding also disconnects the Defender XDR connector. Reconnect it if you want Defender XDR incidents back in Sentinel.
• The pages cited here do not say whether items changed at onboarding come back on offboarding. That covers the disabled Fusion rule, the deactivated Microsoft security incident creation rules and the Other value in Updated by. Confirm in Learn before you rely on it.
• Learn gives 31 March 2027 as the Azure portal support cut-off, so treat disconnecting as a way to fix a bad onboarding, not a long-term position.

For repository connections (content as code), removing the connection leaves already-deployed content in the workspace. Content added to the repository after removal is not deployed.

Common pitfalls

• Leaving automation until after onboarding. Rules built on Description, Incident provider or incident titles can stop working or change scope.
• Forgetting secondary workspaces. Standalone connectors are disconnected there and tenant-based alerts appear only in the primary workspace.
• Assuming alerts all show up. Alerts from analytics rules with incident creation off are not visible, and ingestion through the XDR connector is filtered.
• Expecting Azure RBAC to disappear. Learn says it continues to apply. Playbook Operator, Automation Contributor and Workbook Contributor stay in the Azure portal.
• Activating unified RBAC without a plan. Learn says imported roles replace the existing roles in the individual models.
• Relying on GDAP with Lighthouse. Learn says it is not supported for Sentinel data in the Defender portal. Plan for Entra B2B.
• Missing the repository prerequisites. Learn says connecting a repository needs Owner on the resource group containing the workspace, and the account must be in the home tenant. B2B guests and delegated access are not supported. GitHub needs Collaborator access and Actions enabled. Azure DevOps needs Project Administrator and Pipelines enabled.
• Assuming custom detection rules from a repository are free of licence needs. The repository (ci-cd) page says they need Microsoft 365 E5 or equivalent and a workspace onboarded to the Defender portal, and labels them Preview. Repository connections themselves are available in both portals, at Microsoft Sentinel > Content management > Repositories in the Defender portal.