Who can see what: Sentinel & Defender permissions, untangled

The permission model in the unified portal isn't harder than what it replaced — it's more layered, and the layers answer different questions. The trouble is that nobody tells you there are three of them, so you grant someone a role that feels sweeping, they open the portal, and half of it is greyed out. Untangling it starts with naming the three systems and, more importantly, knowing which one is the authority for which surface.

01The three systems, and what each governs

Microsoft's own framing: the Defender portal unifies three RBAC systems that continue to coexist. Which one is the authority depends entirely on the surface — and on whether you've activated the new model.

The baseline is gentler than the diagram suggests: if you connect Sentinel to the Defender portal and do nothing else, your existing Azure RBAC permissions carry across unchanged, and a SIEM-only team with no Defender XDR and no data lake has no permission work to do. The layering only starts when your needs go past that — XDR access alongside Sentinel needs Entra roles or URBAC; the data lake needs URBAC; row-level scoping needs URBAC.

02The switch that changes who's in charge

Until you activate Unified RBAC for a workload, the legacy model applies. Activate it, and that workload is fully governed by URBAC — with two consequences people don't expect.

Unified RBAC for Sentinel SIEM went to public preview in April 2026, and it's opt-in and per-workspace. Activation lives at System → Permissions → Roles → Activate workloads, where you pick which Sentinel workspaces to enable. Do it, and URBAC becomes the primary source of permissions for that workspace, replacing Azure RBAC. Two things bite here:

03"Why can't they see it?" — the matrix

Five real personas against the surfaces of the portal. Every ✗ below is a genuine, documented gap that generates a ticket — and the footnotes say exactly why.

1 — Sentinel's minimum is the Azure RBAC Sentinel Reader role. Without it the Sentinel menu isn't even visible in the Defender portal, no matter what Defender access the Entra role grants. This is the single most common "I have access but can't see Sentinel" ticket.
2 — The data lake is an independent layer: it always needs a Defender Unified RBAC role, regardless of your SIEM permission model.
3 — A workspace-scoped Sentinel role grants nothing on Defender XDR workloads — those need an Entra role or a URBAC role. Sentinel access ≠ XDR access.
4 — URBAC's whole point is granularity: a custom role scoped to Endpoints leaves Email, Identities, and Sentinel dark. Scope is a feature, and the greyed-out sections are it working.
5 — Under URBAC, Global Admin gets no automatic Sentinel workspace access — only the right to assign it (including to itself). The old "GA sees everything" reflex is gone for Sentinel.

04Turning it on without locking yourself out

Activation is a few clicks; the discipline is importing and validating first, and remembering what URBAC still doesn't cover.

You need Global Admin or Security Admin in Entra to activate. From System → Permissions → Roles, use Activate workloads, toggle each workload one at a time, and for Sentinel choose View Workspaces and select which to enable. Before you flip anything, use Microsoft's import function — it recreates your existing Azure RBAC (and per-workload) roles inside URBAC automatically, so you validate a mirror of what you already have rather than rebuilding from scratch. Check every person maps to the role and scope you expect, then activate.

05The MSSP angle: many tenants, one clock

If you operate across client tenants, this lands on all of them — and the multi-tenant access story is mid-transition.

Two things matter across a fleet of tenants. First, auto-enablement hits every one of them on Microsoft's schedule, so the move from "we'll standardise RBAC eventually" to "URBAC is on in this client next month" is not yours to defer — the win is getting ahead of it with a consistent, imported, least-privilege role model you apply per tenant. Second, cross-tenant access is changing: Entra B2B remains the generally-available path for reaching Sentinel data in a client's Defender portal, and a new Defender-native GDAP model (consent-based, three-step handshake) is in preview for delegating both Sentinel and Defender from one place. The older Azure Lighthouse GDAP integration still does not surface Sentinel data in the Defender portal — though Lighthouse itself is very much alive for cross-workspace KQL and Azure resource access. And once URBAC is active, row-level scoping lets several teams share one workspace while each sees only its slice — the capability that finally makes shared-workspace multi-tenancy defensible.