Role by role, just-in-time access stops scaling somewhere around the tenth role. Groups are the answer, and they are the part of Privileged Identity Management where the constraints are sharp enough to reshape a design: a hard ceiling on how many groups can carry a role, a documented slow path through the workloads people care most about, a door that only opens one way, and a way for an administrator to walk around the whole thing without breaking a rule.
The problem groups actually solve
The previous article ended on a limitation worth restating, because it is the reason this one exists. A PIM policy for a Microsoft Entra role is one policy per role, tenant-wide. Every person eligible for that role gets the same activation window, the same requirements, the same approvers. If two populations need the same role under different conditions, the role policy cannot express it, and no amount of care with the settings page will change that.
There is a second, more mundane problem underneath it. A tier of administration is rarely one role. The person who runs day-to-day identity operations plausibly needs User Administrator, Groups Administrator and Helpdesk Administrator to do their job, and under direct role PIM that is three eligible assignments, three activations before they can start work, three sets of settings to keep aligned, and three things to remember to remove when they change jobs. Multiply by four tiers and you have an estate that is technically just-in-time and practically unusable, which is the state in which people quietly start granting standing access again.
PIM for Groups collapses both problems into one object. A group becomes the unit of privilege: it carries the roles, and people activate into the group. One activation, one policy, one thing to remove. That is genuinely the right shape for most estates past a certain size, and the rest of this article is about the constraints that decide whether it is the right shape for yours.
Two different things that everybody conflates
There are two distinct group properties in play here and most published guidance treats them as one. Separating them is the single most useful thing in this article.
The first is role-assignable. A group can only hold a Microsoft Entra directory role if it was created with that property set, which the portal presents as a toggle asking whether Microsoft Entra roles can be assigned to the group. It is immutable and it is creation-time only. There is no conversion, no supported workaround, no admin who can flip it later. An ordinary group that turns out to need a role has to be recreated, and everything referencing it has to be repointed. Role-assignable groups also carry restrictions that follow from what they can do: membership type must be Assigned rather than dynamic, groups synced from on-premises cannot hold Entra roles at all, creating one requires at least Privileged Role Administrator, and once created only Global Administrators, Privileged Role Administrators, or the group’s own owners can manage its membership and owners. That last point catches automation: through Microsoft Graph, managing these groups needs RoleManagement.ReadWrite.Directory, and the Group.ReadWrite.All permission your existing scripts almost certainly use will not work.
The second property is PIM-managed, and this is the one where the received wisdom is simply out of date. It is widely repeated that a group must be role-assignable to be brought under PIM. That has not been true for some time. Any Microsoft Entra security group and any Microsoft 365 group can be enabled in PIM for Groups, with three exclusions: dynamic membership groups, groups synchronised from on-premises, and groups inside a Restricted Management Administrative Unit. Everything else is fair game.
Role-assignable and PIM-managed are different properties with different rules. Conflating them either scares people away from a capability they have, or has them budgeting a scarce resource they do not need to spend.
The distinction matters commercially as well as architecturally, because it means just-in-time membership is available for far more than directory roles. Access to a sensitive SharePoint site, membership of a group that grants a line-of-business application entitlement, ownership of a group that controls a distribution boundary: all of that can be made eligible and activated on demand, and none of it needs a role-assignable group. Most estates I look at are using PIM for Groups for perhaps a tenth of what it could carry, because they think the door is narrower than it is.
Five hundred, and why it is a budget
A tenant can have at most five hundred role-assignable groups. That is a hard tenant-wide limit, it has not moved, and it is the number to design against. The cap applies only to role-assignable groups; there is no documented cap on how many groups can be PIM-managed, which is exactly the consequence of the distinction above and is stated plainly in the documentation.
Five hundred sounds enormous until you watch how it gets spent. It is spent by treating role-assignable groups as a naming convenience rather than a scarce resource: one per role, then one per role per region, then one per role per business unit, and a couple of years later a large organisation is at three hundred and nobody can tell you which ones are load-bearing. It is spent faster by the fact that the property is immutable, so every mistake is a new group rather than an edit, and the abandoned attempts sit in the count forever unless somebody deliberately cleans them up.
Treat the number as a budget with a named owner. Role-assignable groups should exist for tiers of administration, not for individual roles and not for individual teams. A dozen well-designed tier groups will serve an estate that a hundred badly-designed ones will not, because the design question is how many distinct bundles of authority genuinely exist in the organisation, and the honest answer for almost everyone is a small number. If you find yourself creating the fortieth role-assignable group in a tenant of moderate size, the problem is not the cap.
Which way round: the two layerings
Once a group is both role-assignable and PIM-managed, there are two eligibility axes available and you must choose which one is just-in-time. Microsoft documents both patterns and they behave very differently.
In the first layering, users are active members of the group permanently, and the group holds an eligible role assignment. Membership is static and uninteresting; the role is the thing that gets activated. A user in the group activates the role for themselves, through the ordinary role activation experience, and gets exactly that role for exactly that window.
In the second layering, the group holds an active role assignment permanently, and users are eligible members. Here the group is a standing bundle of authority that nobody is currently inside, and a single membership activation grants everything the group carries at once: every role assigned to it, and also every licence and every application entitlement that membership implies. This is the pattern that makes the tier-group idea work, because it is the one where a single act of activation replaces three or four.
The second layering is the more elegant of the two and it is the one I reach for, with one significant exception that you need to know before you design around it. For roles carrying permissions in SharePoint, Exchange, or the Microsoft Purview portal, Microsoft advises against the second layering, warning that it might take significant time to have all the permissions of the role activated and ready to use, and recommending either the first layering or direct role PIM instead. The SharePoint troubleshooting documentation puts a number on the worst case, and the number is up to twenty-four hours.
A privilege model that takes up to a day to take effect is not a just-in-time model. It is a scheduling problem wearing a security control’s clothes.
Be precise about the scope of that warning, because it is easy to over-generalise into paralysis. The twenty-four hour figure is documented specifically for the path where SharePoint Administrator is reached by activating eligible membership of a group that holds the role. It is not a statement about direct role PIM, and it is not a statement about the directory, which moves in seconds. The design consequence is narrow and clear: bundles that carry directory-facing roles work beautifully under the second layering, and bundles that carry Exchange, SharePoint or Purview authority should either use the first layering or skip groups entirely for those specific roles. In practice this means most estates end up with a tier group for identity and directory work and direct role PIM for the workload administrators, which looks inconsistent on a diagram and is the right answer.
One further wrinkle if you are extending this to Azure. A group holding an eligible Azure resource role assignment produces a double activation: the user activates membership, then activates the role. Two ceremonies for one piece of work is usually a design smell, and the fix is to pick which of the two layers deserves to be the gate rather than gating both.
Nesting, stated correctly
Almost every article on this subject says group nesting is not supported, and in fairness so does one of Microsoft’s own pages, which states flatly that a group cannot be added as a member of a role-assignable group. The PIM documentation is more precise, and the precise version is the useful one. Active nesting into a role-assignable group is indeed blocked: one group cannot be an active member of another group that is role-assignable, so roles do not flow through a permanent nesting. But one group can be an eligible member of another group, and that holds even when one of them is role-assignable. Both statements are live in the documentation at once, which is why this keeps getting repeated wrongly; the group-management page is describing active membership, and the PIM page is describing the case it left out.
The behaviour of that arrangement is the part worth internalising. Activation of eligible membership applies per user, not to the nested group as a whole. Microsoft’s own illustration is exact: if a user is an active member of Group A, and Group A is an eligible member of Group B, the user can activate their membership in Group B, and that activation is only for the user who requested it. The inner group does not become an active member of the outer one, and their colleagues in the inner group are unaffected. That is a genuinely elegant construct, because it lets you express “everyone in the platform engineering group may become a tier one identity operator, one person at a time, on their own clock” without duplicating membership lists. It is also easy to misread as broken when you look at the directory mid-activation and do not see what you expected, which is why knowing the per-user semantics in advance matters more than most nesting trivia.
Two doors, one of which does not close
Two structural facts about PIM for Groups deserve to be design inputs rather than footnotes, and neither is a bug.
The first is that bringing a group under PIM management is a one-way door. Microsoft states it without hedging: once a group is managed, it cannot be taken out of management. There is no un-onboard, no supported reversal. Through the portal the action lives under the Groups view in PIM as a discovery and onboarding step; through Graph there is no explicit onboarding call at all, and a group is silently onboarded the first time you create a schedule request or update its policy, which is a surprising way to make an irreversible change and a very good reason to be deliberate about which groups your automation touches. The policy identifiers also change after onboarding, so a script that cached them will start failing in a way that looks like a permissions problem.
The second is more serious, and it is the hole you have to design around rather than close. Administrators and group owners can still manage these groups through the ordinary Groups experience and other interfaces, overriding what PIM says. A permanent member added through the normal Groups blade is simply a permanent member. PIM does not block it, does not undo it, and the person now holds every role the group carries, standing, with none of the activation ceremony you built. Everything in this article sits on top of a group object that other parts of the product still consider an ordinary group.
There is no setting that fixes this. What you have instead is a combination of three things. Keep the population who can edit these groups genuinely small, which the restricted-management behaviour of role-assignable groups helps with by limiting it to Global Administrators, Privileged Role Administrators and the group’s owners; be extremely careful about who you make an owner, because ownership is the quiet path around the restriction. Watch for it: the same audit discipline that catches a role granted outside PIM catches membership added outside PIM, and a group membership change on a tier group is one of the highest-value alerts in the tenant. And accept the residual risk consciously rather than assuming the product removed it.
Microsoft also raises a specific risk worth repeating because it changes a setting. Where a group is used for elevating into Entra roles, the recommendation is to require an approval process for eligible member assignments, because activation without approval leaves you exposed to a less-privileged administrator: the example named is a Helpdesk Administrator, who has permission to reset an eligible user’s password. The documentation stops there, so let me finish the sentence myself, since the unstated step is the whole point. Reset the password of someone eligible for the bundle, sign in as them, activate, and you hold every role the group carries, having never been assigned any of them. That is a complete escalation chain assembled entirely from legitimate permissions, and the approval gate is what breaks it by putting a second human between a stolen identity and the authority. This is one of the very few places in this wave where I do not treat approval as optional.
What the settings look like from here
Each PIM-managed group carries exactly two policies, one for Member and one for Owner, and they take the same knob set as a role policy: activation duration, what is required on activation including the authentication context, justification, ticket, approval, and the assignment-side expiry controls. Two consequences follow that are easy to miss. Ownership is a privilege in its own right and deserves its own policy rather than inheriting your attention by accident, because an owner can add members and therefore can grant the bundle. And the same scoping trap that applies to roles applies here: never scope the Conditional Access policy backing your authentication context to the group being activated, because during activation the user is not yet a member and the policy will not apply.
The licensing rule is unchanged in substance and worth quoting precisely because it sits on a different page than people look at: every user who is eligible for membership in or ownership of a PIM for Groups must have a Microsoft Entra ID P2 or Microsoft Entra ID Governance licence. Eligible owners count, not just eligible members. There is a sharper licensing edge hiding a few articles ahead, where reviewing these groups turns out to cost more than reviewing roles does, and I will point at it when we get to the operating loop.
The build sheet that follows takes a concrete bundle, a tier one identity operations group carrying three roles, from creation through onboarding, eligibility, activation and validation, including the parts that cannot be undone and therefore have to be right the first time.
Governance
‹ Previous: [PIM 2.1] Build Sheet: Making Entra Roles Eligible
Next: [PIM 3.1] Build Sheet: PIM for Groups End to End ›
