AzureFeeds

Co-authored with Lizet Pena, Caroline Mutua, Alvin Kua and Marco Sudahl

Governance is the silent dependency every transition trips on. Read about how roles, data tiering, and multi-tenant operations evolve in Defender, and why each change unlocks something your old model could not.

Detection engineers debate KQL. Architects debate roles. The Defender transition is interesting because it updates to simply both – but the governance changes are the ones that quietly determine whether your unified SOC actually works the way you designed it on the whiteboard.

The good news: everything is normal on day one. Your existing Azure RBAC assignments keep functioning. Your Sentinel data stays where it is. Your MSSP delegations remain intact. What changes is what is now possible: data-scoped permissions that are not tied to a single workspace, a tiered data model that lets you keep years of history without keeping years of analytics-tier cost, and a multi-tenant view that spans up to 100 customer tenants with a single sign-in.

This post walks through each governance shift, what carries forward, and what is genuinely new—from the perspective of the architect who has to sign off and the SOC lead who has to operate it.

What this post covers

• Roles and personas: who owns what after the transition


• From classic Azure RBAC to Unified RBAC (URBAC): coexistence, then convergence


• The data lake as a governance construct: tiering, retention, residency


• Multi-tenant management and the MSSP operating model


• Persona implications, common misconceptions, and a do-this-week checklist

Roles and personas: nothing breaks on day one

Transitioning to Defender does not eliminate existing Azure RBAC assignments – all continue to function. Once URBAC is activated, it becomes the source of permissions/authorization. The unified platform introduces a new permissions model: Microsoft Defender XDR Unified RBAC (URBAC), which can coexist with or replace classic Azure RBAC for Sentinel access.

Once URBAC is enabled in Defender, URBAC becomes the source of permissions and not Azure RBAC. It is preferred to migrate the classic Sentinel roles to URBAC ones after onboarding the log analytic workspaces.

Before transitioning, SOC leads and identity administrators should review the full role matrix and persona assignments and understand which personas require updated assignments. Customers can import roles using the import wizard; this way there is no need to create URBAC roles manually.

Why URBAC is the upgrade: URBAC is data-scoped + cross-workspace, not tied to a single workspace boundary. Another benefit of migrating to URBAC is the use of Sentinel scoping with row-level RBAC. And finally, it allows you to manage all of your roles and permissions in a single holistic access management system.

Persona-by-persona view

• Security analysts – Triage and investigate incidents using the unified incident queue; require the Security Operator unified RBAC role. Entra global roles are not required for incident triage across Defender and Sentinel—a custom Defender unified RBAC role provides the necessary permissions with more granular scoping.


• Security engineers – Build detections, manage content, and onboard data; require Sentinel Contributor (see mapping with URBAC). For SOAR tasks, roles such as logic app Contributor and Microsoft Sentinel automation Contributor can still be managed and assigned to Security engineers using Azure RBAC


• SOC managers / architects – Plan RBAC strategy and map existing Azure RBAC to URBAC; govern least-privilege access across workspaces


• Automation – Execute playbooks and automation rules; the roles related to automation (Microsoft Sentinel automation Contributor, logic app Contributor, Microsoft Sentinel playbook Operator) post-transition are not yet supported through URBAC, but can still be managed using Azure RBAC


• Service principals – Service principals are currently not supported in URBAC; assigning permissions to a service principal or GDAP user group is planned to go public preview soon. Do not enable URBAC if service principals are in use in Microsoft Sentinel in the Azure portal.

Why this lands well: Day One continuity for every existing role assignment, with a clear path to a more capable model. You choose when to flip URBAC on, the import wizard does the heavy lifting, and you get data-scoped, cross-workspace permissions you never had in classic Sentinel.

Azure RBAC and URBAC: coexistence, then convergence

The transition does not force a permissions cutover. Sentinel permissions currently configured keep working exactly as they do today. You can also use URBAC for Sentinel permissions, ensuring you can manage your access management for Defender and Sentinel in a single holistic access management system. Once you turn URBAC on, it becomes the source of truth for permissions instead of Azure RBAC.

How they compare

Transition considerations

• Onboard the log analytics workspaces first, then move the classic Sentinel role assignments to URBAC


• Use the import wizard rather than re-creating URBAC roles manually—it preserves your existing assignment intent


• If you rely on service principals for any Sentinel access (CI/CD, automation, integrations), please be aware that these are not yet supported in URBAC. The import wizard will detect this and will import the roles, but not assign them to service principals. If the role only includes service principals in the assignment, it can’t be imported. Track the URBAC roadmap and plan accordingly, this support will be available soon. You can continue to configure these in Azure RBAC for now, even when URBAC is enabled.


• Keep automation-related role assignments in Azure RBAC—they are not supported through URBAC today.


• When you enable URBAC and assign roles, they are synchronized back to Azure as well. For example, a Sentinel Reader role created in URBAC will also create the role in Azure RBAC. If you then change the role in Azure RBAC (instead of on URBAC), it can create a sync issue. Disabling and enabling the workspace on URBAC will resolve the issue. This does not affect scenarios where Azure RBAC is the only source of permissions (logic apps for example), but it is something to be aware of.


• Take advantage of row-level RBAC and cross-workspace scoping where you previously had to compromise.

Why this lands well: You get a more capable permissions model without a forced cutover. Classic roles keep working, the import wizard handles the migration, and the new data-scoped model finally matches the way modern SOCs think about access.

Sentinel data lake as a governance construct

All data ingested into the analytics tier (log analytics workspace) is automatically mirrored into the Sentinel data lake tier when Sentinel data lake is enabled, ensuring a single authoritative copy of security data that can be queried using KQL, notebooks, and advanced hunting tools without duplicating ingestion pipelines.

Security architects should use Sentinel data lake for historical threat hunting, retroactive IOC matching, compliance retention, and AI-assisted investigations, while keeping latency-sensitive detections and alerts in the analytics tier. Use the Sentinel cost estimator to calculate your environment’s need and refer to the pricing table to know more.

What the data lake gives you

• Supports interactive and async KQL queries across all connected Sentinel workspaces.


• Query external data sources without moving data (Public Preview), including Microsoft Fabric, Azure Databricks, and Azure Data Lake Storage Gen2.

Transition considerations

• Sentinel data lake must be provisioned in the same Azure region as the primary Sentinel workspace and is not available in all regions—check the latest geographical availability and data residency.


• When Sentinel is accessed through Defender, processed and configuration data may follow Defender regional processing, which can differ from the log analytics workspace region.


• Customer-managed keys (CMKs) are not supported for data stored in the Sentinel data lake; Microsoft-managed keys are used.


• Compare the analytics tier and data lake tier when sizing your retention strategy.

Region availability note: Sentinel data lake is not available in all Azure regions. Validate availability for your primary workspace region before planning enablement—the supported regions list is the authoritative reference and is updated as new regions come online.

Why this lands well: You finally separate “hot” detection data from “warm/cold” investigation data without rebuilding pipelines. One copy of the truth, two tiers, KQL across both—and a clear regional/governance story you can take to your data protection officer.

Multitenant management and the MSSP operating model

MSSPs and large multitenant enterprises have always had to stitch together Lighthouse, GDAP, and per-workspace navigation. Defender does not eliminate those building blocks—but it does add a unified cross-tenant view that genuinely simplifies day-to-day operations.

Azure portal versus Defender for multitenant

Transition considerations

• Maintain Lighthouse: Do not remove existing delegations—Lighthouse is still required to access Azure resources such as Azure policy and function apps.


• 100-tenant limit: Large MSSPs may need multiple MTO configurations or prioritize active tenants. MSSPs can also leverage tenant groups to organize tenants collectively and switch multitenant view between groups. Microsoft hasn’t published a timeline for raising this ceiling—monitor the Defender XDR release notes for updates


• Tenant-boundary isolation: Correlation engine operates within tenant boundaries—incidents never merged across tenants.


• Playbook distribution gap: Automation rules and playbooks (logic apps) are not currently supported as distributable artifacts through MTO content distribution profiles, but you do have the ability to run logic apps hosted on “home tenant” to run on “target tenant” without deploying the artifact.

Where partners and MSSPs add value

Managed security service providers (MSSPs) and Microsoft partners bring specialized expertise in planning and executing Sentinel transitions to Defender. Partners accelerate your transition timeline, reduce operational risk, and ensure your team maximizes the value of unified security operations from Day One.

Key advantages of working with a partner:

• Transition expertise: Partners have hands-on experience transitioning multiple customer environments and can anticipate challenges specific to your industry, architecture, and security maturity level.


• Multi-tenant complexity: MSSPs managing Sentinel for multiple customers can navigate enhanced GDAP delegation, Azure Lighthouse configurations, and cross-tenant workspace management.


• Accelerated onboarding: Partners provide structured onboarding programs combining technical setup, SOC analyst training, and workflow optimization to minimize time to value.


• Custom automation development: Partners can develop logic apps playbooks, custom analytics rules, and hunting queries tailored to your environment and threat landscape.


• Ongoing optimization: Post-transition, partners offer SOC optimization services leveraging the enhanced capabilities in Defender including AI-powered recommendations, cost management, and detection coverage gap analysis.

To find Microsoft partners specialized in Sentinel and Defender, visit partner.microsoft.com or consult your Microsoft account team for recommendations.

Why this lands well: A single cross-tenant view that does not force you to abandon what you have. Lighthouse + GDAP + MTO each do a different job, and the unified incident queue across tenants is the kind of capability MSSPs have been asking for.

Persona implications

Clearing up common misconceptions

• “Turning on URBAC breaks my existing Azure RBAC assignments.”
  No. Classic Sentinel roles continue to function. URBAC becomes the source of permissions once enabled, but it can be migrated from your existing assignments using the import wizard.


• “I have to move my Sentinel data into the data lake.”
  No. Data ingested into the analytics tier is automatically mirrored into the data lake when the lake is enabled—a single authoritative copy, no duplicate ingestion.


• “MTO replaces Azure Lighthouse for MSSPs.”
  No. MTO and Lighthouse coexist—Lighthouse is still required for Azure resource access (Azure policy, function apps); MTO provides the unified cross-tenant SOC view.


• “If I enable URBAC, my logic apps playbooks break.”
  No. Automation-related roles (logic app Contributor, automation Contributor, playbook Operator) keep working under Azure RBAC.


• “Data lake is available everywhere Sentinel is.”
  No. The data lake must be in the same Azure region as the primary Sentinel workspace and is not available in all regions—always check the geographical availability list before planning.


• “MTO will merge incidents across tenants.”
  No. The correlation engine operates within tenant boundaries—incidents are never merged across tenants. MTO provides visibility and operational consistency, not cross-tenant correlation.

Do this week

• Inventory who holds which classic Sentinel role (Reader, Responder, Contributor, Automation roles) and which identities are service principals.


• Defer URBAC enablement and document the dependency if any service principals hold Sentinel access.


• Stand up a test URBAC scope using the import wizard—validate that analyst, engineer, and architect personas see what you expect.


• Confirm your primary Sentinel workspace region is on the Sentinel data lake supported regions list.


• Decide the analytics tier versus data lake tier split: which tables you want hot for detection and which you want warm for hunting/compliance.


• Map your existing Lighthouse + GDAP footprint to the MTO model if you operate multi-tenant, and identify tenants for an initial MTO configuration (under the 100-tenant cap).


• Schedule the transition planning session now if you work with an MSSP or Microsoft partner to compress weeks of work and surface issues you would otherwise find in production.

Continue the series

Each part of this series stands alone—pick the angle that matters most to you or read them in order.

Part 1 – Beyond a portal move: The strategic shift to Defender

Why the transition matters at the architecture and program level—the executive framing, the deadline, and the analyst validation.

Part 2 – Anatomy of the change: Incidents, alerts, correlation, and data

The component-level mechanics: how the XDR correlation engine replaces Fusion, why incidents are no longer alert-centric, and what changes (and doesn’t) in your data architecture.

Part 3 – Detection and automation, reimagined

How analytics rules, playbooks, workbooks, and hunting evolve—and why the toolbelt doubled, not shrank.

Part 5 – Your readiness playbook: Adoption helper, costs, APIs, and the checklist

A practical plan: the Defender adoption helper, cost reality, API strategy, and the migration checklist.

Part 6 – The AI-first SOC: Copilot, UEBA, threat intelligence, and SOC optimization

The destination: how Security Copilot, UEBA, threat intelligence, and SOC optimization combine into a fundamentally different operating model.