An administrator account is only as dangerous as what it can do at the moment it is stolen. That one sentence is the entire argument for Privileged Identity Management, and it is why the interesting question in a mature tenant stopped being who is a Global Administrator and became who is a Global Administrator right now.
The standing grant is the vulnerability
For most of the history of directory administration, a role was a property of an account. You were an administrator the way you were left-handed: continuously, as a fact about you rather than as a thing you were doing. That model was never examined because for a long time it did not need to be. The account lived on a domain-joined workstation inside a network you controlled, and the perimeter carried the weight. It does not carry the weight anymore, and the assumption underneath it has aged badly.
Think about what a permanently assigned privileged role is actually worth to the two parties who care about it. To the business, it is worth the handful of hours a month the human uses it: a tenant setting changed, a stuck object fixed, a policy shipped. To an attacker, it is worth every second of every day, because the moment they hold the credential they hold the authority, with no further work required. There is no escalation step to detect, no second exploit to catch, no window of clumsy behaviour while they try to get from where they landed to where they want to be. They inherit the whole thing intact. The asymmetry is enormous, and it is created entirely by the fact that the grant is standing rather than by anything about the role itself.
That is the design flaw Privileged Identity Management addresses, and it is worth being precise about which flaw it is, because PIM gets credited with solving problems it does not touch. It does not make the role smaller. It does not stop the wrong person from being assigned. It attacks one variable only: the amount of wall-clock time during which a compromised account carries administrative authority. Collapse that number from permanent to a few hours a month and the value of the credential to an attacker collapses with it, not because the role became weaker, but because the odds that the theft and the activation coincide became small, and because every activation is a deliberate, logged, attributable act that a defender can see.
Eligible and active, and the four states that follow
The primitive PIM introduces is small enough to state in a paragraph, which is part of why the product is easy to underestimate. An assignment is either eligible, meaning the person can hold the role but does not hold it until they activate, or active, meaning they hold it now. Independently of that, an assignment is either permanent or time-bound, so it has a start and an end date. Two axes, four combinations, and every design conversation about PIM is ultimately a conversation about which of the four a given human should sit in for a given role.
Microsoft states the consequence more bluntly than most vendors would, and the sentence is worth internalising: there is no difference in the access given to someone with a permanent versus an eligible role assignment, and the only difference is that some people do not need that access all the time. An activated Global Administrator is a Global Administrator, with every permission the role has ever had. Nothing is held back, nothing is degraded, nothing is scoped down by virtue of having been activated rather than assigned.
PIM does not make a powerful role less powerful. It makes it temporary. Those are two different controls solving two different problems, and a tenant needs both.
I labour this because conflating the two is the most common failure I see in tenants that have adopted PIM enthusiastically. Someone has made forty people eligible for Global Administrator, decided the estate is now least-privileged, and stopped. It is not least-privileged. It is a tenant with forty potential Global Administrators and a slightly better audit trail. The time dimension and the permission dimension are orthogonal, and PIM only moves one of them. Deciding that a person should hold User Administrator instead of Global Administrator is a separate act of design that PIM neither performs nor prompts you to perform, and it is the subject of its own article later in this wave.
One structural limit falls out of the primitive and it catches people building automation. Eligible assignments cannot be created for applications, service principals, or managed identities, for the simple and unarguable reason that those identities cannot perform the activation steps. A non-human identity can hold a time-bound active assignment, which is a genuinely useful thing and materially better than a permanent one, but it cannot be eligible. If your mental model of PIM is “everything becomes just-in-time,” the automation estate is where that model breaks, and the answer there is a different set of controls: tight scoping, credential hygiene, and workload identity protections rather than an activation ceremony nobody is present to perform.
Activation is a small ceremony, and the ceremony is the product
An eligible user who needs the role requests activation and chooses a duration up to the maximum the role allows. Depending on how that role has been configured, they may have to supply a business justification, a ticket reference, a fresh authentication challenge, or the approval of a named human, and they can schedule the activation to begin at a future time rather than immediately. PIM then creates a real, temporary, active assignment, and removes it when the clock runs out or when the user deactivates by hand. That is the whole mechanism.
Two guardrails sit around it that are worth knowing before they surprise you. An assignment cannot be created for a duration shorter than five minutes, and an assignment cannot be removed within five minutes of being created. The second one is the one that generates support tickets: a user who activates by mistake and immediately tries to tidy up cannot, and will conclude the product is broken. It is not broken, it is refusing to let assignment churn happen faster than the directory can honestly reflect it.
Which brings me to the part of PIM that is least well covered and most likely to embarrass you in front of a client. Activation is not instant in the way the word suggests. Microsoft is careful here and says the active assignment is created within seconds, which is true and also not the number that matters. The number that matters is when the workload the admin is trying to administer notices, and that depends entirely on the workload. The directory itself is quick. Applications cache role state, and the documented remedy is the unglamorous one: sign out and sign back in. Exchange, SharePoint and the Purview portal are slower still, and in one specific group-based pattern the documentation quantifies the worst case at up to twenty-four hours, which I will come back to when this wave gets to PIM for Groups.
Design around this rather than arguing with it. A one-hour activation window on a role whose workload takes twenty minutes to acknowledge the change is not a one-hour window, it is a forty-minute window with an irritated administrator at the front of it. That single piece of operational honesty does more to make a PIM rollout survive contact with users than any amount of policy elegance, and it is why the activation durations I recommend later in this wave vary by role rather than being set once and applied everywhere.
The gap that closed this spring
Everything above has been broadly true for years, and it is the reason so much PIM content reads as settled. It is not settled. The most important thing that has happened to this product in a long time happened in April 2026, and it changes what an activation can be made to cost.
Until recently, the strongest thing the role settings could demand at activation was multifactor authentication, and that demand was softer than it looked. Microsoft’s own documentation concedes it: users might not be prompted for multifactor authentication if they authenticated with strong credentials or provided multifactor authentication earlier in the session. The claim from the morning sign-in is reused. In practice that meant an attacker who had phished a session and inherited a satisfied MFA claim paid nothing extra to activate Global Administrator, and the setting that was supposed to be the last gate was a comfort blanket. I have watched competent architects design around that gate without realising it was not holding anything.
The fix is now generally available. Conditional Access enforcement on PIM activation went GA in April 2026, which means a role’s activation can be bound to a Conditional Access authentication context, and the policy targeting that context can demand a phishing-resistant credential, freshly presented, every single time. The consequence is architecturally interesting rather than merely incremental: the credential that unlocks Global Administrator can now be a different and stronger thing than the credential that started the workday. A user who signed in with a password and an Authenticator push can be forced through a security key before the directory will let them become an administrator, and a stolen session token does not carry that.
Elevation is now something you can charge a real price for. Until this spring, the price was whatever the user had already paid that morning.
That capability is the centre of gravity for this whole wave, and it gets a doctrine article and a full build sheet of its own further down. I raise it here because it should change how you read every piece of PIM guidance published before this year, including guidance I wrote. Most of it predates the change or still describes the feature as preview, and it therefore treats the activation gate as weaker than it now has to be.
What the licence buys, and the sentence that shapes the rest of this pillar
PIM requires Microsoft Entra ID P2 or Microsoft Entra ID Governance, and the licensing model is more forgiving than people expect once they understand what is being counted. Licences are pooled and count-based rather than enforced per user: Microsoft’s wording is that users do not need to be assigned a licence, but there need to be as many licences as there are member users in scope. Scope means five categories, and they are worth knowing precisely because two of them surprise people. Users with eligible or time-bound assignments to Entra or Azure roles count. Users who are eligible or time-bound members or owners of PIM-managed groups count. Users who can approve or reject activation requests count, even though they never activate anything themselves. Users assigned to an access review count, and users who perform one count. Microsoft publishes worked examples on the licensing page and they are the clearest way to sanity-check a purchase: fourteen eligible users plus three approvers requires seventeen licences, and forty-two eligible plus five approvers plus six reviewers requires fifty-three.
Read the lapse behaviour before you build anything on this, because it does not fail the way a security control ought to. If the licences go away, eligible assignments are removed, ongoing role access reviews end, PIM settings are removed, and PIM’s emails and alerts stop. Meanwhile, active time-bound assignments become active permanent, and permanent assignments are untouched. Put plainly, a licensing lapse does not revoke privilege, it makes privilege permanent and silences the machinery that was watching it. That is a fail-open behaviour sitting underneath a control you are relying on to fail closed, and it belongs on the risk register of anyone running PIM in a tenant whose subscription true-ups are handled by a different team than the one running identity.
There is one more licensing fact, and it is the one that determines the shape of this entire pillar rather than just this wave. Microsoft’s stated position is that no new Identity Governance and Administration features or capabilities will be added to the Microsoft Entra ID P2 SKU. P2 is frozen. Everything in this wave, all of it, is P2: PIM for roles, PIM for Groups, the Conditional Access activation controls, and access reviews of Entra and Azure role assignments. Everything that comes after it in identity governance, and one sharp edge inside this wave that I will point at when we reach it, lands in the Governance SKU or the Entra Suite instead. That is not a complaint. It is a planning fact, and it means the honest way to write about this subject is to be explicit at every step about which side of that line a capability sits on.
What this wave covers
This article opens a new pillar on the site. Governance is the category, and it will grow to hold access reviews, entitlement management, lifecycle workflows and eventually the data governance material, each arriving as its own wave with its own prefix. Privileged Identity Management is wave one because it is the piece with the most immediate security return and because the ground under it moved this year.
The argument runs in five movements. First the assignment model itself: what the per-role settings actually control, why the three-way choice at activation matters more than anything else on the page, and how approval design and expiry mechanics fit together, followed by the build sheet that takes a tenant from standing assignments to a working just-in-time estate for its first role set. Then groups, which is how this scales past a handful of roles and which carries constraints sharp enough to reshape a design: a hard ceiling on role-assignable groups, a documented slow path for the Exchange and SharePoint workloads, and a way for an administrator to walk around PIM entirely through the ordinary Groups experience. Then the activation control itself, the passwordless elevation story, in doctrine and in a build sheet that is the most useful thing in this wave. Then the role model that decides which assignments should exist at all, including the two accounts that are deliberately left standing, permanent, and outside the machine. And finally the operating loop, because a just-in-time estate that nobody reviews decays back into a standing one within a year, quietly, through exceptions that each seemed reasonable.
Azure resource roles get their own article in the middle of that, because the same discipline applied to Azure RBAC has a different administrative surface, different scoping rules, and one operational tax that catches everyone: role settings there are per role and per resource, with no inheritance down the scope tree. The wave closes with a decision piece on where PIM’s responsibility genuinely ends and what the next waves of this pillar have to pick up.
If you arrived here from the Intune deployment guide, the earlier article on PIM architecture and build remains live and remains a reasonable entry point from that context. This wave is the deep treatment: it goes further on every axis, it is current on the April 2026 change, and it is where I will keep the material up to date. Start with the assignment model, because every other article in the wave assumes its vocabulary.
Governance
Next: [PIM 2] The Assignment Model: Roles, Settings, and the Shape of an Activation ›
