Defender permissions have been a sore spot in most of the tenants I work with. Entra Global Admins or the default Security Administrator roles still get handed out far too often, a leftover from the days when every Defender workload came with its own access model. Defender unified RBAC (role-based access control) changes that. Microsoft has pulled the permissions together, and nearly all Defender workloads are now managed in one place in the Defender portal, with granular scoping and a separation that fits how SOC roles actually work. Security improves, and you also get a clear picture of who can do what, and where.

Unified RBAC lives under the permission settings in the Defender portal

The settings are under Defender portal → Settings → Permissions → Microsoft Defender XDR → Roles. You can import the existing roles from each workload, but keep one thing in mind: unified RBAC must be explicitly enabled for each workload. It doesn't take over on its own (activation details). Once you switch a workload to unified RBAC (Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps, Vulnerability Management), its old role model is deactivated and all permissions are handled centrally. In larger teams this migration is a project of its own, and it needs proper planning.

After setup, you can scope role assignments by user, group, specific device groups or data sources. Your L1 SOC analyst might only see alerts from one server group, for example, while a threat hunter gets much wider access. Compared with the old, coarse Entra roles, that is a big step forward.

Custom roles should mirror your SOC tiers instead of Entra defaults

Defender unified RBAC is deliberately kept apart from Entra role assignments. It was designed for security operations, not identity administration. Roles such as Security Reader, Security Operator or Security Administrator are not mapped automatically. You decide which actions a role may perform in which workload (device management, incident triage, live response, custom detections and so on). That makes it possible to translate your SOC tiers (L1, L2, L3) into custom roles quite precisely:

  • L1: Read-only, triage incidents
  • L2: Can run response actions (device isolation, live response)
  • L3: Full rights for investigations and custom detection rules

The Microsoft documentation on creating custom Defender roles goes into this in detail.

In practice, though, I still see the Security Administrator role assigned far too often, mostly out of habit. That's a risk. The role grants full access and belongs only to your core security admins. Build task-specific roles with tightly limited permissions instead, and keep a record of who has which one.

A single diagram shows how roles, scopes and workloads connect

I usually explain unified RBAC with a diagram that shows how roles, users, scopes and workloads relate to each other:

flowchart TD
  RBACUI["RBAC management"] --> Roles["Defender XDR roles"]
  Roles --> Scopes["Scopes (e.g. device groups)"]
  Roles --> Workloads["Workloads (Endpoint, O365, Identity, Cloud Apps)"]
  Users["Users / groups"] --> Roles
  Roles --> Permissions["Permissions (e.g. incidents, live response)"]

Figure: Unified RBAC in Defender XDR, with central assignment, scoping and workload mapping.

Once the migration is done, you notice the difference right away. Access is cleaner and easier to audit, and troubleshooting or delegating gets much simpler. From an audit and transparency point of view, unified RBAC is a real milestone.

Automation accounts break quietly when you make the switch

Automation and service accounts are easy to break when you turn on unified RBAC. I mean the ones behind playbooks, custom detection rules (see my post) or live response playbooks (see the live response guide). Many of them still run as Security Administrator, some even with global Entra permissions. After unified RBAC is enabled, these accounts need the right Defender roles and scopes assigned explicitly. If they don't get them, their actions fail without any obvious error.

Practical tip: Give automation accounts their own tightly restricted roles. Don't reuse one account across several workloads or tasks. If an automation account is ever compromised, the damage stays limited.

The cleanest approach I know is to put automation accounts into well-scoped Azure AD groups and add those groups to your Defender roles. That keeps things tidy and auditable.

A careful migration prevents permission surprises

On the technical side, moving to Defender unified RBAC is simple. The strategic effort is what people tend to underestimate. Audit all existing workload roles and workflows before you switch anything. Once unified RBAC is enabled for a workload, only Defender roles count and the old workload roles are ignored. So import first, then review and test, and activate last. That order avoids outages and accidental access problems.

Regular access reviews are now easier, and you can automate them with scripts or audit reports. Unified RBAC also has built-in permission testing that lets you simulate how a role will behave (see the docs). For many security teams, the migration is a good opportunity to clean up and tighten all security permissions, particularly in complex organizations with several SOC teams, partners or integrations.

Permissions finally end up in the right hands

For me, Defender unified RBAC is one of the most meaningful improvements Microsoft has made to security operations in recent years. Permissions can now reflect how a SOC really works. They are granular and auditable, and they behave the same across workloads. Blanket Entra Security Admins and murky, siloed permissions can become a thing of the past, provided you take the time to migrate cleanly and review regularly. In my experience, a pragmatic and thorough rollout pays off almost immediately, both for security and for daily work. Everyone involved benefits from that.