Privileged Identity Management answers one question extremely well and several adjacent questions not at all. This closes the wave with the decisions worth defending, an honest account of where the model stops, and a map of what the rest of this category has to pick up. The most useful thing I can leave you with is the list of problems you should stop trying to solve with this product.
Three estates, three stopping points
Not every tenant needs everything in this wave, and knowing where to stop is worth more than knowing how to build all of it.
The first estate stops at direct role PIM. It has a small administrative team, a handful of privileged roles that matter, and no meaningful Azure control plane. Convert Global Administrator and Security Administrator to eligible, give them deliberate windows and approval, bind activation to an authentication context with a phishing-resistant strength, build the two emergency access accounts properly, and run a quarterly review. That is genuinely finished. It is perhaps two days of work including the credential rollout, it removes the majority of the standing-privilege risk in the tenant, and adding groups on top of it would add maintenance without adding control. A surprising number of organisations belong here and are being sold a larger project.
The second estate needs groups, and the tell is not size but structure. If your administration divides into recognisable tiers, where a person’s job implies three or four roles rather than one, then per-role eligibility is producing three or four activations before anybody can start work, and that friction will be routed around eventually. Build tier groups, put the gate on membership, and accept the constraints: role-assignable groups are capped at five hundred and their key property is immutable, onboarding is one-way, and administrators can still add permanent members through the ordinary Groups experience. Keep Exchange, SharePoint and Purview roles out of the bundles for the documented propagation reason, which produces a design that looks inconsistent and is correct.
The third estate extends into Azure, and here I would be more decisive than most: if you have production subscriptions, do subscription Owner and User Access Administrator regardless of whether you have done anything else. It is a small piece of work, those two roles are the ones that can destroy or re-grant everything, and the newer integration into Access control means your platform engineers never have to visit an identity blade to live with it. Just go in knowing the two things that differ: settings are per role and per resource with no inheritance down the scope tree, so concentrate policy at as few scopes as your delegation model allows, and your security function cannot see any of it by default, which is a visibility gap worth closing on day one.
The posture I will defend
A few positions from this wave are worth restating as positions, because they are where I differ from the common advice and I would rather be argued with than vague.
Activation windows should vary by role and should be set against how the workload behaves, not chosen once and applied everywhere. An hour for the tenant-wide roles, because that work is bursty and specific. Two for the investigative and workload-facing roles, because they take longer to get going and because the permissions take longer to become usable. A working day for the shift-shaped helpdesk roles, because an eight-hour window produces one activation per shift and a one-hour window produces six activations and a workaround. The instinct to make every window as short as possible is the instinct that gets just-in-time access quietly abandoned.
Approval belongs only where a second human adds signal. That means the tenant-wide roles, the roles that can rewrite the controls, and any group that bundles directory roles, where an unapproved membership activation completes a real escalation chain. It does not belong on the roles a service desk uses forty times a week, because an approver who has learned to click yes without reading is not a control, they are a delay with a governance label on it. And whatever you gate, name your approvers explicitly, because the silent fallback to active Privileged Role Administrators and Global Administrators makes the answer to “who approved this” depend on who happened to be looking.
Every control in this wave is a tax on the people doing legitimate work. Charge it where the risk is, and nowhere else, or they will find a way not to pay it.
Never trust a default you have not read in your own tenant. Microsoft does not publish the out-of-box values for activation duration or assignment expiry, and it does not publish the defaults for the alert thresholds either. The numbers circulating in articles, including the ones I would have repeated a year ago, are unsourced. There is also a live, unreconciled contradiction between the portal documentation describing the activation slider as running from one to twenty-four hours and the Graph documentation stating that activation is always time-bound to a maximum of eight. Read the policy. Write down what you find.
And the one I would argue hardest for: replacing the on-activation multifactor requirement with an authentication context is worth more than everything else in this wave combined. Not because the other work is unimportant, but because until you do it, every gate you have built can be satisfied by a session that was authenticated hours ago, which is precisely the thing an attacker has.
What this model does not solve
PIM governs administrative privilege in Entra and Azure, held by humans, over a time dimension. Everything outside that description is somebody else’s problem, and the failure mode I see most often is an organisation stretching this product across problems it was never shaped for.
It does not do entitlement. The question of who should have access to which application, which SharePoint site, which line-of-business system, requested by the person who needs it and approved by somebody who understands the resource, is a different machine entirely. You can approximate a little of it with PIM-managed groups, and I have, but you are building a request-and-approval workflow out of a just-in-time elevation tool and it shows quickly.
It does not do joiner, mover, leaver. Nothing here notices that somebody changed department, and the eligible assignment they held for their old job survives the move perfectly. The expiry dates from this wave are a backstop against that, not an answer to it; they catch the problem within six months rather than at the moment it happens.
It does not do non-human identities. Eligible assignments cannot be created for applications, service principals or managed identities, because they cannot perform an activation. In an Azure estate that is a large fraction of all privileged access, and it needs a different set of controls entirely.
It does not do guest lifecycle, and it does not touch data. A guest who can activate a role is governed here; the question of whether that guest should still exist is not. And nothing in this wave has an opinion about the documents, the labels, or the data those privileges reach.
What the rest of this category picks up
Those gaps are the map of the Governance pillar, and each becomes a wave in this same category.
Access reviews as a general capability come next, because this wave used only the privileged-access corner of them. The broader feature covers groups, applications and access packages, and it is where the review-of-everything-else story lives, along with the machine-learning-assisted recommendations that sit on the Governance side of the licensing line.
Entitlement management is the entitlement answer, and it has already grown a bridge back into this wave that is worth knowing about now. Access packages can assign eligible membership and ownership of PIM-managed groups, generally available since November 2025. Read that carefully, because it changes the shape of what you built: the tier group from the earlier build sheet can be requested through a self-service access package with its own approval workflow and its own expiry, and what the requester receives is eligibility rather than access. Request-and-approve on the outside, just-in-time on the inside. That is the combination that makes a large estate work, and it needs the Governance licence rather than P2. The same capability reached Azure role assignments in public preview in May 2026, governing eligible and active assignments at management group, subscription and resource group scope, which is the direct answer to the Azure conversion problem this wave could only solve by script.
Lifecycle workflows are the joiner-mover-leaver answer, and Purview is where the data governance material eventually lands, which is the point at which this category stops being about identity at all.
One licensing observation ties all of it together and it is the thread to hold. Microsoft’s stated position is that no new identity governance features will be added to the Entra ID P2 SKU. Everything in this wave is P2. Almost everything in the waves after it is not. That is not a complaint, it is a planning fact, and it means the honest way to scope any of this work is to be explicit at each step about which side of the line a capability sits on. The sharpest example is already inside this wave: reviewing the role assignments held by a PIM-managed group is P2, and reviewing the membership of that same group is not. Expect more seams exactly like it. Worth knowing too that the licensing landscape has grown a floor and a ceiling around this: the Entra Suite bundles ID Governance with Private Access, Internet Access, ID Protection and Verified ID, Microsoft 365 E7 now includes the whole of ID Governance through that route, and guest users touching Governance-exclusive features bill per monthly active user through a linked Azure subscription, a linkage that has been enforced since January 2026. P2 features are not billed that way.
The watchlist
Six things I am watching, offered so you can watch them too rather than rediscover them.
The activation-duration contradiction between the portal documentation and the Graph documentation is unreconciled and out-of-box defaults remain unpublished across the board. Until one of those changes, reading your own tenant is not diligence, it is the only available method.
PIM for Groups has no alerting. This is documented rather than merely absent: the alerts API is beta and covers Entra roles only. The group is simultaneously the object that bundles several roles into one activation and the object with a documented bypass through the ordinary Groups experience, so the gap is meaningful and the monitoring is yours to build until it closes.
The Azure mobile app supports activation for Entra roles and Azure resource roles, does not appear to support PIM for Groups, and nothing documents how it behaves when an activation is bound to an authentication context. If your administrators elevate from phones, that is an untested path through your strongest control, and I would find out before relying on it.
Protected actions compose beautifully with PIM and their release status is genuinely contradictory, with the feature’s own overview reading as generally available and another current page still describing it as preview. It is the right control for protecting Conditional Access policy management, which is the soft underbelly of everything in this wave, so the ambiguity is worth tracking.
Two dates are already on the calendar. The second-iteration beta API stops returning data on the twenty-eighth of October 2026, and the failure is silent: reports keep running and return nothing. And the credential landscape moves under all of this, with passkeys becoming the default sign-in experience on the first of September 2026 and Microsoft-provided SMS and voice delivery retiring on the first of February 2027, after which a user whose only method is SMS or voice will be required to register a passkey during sign-in, with no opt-out. That last change quietly does a lot of this wave’s work for you, since it pushes the whole estate toward the credentials the phishing-resistant strength actually accepts.
And the one I find most interesting. Agent identities are becoming a governed object class in their own right, with a dedicated Microsoft licensing vehicle covering entitlement management for agents and service principals, lifecycle workflow tasks for agent sponsorship, and sponsors acting as approvers. The reason it belongs on a PIM watchlist is structural rather than commercial: the central limitation of this entire wave is that eligibility requires somebody present to activate, which is exactly why non-human identities cannot hold it. If autonomous agents are going to hold real privilege, something has to answer that question, and it will not be this product in its current shape. That is the interesting problem in this space over the next couple of years.
The argument, in one paragraph
Standing privilege is the risk, because a compromised account is only as dangerous as what it holds at the moment it is stolen. Eligibility is the design response, and it costs nothing in capability because an activated role is the same role. Groups are how that scales past a handful of assignments, with real constraints that shape the design rather than decorate it. The activation itself is where the control finally became serious this year, because it can now demand a credential the attacker does not have rather than one they inherited. The role model decides what should exist at all, and deliberately leaves two accounts outside the whole machine, watched more closely than anything else in the tenant. And the operating loop is what stops all of it decaying, quietly, through exceptions that each seemed reasonable.
None of this makes an administrator less powerful. That was never the goal, and a design that tries to achieve it produces an estate where nobody can do their job and everybody has a workaround. What it changes is the shape of the target: from a standing set of credentials that are always worth stealing, to a small set of deliberate, logged, attributable acts that cost something to perform. That is a smaller and much less interesting thing for somebody to attack, and it is achievable in a fortnight in most tenants.
If you have read the wave and want a starting point, it is not the interesting one. Go and read the role settings for Global Administrator in your own tenant and write down what they say. Almost everything else in these articles follows from being unhappy with what you find there.
Governance
‹ Previous: [PIM 7.1] Build Sheet: Access Reviews for Privileged Roles
