Delegation in Intune is two questions asked separately: what an administrator is allowed to do, and which objects exist for them at all. Most tenants answer the first question carefully and never ask the second, and for years the platform itself blurred them further by quietly merging permissions across role assignments. That last part is finally being fixed, and the fix changes how you should design delegation from now on.
This article extends the Phase 2 identity foundation into the question of who administers the endpoint estate itself. It is also one half of a seam. The Entra series covers roles, custom roles, and delegated administration on the identity plane, and this piece covers the device plane, because the two are parallel systems that must be designed to agree rather than assumed to.
Two role systems meet at the console
Intune runs its own role-based access control, distinct from Entra’s directory roles, and the first design decision is which system your administrators actually live in. A small set of Entra roles carries Intune power from the outside: Global Administrator and Intune Administrator hold full read and write across the service, and a handful of security and reader roles hold read access, with Security Administrator also carrying full control of the Endpoint Security node. Microsoft’s guidance here is blunt and matches my own practice: do not use Global Administrator in Intune, and do not use the Intune Administrator role for day-to-day administration either. Assign built-in or custom Intune roles instead. The reason is not just least privilege in the abstract. Entra roles bypass Intune’s visibility controls entirely, so an administrator holding one sees everything no matter how carefully you have partitioned the console, and the two powerful roles can change everything they see. Every person you keep out of those roles is a person your partitioning actually applies to.
Inside Intune’s own system, the built-in roles cover the recognizable jobs: Policy and Profile Manager, Application Manager, Help Desk Operator, Read Only Operator, Endpoint Security Manager, the Endpoint Privilege Management pair, School Administrator, and, in tenants with a Windows 365 subscription, a Cloud PC Administrator and Reader. Built-in roles cannot be edited, and when none fits, a custom role can be built from any Intune permission. One built-in role deserves special respect: Intune Role Administrator is the only Intune role that can assign permissions to other administrators, which makes it the delegation-of-delegation role and a privileged object in its own right, exactly as the Entra side treats Privileged Role Administrator.
The anatomy of an assignment
A role by itself does nothing; the design lives in the assignment, and an Intune role assignment has three working parts. Members is the security group of administrators receiving the role. Scope groups define which users and devices those administrators may manage, and the reflex to resist is selecting all users and all devices when the admin should only reach a region or a business unit. Scope tags are the third part and the least understood: they control which objects, the policies, profiles, and apps themselves, the administrator can see. The cleanest way I know to hold the distinction is that roles decide what an administrator may do, scope groups decide to whom they may do it, and scope tags decide which configuration objects exist in their view of the console at all.
Two properties of the model shape everything you build on it. There are no deny permissions; access is purely additive, so anything an administrator should not have must simply never be granted, because nothing can subtract it later. And the whole apparatus runs on security groups, not on the directory’s administrative units. An administrative unit that partitions the Entra directory does not constrain what an Intune administrator can do in Intune, which is precisely the seam the Entra article describes from the other side. If your delegation story assumes the identity boundary carries into the device console, it does not, and the two must be built to match by hand.
Roles decide what an administrator may do. Scope groups decide to whom. Scope tags decide what exists in their console at all.
Scope tags in practice
Scope tags reward a little study because their defaults are full of quiet consequences. Every untagged object that supports tagging carries the default tag automatically. When an administrator creates an object, all of their own tags are stamped onto it, which keeps their work visible to themselves and is also how tags propagate without anyone thinking about it. An administrator whose role assignment carries no scope tags does not see less; they see everything, because no tags effectively means all tags, and that inversion has surprised every team I have watched adopt tagging midway. Administrators can only apply tags they themselves hold, can only target groups listed in their own scope groups, and cannot strip the last of their own tags off an object. Tags can also flow to devices automatically by group membership, and those automatic assignments overwrite manual ones. The ceilings are one hundred tags per role and one hundred per object, a few object types do not support tags at all, Autopilot devices and corporate device identifiers among them, and creating or deleting the tags themselves requires the Entra Intune Administrator role, which is one of the few legitimate reasons to elevate into it.
The merged-permissions problem, and its fix
Here is the flaw that has lived in this model for years. When one administrator holds multiple role assignments that share a permission category, Intune has historically merged the permissions across them. Give a team read-only rights over mobile apps scoped to headquarters, and full create-and-delete rights over mobile apps scoped to a regional office, and the merge quietly grants full rights in both places. The read-only intent for headquarters simply evaporates. Every consultant who has designed regional delegation has either tripped over this or unknowingly shipped it, because the console gives no hint that the assignments are bleeding into each other.
In March 2026 Microsoft shipped the fix as an opt-in public preview called Scoped permissions. With it enabled, each role assignment’s permissions stay contained to its own scope tag context, and administrators get exactly the access each assignment intended, no more. Two things about it demand planning rather than enthusiasm. First, enabling it is a one-time tenant action that cannot be undone, so it belongs in a change window with eyes open, not in a Friday experiment. Second, the practical effect is a permission reduction for anyone who was benefiting from the merge, which is why Microsoft ships a Permissions Assessment Report that previews, admin by admin, exactly which permissions would narrow before you commit. Run it, communicate the reductions, then flip the switch. And design for the new world regardless of when you enable it, because Microsoft has said that at general availability scoped behavior becomes the default for every tenant. The merged behavior is not a quirk to work around anymore; it is a deprecated assumption.
The seam, and the habits that keep it honest
A few surrounding facts complete the design. Just-in-time privilege composes with all of this: you can run Privileged Identity Management over the Entra Intune Administrator role for the rare tasks that genuinely need it, or, more usefully, run PIM for Groups over the security group that is the member of an Intune role assignment, so that eligibility and activation govern the endpoint console the same way the PIM architecture article described for the directory. For managed service providers, remember that cross-tenant delegation through GDAP lands the partner in Entra roles in the customer tenant, and Entra roles bypass scope tags, so a partner admitted that way is outside the partitioning no matter how disciplined the tags are. Watch the audit log’s role category for assignment changes, since auditing is always on and role changes are exactly the moves a compromised account makes first. None of this is license-gated beyond core Intune; RBAC, scope tags, and the scoped-permissions preview are all part of the base service.
Delegation bounds what each administrator can reach on their own. It says nothing about the changes that are dangerous no matter who makes them, the script pushed to every device, the role assignment widened at midnight. For those, Intune has a control that assumes the administrator themselves might be the problem, and requires a second signature before the change applies. That is Multi-Admin Approval, and it is the next article.
Intune Deployment Guide · Phase 2: Identity and Tenant Foundation
‹ Previous: [2.5.2] Cloud Kerberos Trust: On-Prem Reach for Entra-Native Devices
Next: [2.7] Multi-Admin Approval: The Second Signature ›
