When you onboard a tenant into Microsoft Defender XDR, the first real fork in the road is which permission model you commit to: Unified RBAC or the older legacy per-workload roles. It’s easy to skip past, but the choice changes how you assign access for every workload after it.
The short version
- Unified RBAC gives you one role-assignment surface across Defender workloads, with granular scoping — including per-data-source boundaries for identity data.
- Legacy RBAC keeps each workload’s permissions separate, the way they worked before the unified model existed.
Why the decision is time-sensitive
The ability to deactivate Unified RBAC for a workload only exists for tenants created before Microsoft’s default-enforcement cutoff. Newer tenants are on the unified model by default, and the legacy path simply isn’t available. So before you promise anyone a legacy onboarding, confirm the tenant is actually eligible for it.
A trap worth flagging
Under the legacy model, identity (MDI) access is effectively tenant-wide — you can’t scope it per-domain the way Unified RBAC allows. Endpoint scoping via device groups still works, but if a client declines Unified RBAC expecting fine-grained identity boundaries, that expectation needs correcting up front.
Placeholder article — the details here are illustrative. Verify against current Microsoft documentation before acting on any onboarding.
The takeaway: make the RBAC-model decision explicitly and early, write down why, and check tenant eligibility before you commit a client to a path they can’t easily leave.