Privileged Identity Management (PIM): just-in-time admin, done right
The most dangerous thing in your tenant isn't an unpatched server — it's the ten people carrying Global Admin they use twice a year. PIM makes privilege something you switch on when you need it and lose when you don't.
New to cloud? CAMPUX is a free, build-first course. Start here →
The core of PIM is one move: make privileged roles eligible instead of permanently active, so admins hold ordinary rights until they activate a role — with MFA, a justification, an expiry, and approval for the highest roles. Add recurring access reviews to stop privilege creep, keep the number of Global Administrators tiny, extend PIM to Azure resource roles and groups, and keep monitored break-glass accounts outside it. Everything else is tuning; the risk reduction is in removing standing access.
Standing privilege is the quiet liability in most tenants. Every account that permanently holds an admin role is a full compromise waiting for one phished session — and the more of them there are, the wider the door. PIM (it needs Microsoft Entra ID P2 or Microsoft Entra ID Governance) flips the default from "you're an admin all the time" to "you can become an admin, briefly, when the work needs it and the system agrees." Here's how to run it well.
What is Privileged Identity Management?
Privileged Identity Management (PIM) is the Microsoft Entra service that grants just-in-time, time-bound access to privileged roles. A user is made eligible for a role rather than holding it outright, then activates it when the work needs it — with MFA, a justification, approval and an expiry. It covers Entra roles, Azure resource roles and groups.
You will see the idea written a dozen ways — privileged identity and access management, privileged access management, PAM. Those name the general category: controlling what admin accounts can do, and when. PIM is Microsoft's implementation of that category inside Entra, and it applies to three things: Microsoft Entra roles (the directory roles, built-in and custom), Azure resource roles (the RBAC roles on management groups, subscriptions, resource groups and resources), and PIM for Groups (eligible membership or ownership of a security group, which is how one activation can reach permissions across several services at once).
Why use it at all? Without PIM, an admin holds the role every hour of every day, whether or not they are using it. One phished session is then a full compromise, and nothing in the tenant records that a human decided to be an admin at 2am on a Sunday. With PIM the elevation is deliberate, short, and written down.
How PIM works: the activation workflow
Four steps, and each one is somewhere to put a control:
- Assign. An administrator gives a user or group an eligible or an active assignment at a chosen scope, either permanent or with start and end dates. That is four combinations: permanent eligible, permanent active, time-bound eligible, time-bound active. Service principals cannot be made eligible, but they can hold a time-limited active assignment.
- Activate. The eligible user asks for the role, picks a duration up to the maximum you set, and states why. This is the self-service part — the person elevates themselves, inside rails you built, without waiting on someone else to hand them a role.
- Approve or deny. If the role requires approval, the named approvers get an email and decide. An approver does not need to hold the role themselves.
- Expire. The role falls away on its own at the end of the window. The user can request an extension before it expires, or a renewal after — both need an approval.
Every one of those events lands in the PIM audit history, which holds the last 30 days for Entra roles, Azure resource roles and PIM for Groups. Export it monthly if you need to keep more than that.
Who can do what is not the same on both sides of the house:
| Who | What they can do in PIM |
|---|---|
| Privileged Role Administrator or Global Administrator | Manage assignments and role settings for Microsoft Entra roles |
| Security Administrator, Global Reader, Security Reader | View assignments to Microsoft Entra roles |
| Subscription administrator, resource Owner, User Access Administrator | Manage assignments for Azure resource roles |
| Approver | See pending requests and approve or deny them — no role of their own needed |
| Eligible user | Request activation, check the status, use the role until it expires |
Note the asymmetry: a Privileged Role Administrator does not, by default, get to see Azure resource role assignments in PIM. Whoever owns the subscription does.
That is the mechanism. The rest of this is the practices — seven of them, in the order they matter.
1. Eligible, not active — the whole point
PIM has two kinds of assignment, and the entire benefit lives in choosing the right one:
| Active assignment | Eligible assignment | |
|---|---|---|
| Holds the role | Always (standing access) | Only after activation |
| Attack window | 24/7 | Minutes, when activated |
| Use for | Almost nothing | Nearly every privileged role |
Make privileged roles eligible. An eligible admin spends the day as an ordinary user, so a stolen session usually can't touch anything privileged — the attacker would still have to activate the role, and that's where your controls sit.
2. Put real controls on activation
Activation is the gate. Configure each role's PIM settings so switching a role on isn't free:
- Require MFA on activation — always.
- Require a justification, so every elevation has a written reason in the log.
- Require approval for the highest-impact roles (Global Administrator, Privileged Role Administrator) — a second person signs off.
- Short activation window — a few hours, not a day; the role expires on its own.
- Tie a ticket number in the justification where you can, so elevations reconcile against real work.
The activation maximum duration is a slider, one to 24 hours. Microsoft's own deployment example sets one hour for Global Administrator, two for Exchange Administrator, eight for Helpdesk Administrator. Two honest caveats. The ticket-number field is information only — nothing reconciles it against your ticketing system, so treat it as a prompt for the audit trail, not a control. And a user who already passed MFA earlier in the session may not be prompted again; if you want fresh proof at the moment of elevation, use require Conditional Access authentication context with an authentication strength instead of the plain MFA toggle, and set that policy's sign-in frequency to every time.
Now a compromised account cannot silently become admin: it has to pass MFA, state a reason, and sometimes wait for a human — and whatever it does is time-boxed and recorded.
If every Global Administrator and Privileged Role Administrator assignment is eligible rather than active, approval is required to activate, and no approvers are named, then nobody is left who can approve anything and the tenant is locked. Name at least two specific approvers per role, and keep the emergency access accounts described below.
3. Least privilege — and very few Global Admins
PIM makes privilege temporary; least privilege makes it small. Prefer a specific role (User Administrator, Exchange Administrator) over Global Administrator for day-to-day work, and keep the number of Global Admins deliberately tiny — Microsoft's guidance is fewer than five. Entra shows an alert card on the overview page once you have five or more. There is a second number worth knowing: Microsoft also recommends fewer than 10 privileged role assignments in total, and warns on the roles page above that. Every one of those accounts is a top-value target, so the fewer eligible, the smaller the prize.
4. Run access reviews so privilege doesn't creep
Eligibility granted once tends to live forever. Access reviews fix that: schedule recurring reviews where a role owner confirms each person still needs their eligible assignment, and remove the ones no longer justified. Without reviews, your "small" set of eligible admins quietly grows every reorg until it isn't small anymore.
5. Cover Entra roles, Azure resources, and groups
PIM isn't only for directory roles. Use it for Azure resource roles (Owner/Contributor on subscriptions and resource groups) so infrastructure privilege is just-in-time too, and for PIM for Groups to make membership of a powerful group activatable. If a static RBAC role assignment grants standing Owner on a subscription, that's the same standing-privilege problem this whole article is about — make it eligible. (New to the RBAC roles themselves? See Owner vs Contributor vs Reader.)
6. Leave break-glass accounts permanently active — and watched
PIM is a dependency. If activation itself is unavailable, nobody can elevate. So keep at least two emergency access (break-glass) accounts, and treat them as the one deliberate exception to everything above:
- Cloud-only accounts on the
.onmicrosoft.comdomain, not synced or federated from on-premises. - In PIM, their Global Administrator assignment is permanent active, not eligible. This is the one place standing privilege is the right answer.
- Phishing-resistant credentials — a passkey (FIDO2), or certificate-based authentication if you already run a PKI — and a different method from the one your everyday admin accounts use.
- Excluded from the Conditional Access policies that block or restrict sign-in. Report-only policies need no exclusion.
- Alerted on every sign-in, with a post-mortem after each use.
- Tested at least every 90 days, so you find out they work before you need them.
They are the manual override for the day PIM cannot help you. The monitoring is what keeps that override safe.
7. PIM implementation: what a rollout actually includes
Turning PIM on is a five-minute job. Implementing it is a project, and the order matters, because the failure mode is locking your own admins out of production. Here is what a PIM implementation includes, start to finish.
Requirements first. PIM needs Microsoft Entra ID P2 or Microsoft Entra ID Governance licenses — not for the whole tenant, but for every user with an eligible or time-bound assignment, every user who can approve or reject an activation, and everyone who reviews or is reviewed in an access review. If those licenses lapse, eligible assignments are removed outright and time-bound active assignments turn permanent, which is the opposite of what you built.
- Discover. List who holds privileged roles today. Remove the assignments nobody can justify before you make any of them eligible — migrating dead access into PIM only launders it. Access reviews will do the discovery for you.
- Decide the scope. Global Administrator and Security Administrator first, because those do the most damage when compromised. Use the PRIVILEGED label on the roles page to find the rest. On the Azure side, put every subscription Owner and User Access Administrator under PIM, then work outward by how much each resource would hurt.
- Draft the role settings before you open the portal. One row per role: MFA, Conditional Access context, notification, ticket, approval, who approves, activation duration, and whether any permanent admin remains. That table is your privileged access policy — get it signed off, then configure to match. It is also the document an auditor asks for.
- Pilot. A small group, every setting verified, before anyone else is affected.
- Communicate. Tell people what changes, when, and who to call. Walk internal IT support through the activation workflow before their first ticket about it, not after.
- Test with test users. Write the expected behaviour per role — prompts for MFA, approver gets the mail, role expires on time — and check the actual result against it.
- Roll out in slices. For Entra roles, most organizations do Global Administrators first. For Azure resources, one subscription at a time.
- Turn on the monitoring. Security alerts for suspicious activity, one named person reading the audit events weekly, an export monthly.
- Schedule the access reviews so the set you just cleaned up stays clean.
Microsoft's own example settings give you a sane starting shape:
| Role | MFA | Approval | Ticket | Activation |
|---|---|---|---|---|
| Global Administrator | Yes | Yes — another Global Administrator | Yes | 1 hour |
| Exchange Administrator | Yes | No | No | 2 hours |
| Helpdesk Administrator | No | No | Yes | 8 hours |
That Helpdesk row is Microsoft's illustration, not our advice: require MFA on every role you manage. The cost is one prompt.
And keep the rollback in your pocket. If PIM misbehaves in production, select the ellipsis next to an eligible assignment and choose Make active. That is the whole retreat — which is why it is safe to start.
Permanent admin is a standing invitation. PIM turns it into a request you can see, time, and refuse.
Questions people also ask
What is Privileged Identity Management?
Privileged Identity Management (PIM) is the Microsoft Entra service that grants just-in-time, time-bound access to privileged roles. Instead of holding an admin role permanently, a user is made eligible for it and activates it when the work needs it, with controls like MFA, a justification, approval and an expiry. It covers Microsoft Entra roles, Azure resource roles and PIM for Groups, and it needs a Microsoft Entra ID P2 or Microsoft Entra ID Governance license.
How does Privileged Identity Management work?
PIM works in four steps. An administrator assigns a user an eligible or an active role assignment at a chosen scope, permanent or with start and end dates. The eligible user activates the role when they need it, choosing a duration up to the maximum you set and meeting whatever controls you configured. If the role requires approval, a named approver accepts or denies the request. The role then expires on its own, and every step is written to the PIM audit history.
What is the difference between an eligible and an active assignment in PIM?
An active assignment means the user holds the role right now, all the time — standing access. An eligible assignment means the user can activate the role when they need it, subject to your activation controls, and it expires after a set window. Best practice is to make privileged roles eligible rather than active so no one carries admin rights they aren't currently using, which shrinks the window an attacker can abuse a compromised account.
Why use PIM?
Because standing privilege is the risk. Without PIM an administrator holds their role every hour of every day, so one phished session is a full compromise, and nothing records who elevated when. With PIM, an eligible admin spends most of the day with ordinary-user rights, elevation costs MFA and a written reason and sometimes an approval, the role expires by itself, and the whole thing lands in an audit trail you can hand to an auditor.
What happens when you don't have privileged identity management?
Every admin role is permanent, so the attack window is 24 hours a day rather than the minutes someone is actually doing admin work. Privilege creeps upward as people change teams, because nothing expires and nobody reviews it. Elevation leaves no record of who needed admin rights or why. And there is no approval step, so a single compromised account is a single point of failure for the whole tenant.
What license do you need for Privileged Identity Management?
PIM requires Microsoft Entra ID P2 or Microsoft Entra ID Governance licenses. You need one for every user with an eligible or time-bound assignment to an Entra or Azure role, every eligible member or owner of a PIM for Groups, every user who can approve or reject activation requests, and everyone who performs or is assigned to an access review. If the license expires, eligible assignments are removed and time-bound active assignments become permanent.
What does a PIM implementation include?
A PIM implementation includes discovering who holds privileged roles today and removing the assignments nobody needs, deciding which roles PIM will manage, drafting the role settings for each one as a signed-off policy, piloting on a small group, telling users and IT support what changes, testing against a written test plan, rolling out in slices, turning on security alerts and audit review, and scheduling recurring access reviews. The rollback is to make an eligible assignment active again.
Can users activate their own PIM roles?
Yes. Activation is self-service by design. An eligible user requests the role themselves, picks a duration up to the maximum you configured, and satisfies the controls on that role — MFA, a justification, a ticket number, a Conditional Access authentication context. Only roles you configured to require approval wait for a second person. Users can also request an extension before an assignment expires, or a renewal after it has.
How many Global Administrators should I have?
Microsoft recommends assigning the Global Administrator role to fewer than five people, and keeping fewer than 10 privileged role assignments in total. Make those assignments eligible through PIM rather than permanent, require approval to activate, and prefer a more specific role for day-to-day work. The exception is your two or more emergency access accounts, which stay permanently active in PIM and are alerted on every sign-in.
What are PIM access reviews?
Access reviews are recurring checks where role owners confirm whether each person still needs their eligible privileged assignment. They prevent privilege creep — the slow accumulation of admin rights people were granted once and never lost. Schedule them regularly for every privileged role, and remove eligibility that reviewers no longer justify so the set of people who can reach admin stays as small as the work requires.
What is the difference between PIM and PAM?
Privileged access management (PAM), sometimes written as privileged identity and access management, is the general category: controlling which accounts hold administrative power, and when. PIM is Microsoft's implementation of that category inside Microsoft Entra, covering Entra directory roles, Azure resource roles and PIM for Groups. If someone says PAM in a Microsoft context, they usually mean PIM plus the surrounding practices — least privilege, access reviews and emergency access accounts.