Delegation in Entra ID: PIM, administrative units and custom roles

The question always comes in the same form: "The service desk has to be able to reset passwords for its own department, and the line managers have to be able to order access for new hires — but none of them should be administrators." Entra ID has three mechanisms that look like they solve this. None of them does it alone, and the reasons are worth knowing precisely.

PIM governs *when*, not *what*

Privileged Identity Management is a time-control and activation layer on top of role assignments that already exist. It provides just-in-time activation, time-bound access with a start and end date, approval requirements, MFA requirements on activation, justification fields and audit history — for Entra directory roles, Azure resource roles (RBAC) and, via PIM for Groups, membership and ownership in groups.

What PIM does not do is define new permissions. A user who activates Helpdesk Administrator through PIM has, during the activation window, exactly the same permissions as a user with a permanent assignment of the same role. PIM reduces exposure time. It does not reduce the scope of permissions.

The consequence is that PIM solves "too many people hold the permissions all the time", but not "this person shall be able to do exactly one thing". Microsoft's own answer to the latter is entitlement management — access packages with delegated package managers — and not PIM.

License requirements: Entra ID P2 or Entra ID Governance, for eligible users, for approvers, for those who perform access reviews, and for members and owners in PIM for Groups. Known limitations in PIM for Groups: a maximum of 500 role-assignable groups per tenant, no nested groups as active members of role-assignable groups, and neither dynamic groups nor groups synchronized from on-premises AD can be activated in PIM.

Administrative units scope less than people think

An administrative unit (AU) lets you scope a role assignment to a selection of users, groups or devices. It is the right tool for "only my department" — but with four limitations that cause problems in practice:

First, group members are not in scope. If you put a group in an AU, it is the group object that is scoped. The AU administrator can change the group's properties and membership, but not the properties of the individual members — unless the members have also been added to the AU separately. This is the most common misconception.

Second, not all roles can be scoped. Only a defined subset supports AU scope: Authentication Administrator, Cloud Device Administrator, Groups Administrator, Helpdesk Administrator, License Administrator, Password Administrator, Privileged Authentication Administrator, SharePoint Administrator, Teams Administrator, User Administrator and a few others. Azure RBAC roles are not supported at all — AUs apply only to Entra roles. Intune device management is not covered either.

Third, the licensing model is counterintuitive. Creating AUs is free, and the members require no license — but each administrator with an AU-scoped role requires P1, and if you use dynamic membership rules (for example department eq "Logistics"), P1 per member is required. The elegant solution is therefore the expensive one.

Fourth, AUs cannot be nested, and they are not supported together with Entra ID Governance.

Restricted management administrative units are a separate variant that protects objects from everyone except administrators explicitly scoped to the AU — including Global Administrator. Useful, but: the setting is irreversible (it must be set at creation), a maximum of 100 per tenant, only security groups are supported (not Microsoft 365 groups, mail-enabled security groups or distribution groups), and objects in such an AU cannot be managed via PIM, entitlement management, lifecycle workflows or access reviews.

Custom roles give new composition, not new granularity

A custom role is "a collection of permissions that you add from a preset list. These permissions are the same permissions used in the built-in roles". You can compose permissions in new ways and scope them to the tenant, an AU or a single resource (for example one app registration). You cannot create permissions that do not exist.

The clearest example is password reset. The permission microsoft.directory/users/password/update is not available for custom roles. The only password-related permission in the list is microsoft.directory/users/passwordPolicies/update, which applies to policy properties — not the password itself. The wish "can reset passwords only for their own department" can therefore not be built as a custom role. It has to be solved as an AU plus the built-in Password Administrator or Helpdesk Administrator, with P1 for the administrator, and with the additional limitation that password reset under AU scope only applies to non-administrator users.

License requirement for custom roles: P1 per user with an assignment.

The arithmetic

To give twelve team leads and four service desk staff scoped, time-bound and approval-controlled access you need: P1 for each of the sixteen (AU scope and custom roles), P2 or Governance for the approval flow in PIM, P1 for each dynamic AU member if you want to avoid maintaining static lists, and then a setup job with AUs, role assignments and PIM policies per department — which must be maintained every time the organization changes. The list price alone, P2 + Governance, is USD 17 per user per month with an annual commitment.

And after all that, the sixteen are still administrators in the technical sense. They have merely been given a shorter reach.

What this means for Entra Logic

Entra Logic attacks the problem from the opposite end. Instead of giving non-technical roles a scoped administrator role, it gives them no administrator role whatsoever. The service desk, HR and line managers work in the administration portal, see the estate, and submit change requests. The execution engine runs against Microsoft Graph on behalf of the approval — not on behalf of the user's permissions.

That turns delegation into a configuration question in the portal instead of a licensing and role design project in Entra, and it makes granularity independent of which permissions Microsoft has made available to custom roles. Where Entra's own mechanisms are bounded by what Microsoft has exposed, the order flow — a request that carries its own approval and execution — is bounded by what the organization has actually decided.

—

Sources

• Microsoft Learn — What is Privileged Identity Management?
• Microsoft Learn — PIM for Groups
• Microsoft Learn — Administrative units
• Microsoft Learn — Restricted management administrative units
• Microsoft Learn — Custom roles overview
• Microsoft Learn — User permissions for custom roles
• Microsoft Learn — ID Governance licensing fundamentals
• Microsoft — Microsoft Entra pricing