Privilege is the one thing in a directory you want people to have and not hold. The whole idea of Privileged Identity Management is to separate being entitled to a powerful role from actually possessing it, so that the standing state of even your administrators is ordinary, and power is something they reach for deliberately, briefly, and on the record. Get that separation right and a compromised admin account is, most of the time, a compromised account with no active privilege attached.
This is the seventh article in the Entra ID series. The endpoint series already introduced this ground in its Privileged Identity Management article, and that piece remains the right entry point. This one goes deeper into the model, the settings that actually shape it, and the design decisions that separate a real just-in-time program from a checkbox.
Eligible and active are the whole idea
Everything in PIM rests on one distinction. An active assignment is a role you hold and can use with no further action. An eligible assignment is a role you are permitted to activate when you need it, through a just-in-time step that grants the permissions temporarily. The important and slightly counterintuitive fact is that the access these two produce is identical; a person with an active Global Administrator assignment and a person who has just activated an eligible Global Administrator assignment can do exactly the same things. The only difference is time. One holds the power continuously; the other holds it for a bounded window and is otherwise an unprivileged account. That difference in duration is the entire security value, because it shrinks the span during which a stolen session or a coerced admin is actually dangerous from always down to sometimes.
Both kinds of assignment can be made permanent or time-bound with start and end dates, which gives you a second axis to work with. The target state for almost every privileged role is eligible rather than active, and time-bound rather than permanent wherever a role is genuinely temporary. The deliberate exception, which I will come back to, is the small set of accounts that must always work.
Three surfaces, one model
PIM applies the same eligible-and-active model to three different kinds of power, and it is worth being clear that they are distinct systems governed by one mechanism. PIM for Entra roles governs the directory roles, the Global Administrators and User Administrators and their kind. PIM for Azure resources governs the resource-management roles, scoped anywhere in the Azure hierarchy from a management group down to a single resource, with the small operational quirk that once activated, an assignment there cannot be deactivated for five minutes. PIM for Groups governs the membership and ownership of groups, and it is the one that repays the most thought, because a single group can front many roles at once. Make a group eligible in PIM and one activation can light up everything that group confers, which is powerful and also a concentration of blast radius you should place consciously. Two constraints bound it: a group carrying an Entra role must be role-assignable, and the tenant ceiling on role-assignable groups is five hundred; and dynamic-membership groups and on-premises-synced groups cannot be brought under PIM for Groups at all, because their membership is authored somewhere PIM does not control.
The activation step is where the policy lives
An eligible assignment does nothing on its own. Its value is realized only at activation, which is exactly why the activation settings are where the real security design happens rather than in the assignment itself. For each role you decide how long an activation lasts, from one to twenty-four hours, and the shorter you can make it without generating constant reactivation friction, the tighter the window of exposure. You decide whether activation requires multifactor authentication, whether it requires a written justification, and whether it requires a ticket number, with the honest caveat that the ticket field is recorded but not validated against any system, so it is a discipline and an audit breadcrumb rather than an enforced control. And you decide the heaviest lever, approval, where activation is held until a named approver signs off.
Approval is genuinely strong and it carries two costs that have to be designed around. It adds latency, because a human now stands between the administrator and the role, so it belongs on the roles where a few minutes of delay is an acceptable price and not on the ones needed to respond to an incident in progress. And it introduces a lockout failure mode that has caught careful teams: if a role requires approval, but no approver is configured and the only people who could serve as default approvers are themselves merely eligible rather than active, there may be no one able to approve, and the role becomes unactivatable. Configure at least two approvers, deliberately, for anything gated this way. Beyond these, activation can be tied to a Conditional Access authentication context, which lets the elevation event itself demand a specific authentication strength or a compliant device, and this is the mechanism that makes the phrase phishing-resistant privilege real, because the act of becoming an administrator can be made to require a phishing-resistant credential every time.
An eligible assignment does nothing on its own. The activation step is where the security actually lives.
The system watches the privilege it manages
PIM does not only broker activation; it also observes the privileged estate and raises alerts about its own health. It will tell you when there are too many Global Administrators, when roles are being assigned outside PIM through some side door, when privileged accounts have gone stale without signing in, when administrators never actually activate the roles they hold, and when roles do not require multifactor authentication to activate. Read as a set, these alerts are a standing critique of your privilege hygiene, and they are most of what a monthly review of the tier needs. Alongside them, access reviews integrate directly with PIM so that eligible and active privileged assignments can be recertified on a schedule, with recommendations that lean on whether the person has signed in recently and an auto-apply option that removes what the reviewers decline. Privilege that is granted once and never revisited is how directories accumulate the quiet, forgotten administrators that every assessment eventually finds, and the reviews are the countermeasure.
Licensing, and a mandate that changed the backdrop
PIM, in all three of its forms, is licensed by Entra ID P2 or by the Entra ID Governance product, and the model is per-user rather than tenant-wide: you need enough licenses to cover everyone who holds an eligible or time-bound assignment, plus the approvers and the reviewers. There is a strategic wrinkle worth stating plainly, because it shapes where new capability will appear. The classic PIM features remain on P2, but Microsoft has said that net-new identity-governance capability lands only in the Governance stock keeping unit, and not in P2. So P2 is a stable floor that will not grow, and the governance-heavy future of this area lives behind the Governance license. Design with an eye to which side of that line the capabilities you are counting on actually sit.
One change in the surrounding platform is worth folding in because it interacts directly with PIM. Multifactor authentication is now mandatory for the administrative portals and, in its second phase, for the command-line and programmatic control paths, with no exceptions for any account. That partly overlaps PIM’s own require-MFA-on-activation setting at the portal boundary, but it does not make it redundant, because the mandate secures reaching the console while PIM’s setting secures the specific act of elevation, and it is the elevation you most want bound to a strong credential. The two are layers, not substitutes.
The accounts that must always work
Every good just-in-time design needs a deliberately excepted corner, and the exception is the emergency access accounts. Microsoft’s guidance, which I follow without hesitation, is to keep a small number of cloud-only break-glass accounts permanently assigned Global Administrator, held out of PIM eligibility and excluded from the Conditional Access policies that could otherwise block their sign-in, so that a failure in the machinery that governs everyone else cannot lock the organization out of its own tenant. Those accounts still carry a phishing-resistant credential, because the mandatory multifactor requirement now reaches even emergency access, but they are kept clear of the conditional logic that could deny them entry in a crisis. The goal I aim for is zero standing active assignments for every role except those emergency accounts. That single sentence is most of the target state: the whole administrative population eligible and just-in-time, the tier reviewed and alerted on, elevation bound to a strong credential, and two accounts held back from all of it so there is always a way in when the rest fails.
PIM decides when a person may wield a role. It does not decide what the roles themselves are permitted to do, or how you carve the directory so that most administrators never need a tenant-wide role at all. That is the work of the role model and delegation, and it is where the series goes next.
Entra ID
‹ Previous: [E 6] Identity Protection: Risk as a Signal
Next: [E 8] Roles, Custom Roles, and Delegated Administration ›
