Delegation is the discipline of giving people exactly the authority their job requires and not a scrap more. It sounds like a matter of tidiness, and it is really a matter of blast radius: every role you hand out is a set of actions an attacker inherits if that account is taken, so the width of a role assignment is the width of a breach. Designing roles well is designing how far a compromise can travel.
This is the eighth article in the Entra ID series. The previous one was about when a person may use a privileged role. This one is about what the roles are, how you build narrower ones when the built-in set is too broad, and how you scope authority to a slice of the directory rather than the whole of it.
Two role systems that only look like one
The first thing to hold straight is that there are two separate role systems in play, and conflating them causes a surprising amount of confusion. Entra roles govern the directory: users, groups, applications, authentication policy, the identity plane itself. Azure roles, the ones people mean when they say RBAC, govern the management of Azure resources: subscriptions, resource groups, virtual machines, storage. These are different systems with different data stores and different decision points, and by default an assignment in one says nothing about the other. The single documented bridge between them is deliberate and one-directional: a Global Administrator can elevate to take the User Access Administrator role across every Azure subscription in the tenant, a toggle that exists so an organization can recover control of a subscription that has been orphaned. Knowing that bridge exists, and that it is the only one, keeps you from assuming an Entra role carries Azure power or the reverse.
It is worth adding that several major services carry their own role systems as well, distinct from Entra roles. Exchange, Intune, and the security and compliance portals each maintain their own administrative model, while Teams and SharePoint do read Entra roles. The practical consequence is that governing the identity plane’s roles well does not, by itself, govern those services, and a delegation design has to account for the seams between them rather than assuming one model reaches everywhere.
Start narrow, and count your Global Administrators
Entra ships with more than sixty-five built-in roles, and the sheer number is the point: they exist so that almost no one needs Global Administrator. Microsoft maintains a task-to-role reference that maps common administrative jobs to the least-privileged role that can perform them, and using it is the single most effective habit in this whole area, because it turns the default reflex, reach for the powerful role, into its opposite, find the narrow one. The guidance on the top role is explicit and I hold to it firmly: keep Global Administrator assignments to fewer than five people, keep total privileged assignments modest, and back the whole thing with two cloud-only emergency accounts as described in the previous article. A tenant with a dozen Global Administrators has not distributed authority, it has diluted accountability and multiplied the number of accounts whose compromise ends the game.
Microsoft has also begun tagging which roles and permissions are privileged, meaning they can manage other principals’ access or credentials, so that the genuinely dangerous roles are visible as such rather than buried in an alphabetical list. That tagging is still labeled preview as I write this, so I treat it as a useful signal to inform decisions rather than a finished control to depend on, but the direction is right: the roles that can grant roles are a category apart and deserve to be named.
Sixty-five built-in roles exist for one reason: so that almost no one needs to be a Global Administrator.
Custom roles, and their honest limits
When no built-in role fits, Entra lets you define a custom one from a set of resource actions, and this is the right tool when a team needs a precise and unusual slice of authority, such as managing the credentials of application registrations and nothing else. Two limits keep custom roles honest and should temper any expectation that they can express anything you can imagine. The first is coverage: a custom role can only include permissions that Microsoft has enabled for custom use, and whole categories of action are simply not available, so there are narrow roles you would like to build and cannot. The second is scope: a custom Entra role can be assigned at the level of the whole directory or scoped to a single application-registration resource, which is a real but limited form of targeting. There is also a ceiling of one hundred custom roles per tenant, which is rarely a constraint if you are building them deliberately and a warning sign if you are approaching it. Custom roles are a scalpel, not a printing press, and the discipline is to build the few that genuinely close a gap rather than proliferating one per team.
Administrative units scope authority to a slice
A role assigned without a scope applies to the entire tenant, which is exactly what you do not want for a regional help desk or a business unit’s own administrators. Administrative units are the primitive that fixes this, containers of users, groups, or devices over which a role can be scoped so that its holder manages only what is inside. A User Administrator scoped to one administrative unit can reset passwords for that unit’s members and no one else’s, which is delegation in its cleanest form. Membership can be maintained by hand or, for users and devices, driven dynamically by rules, though not for groups. The caution I always attach is that not every role can be scoped to an administrative unit; only a defined subset supports it, so a delegation design has to confirm that the specific role it wants to hand out actually honors the boundary rather than quietly applying tenant-wide.
The most valuable administrative unit in the current year is the restricted management kind, generally available since the middle of last year, which I described in the tenant-foundations article as the containment boundary for break-glass and tier-zero objects. It inverts the usual assumption: objects inside it cannot be modified even by tenant-level administrators, Global Administrator included, unless the administrator holds a role explicitly scoped to that unit. That protection is genuine and it is symmetric, which is the part that bites the careless. The governance features cannot reach inside it either, so no Privileged Identity Management, entitlement management, access reviews, or lifecycle workflows touch what you place there, and an administrator you enclose cannot have their password reset by anyone outside. Use it for the small set of objects that truly must survive a compromised administrator, and no wider, because everything you gain in protection you lose in manageability.
Groups that grant roles are privileged objects
Delegation often runs through groups, and a group that can be assigned a role is not an ordinary group. It must be created role-assignable through a property fixed at creation and never changed afterward, it cannot use dynamic membership, and it cannot be nested, all for the same reason: any path by which membership could be manipulated indirectly is a path to injecting an account into a privileged role. Only a Privileged Role Administrator can create one, changing the credentials of its members demands an elevated role of its own, and the tenant is capped at five hundred of them, a number you should never approach. Treat these as privileged objects in their own right, because the platform does, and because a role-assignable group is functionally a role you can add people to.
The seam with the endpoint side
This is the point where the identity role model meets the one in the endpoint estate, and the two do not automatically align. Intune runs its own role-based access control, and an administrative unit in Entra does not constrain what an Intune administrator can do inside Intune; the Intune equivalent of scoping is its own roles combined with scope tags, which govern which objects an admin can see rather than borrowing the directory’s boundary. The lesson for anyone designing delegation across both is that the identity plane and the device plane are governed by parallel systems that must be designed to agree, not assumed to. On the endpoint side there is also multi-admin approval, which requires a second administrator to sign off on the most sensitive Intune changes, and it is the device-management counterpart to the just-in-time and review disciplines this series has been describing. The two halves of the seam reference each other precisely because neither one covers the other’s ground.
Roles and their scopes decide what an administrator is allowed to do. They do not, on their own, decide how an ordinary user comes to hold the access they need for their work, or how that access is granted, time-boxed, and taken back. That is governance in the everyday sense, access as a managed object rather than a manual favor, and it is where the series turns next.
Entra ID
‹ Previous: [E 7] Privileged Identity Management in Depth
Next: [E 9] Entitlement Management: Access as a Governed Object ›
