How do MSSP analysts get Sentinel and Defender access across GDAP tenants after Unified RBAC auto-enablement?

Reviewed by ContraForce team · Updated 2026-09-04

> Microsoft Defender Unified RBAC will auto-enable on tenants starting late September 2026 and completing by December 2026, importing existing roles with a 30-day notification period before activation. GDAP grants access to Defender data only and is not supported for Microsoft Sentinel data, so a delegated relationship alone does not give analysts Sentinel visibility.

What is changing, and when?

Message Center notice MC1457836, published 19 August 2026 and tagged a major change with admin impact, states that Microsoft Defender Unified RBAC (URBAC) becomes the single access model for Defender and Sentinel portal experiences, and that tenants will be auto-enabled.

The published sequence is: rollout begins late September 2026, each tenant receives a 30-day notification before activation, existing roles are imported at activation, and the rollout completes by December 2026. Opt-out is available after activation, not before it. Other Microsoft permissions are unchanged.

For a provider, the operative detail is that this arrives per tenant on a rolling schedule rather than all at once. A book of 100 customer tenants sees 100 separate 30-day windows spread across roughly three months.

Why does GDAP not carry Sentinel access?

Granular Delegated Admin Privileges is the Microsoft delegated access model for CSP partners, and it reaches Defender data. It does not reach Sentinel data. Microsoft states this directly in the multitenant management requirements: "GDAP is not supported for Microsoft Sentinel data, and provides access to Defender data only."

The reason is architectural rather than a gap waiting to be closed. GDAP grants Microsoft Entra directory roles in the customer tenant. Microsoft Sentinel is an Azure resource governed by Azure role-based access control on the Log Analytics workspace beneath it, which is a different authorisation plane. A directory role does not resolve to a workspace permission.

Two consequences follow for a delegated estate:

• Sentinel data access runs through Microsoft Entra B2B guest access rather than GDAP. Microsoft's own requirements page directs partners to B2B for this.
• Cross-tenant Sentinel queries additionally require Azure Lighthouse, and that holds inside the Defender portal, not only the Azure portal. Microsoft documents that running cross-tenant queries on Sentinel data, such as the `workspace()` operator in advanced hunting and analytics rules, means setting up Azure Lighthouse.

What does this mean for tier 1 and tier 2 analysts?

Tier 1 and tier 2 break differently, because they depend on different authorisation planes.

A tier 1 analyst working the queue needs Defender incident access, which GDAP provides. If that analyst also needs the Sentinel incidents or the logs behind them, the GDAP relationship does not carry it, and the analyst sees a partial picture without an error explaining why.

A tier 2 analyst hunting across customers needs cross-workspace query, which is the Lighthouse requirement rather than the GDAP one. Multitenant advanced hunting also caps the result set: Microsoft documents that the result from each individual tenant is capped at 50,000 divided by the number of tenants queried, so a hunt across 50 tenants returns 1,000 rows per tenant regardless of what matched.

What should you do in the 30-day window?

The 30-day window is the only period in which the change is both known and not yet applied, so the work is inventory rather than remediation.

• Record who holds what today, per tenant, across GDAP relationships, B2B guest accounts, and any Azure Lighthouse delegations. Activation imports existing roles, so an accurate before state is the only way to tell what changed.
• Identify analysts whose access depends on a workspace-level assignment rather than a directory role. Those are the assignments most likely to behave differently once URBAC is the access model.
• Confirm which tenants are reachable for Sentinel at all, since a tenant with a GDAP relationship and no B2B path has no Sentinel access to preserve.
• Decide the opt-out position before activation, because opt-out only becomes available afterwards. A tenant that must not change during a customer's audit window still activates on schedule.

How do you run analyst access across every tenant without rebuilding it per tenant?

Every access model above is per tenant by construction. GDAP relationships are established per customer, B2B guests are invited per directory, and Lighthouse delegations are scoped per subscription. A provider operating a hundred customers maintains a hundred instances of each, and a platform change like URBAC activation arrives a hundred separate times.

The alternative is an operating layer that holds its own identity and role model, so an analyst is granted a role once and that role resolves against every connected customer environment. ContraForce works this way: analysts, roles, and approval gates live in the platform, and the connection into each customer tenant is a scoped Microsoft Entra enterprise application consented per module rather than a per-analyst delegated identity. Access changes are made once and apply everywhere, and a Microsoft-side access-model change lands in one place rather than in every tenant's role assignments.

That does not remove the need for delegated access to exist. It removes the need for analyst permissions to be modelled tenant by tenant on top of it.

Sources

• MC1457836, Tenant will be auto-enabled into Microsoft Defender Unified RBAC, Microsoft 365 Message Center, published 19 August 2026
• Microsoft Defender multitenant management requirements
• Multitenant advanced hunting
• Microsoft Defender Unified RBAC