Entra ID Privileged Identity Management

Privileged Identity Management (PIM) is the Entra ID feature that turns standing admin role assignments into just-in-time, time-bound activations. Instead of being a Global Administrator around the clock, an admin is eligible for the role: they request activation when they need it, prove who they are, hold the role for a few hours, and lose it again automatically. It's one of the highest-value-per-effort security controls in the entire Microsoft stack.

Why standing access is the problem

A permanent Global Admin assignment is a permanent attack surface. Phish that account — or its refresh token, or the machine it's signed in on — and the attacker is a Global Admin, at 3 a.m., for as long as they stay undetected. Standing access also decays socially: roles granted for one project outlive the project, and two years later nobody remembers why the intern's old account is an Exchange Administrator.

With PIM in place:

• Roles are eligible, not active. A compromised account holds only the user's day-to-day access.
• Activation demands fresh proof — MFA at activation time, or, better, a Conditional Access authentication context requiring a phishing-resistant method or a compliant workstation.
• Activations are time-boxed (commonly 1–8 hours) and can require justification, a ticket number, or explicit approval by another human.
• Every activation lands in the audit log and can raise an alert — "Global Admin activated outside business hours" is exactly the kind of signal a SOC wants.

The attacker's job changes from "use the access you stole" to "successfully impersonate the victim through an MFA-gated, logged, possibly approval-gated ceremony." That's a much worse job.

What PIM covers

• Entra ID roles — Global Administrator, User Administrator, Exchange Administrator, and the rest of the directory role catalogue. This is the core use case for Microsoft 365 tenants, and how the workload admin roles (Exchange, SharePoint, Teams, Intune) should be handed out — see Microsoft 365 admin role design.
• Azure resource roles — Owner, Contributor, and friends, scoped to management groups, subscriptions, or resources.
• PIM for Groups — eligibility for membership or ownership of a group. Powerful for two reasons: role-assignable groups let one activation grant a bundle of roles, and group-based licensing or app access can be made just-in-time the same way.

The three assignment states

• Eligible — can activate, holds nothing right now.
• Active — holds the role now, via activation or direct assignment.
• Permanent vs time-bound — both eligible and active assignments can carry expiry dates, so even eligibility can be forced through periodic renewal.

The operating rule: almost everything becomes Eligible. The exceptions are your break-glass accounts — permanent, active, excluded from Conditional Access, locked in a safe — and genuine service scenarios that can't perform an interactive activation.

Role settings that work in practice

Per role, PIM lets you tune activation duration, MFA/authentication context, justification, ticketing, and approval. A calibration that holds up:

• Global Administrator, Privileged Role Administrator, Security Administrator: 2–4 hour activation, approval required, justification required, phishing-resistant MFA via authentication context. Keep the eligible list brutally short — Microsoft's guidance of fewer than five Global Admins is right.
• Workload admins (Exchange, SharePoint, Teams, Intune): 8 hours, MFA and justification, no approval — these are daily-driver roles, and an approval gate on daily work teaches people to hate PIM.
• Read-heavy roles (Global Reader, Security Reader): consider these for standing assignment or long activations; friction here buys little.

That last point generalises: PIM fails through overreach. If activating a role people need ten times a day requires an approver who's asleep, admins will lobby for standing access again and they'll have a case. Reserve the heavy ceremony for the roles that can destroy the tenant.

Access reviews close the loop

PIM pairs with access reviews: recurring campaigns (quarterly is typical) that make role owners re-confirm every eligible and active assignment, with auto-removal for non-response. Activation history makes the review honest — an eligibility that hasn't been activated in six months is a strong candidate for removal. This is what catches the slow drift that created the standing-access mess in the first place.

Licensing

PIM requires Entra ID P2, which comes with Microsoft 365 E5, the E5 Security add-on, or Entra ID Governance SKUs. You don't need P2 for every user — you need it for users who benefit from PIM, i.e. the admin population. For an E3 tenant, licensing a couple of dozen admins for a step-up SKU is one of the cheapest meaningful security upgrades available.

Rollout

1. Inventory current role assignments (the PIM discovery view does this) and be prepared for unpleasant surprises.
2. Confirm break-glass accounts work, then convert standing assignments to Eligible, starting with the most privileged roles.
3. Configure per-role settings along the lines above.
4. Wire activation alerts into whatever your SOC watches.
5. Schedule quarterly access reviews per privileged role.
6. Extend to Azure resource roles and PIM for Groups once directory roles are stable.

The whole thing is a few weeks of part-time work for a typical tenant, and it converts your worst-case phishing outcome from "tenant compromise" to "one user's mailbox." Few controls trade effort for risk that well.

Decision matrix — role settings by tier

Use this as a starting point and tune down where friction is genuinely paying no security dividend. The "tier" language comes from Microsoft's own enterprise access model; the specifics are the calibration that survives contact with a real admin population.

| Role tier | Examples | Max activation | MFA at activation | Justification | Ticket | Approval | |---|---|---|---|---|---|---| | Tenant-critical | Global Admin, Privileged Role Admin, Partner Tier2 Support | 2 h | Phishing-resistant (auth context c1) | Required | Required | Required | | Security-critical | Security Admin, Conditional Access Admin, Authentication Policy Admin | 4 h | Phishing-resistant | Required | Required | For CA / authentication policy changes only | | Workload admin | Exchange, SharePoint, Teams, Intune, Compliance | 8 h | Standard MFA | Required | Optional | No | | Governance admin | Identity Governance, User Admin, Groups Admin | 4 h | Standard MFA | Required | Optional | For User Admin only | | Read-heavy | Global Reader, Security Reader, Reports Reader | 8 h or standing | Standard MFA | Optional | No | No |

Two settings tend to get overlooked: "On activation, require Conditional Access authentication context" binds the activation to a phishing-resistant method or a compliant device without duplicating the policy in PIM, and "Require approval to activate" with an empty approver list quietly falls back to the Privileged Role Administrator, which is not what most tenants want — always specify a group.

Worked example — a 500-seat tenant, 6 weeks in

A concrete run before it stops sounding theoretical. Tenant: 500 seats, 8 IT staff, previously three Global Admins as day-to-day accounts. Six weeks of part-time work by one identity engineer:

1. Week 1 — discovery and break-glass. Inventory: 3 permanent Global Admins, 11 permanent Exchange Admins (most former IT staff), 4 SharePoint Admins nobody remembered granting. Two break-glass accounts created, tested end-to-end (sign in through a private window, resolve an MFA challenge on the FIDO2 key held in the safe, land in the admin portal), documented, excluded from every Conditional Access policy, put in a monthly test rotation.
2. Week 2 — Global Admin conversion. Three humans converted to Eligible on Global Admin with the tier-1 settings above; one approver group of two people wired in. The first activation took 20 minutes because nobody had used PIM before — worth doing before there's an incident.
3. Weeks 3–4 — workload roles. Exchange, SharePoint, Teams, Intune, Compliance Admin all converted, tier-3 settings, no approval. 11 stale Exchange Admins removed outright — nobody complained. Access reviews configured to run quarterly, auto-remove non-responders.
4. Week 5 — alerts and SOC. Activation alerts wired into the SIEM: page for any tier-1 activation outside 08:00–18:00 tenant time, log-only for the rest. First real alert fired in week 6 — a legitimate after-hours change, but the on-call now knew what one looked like.
5. Week 6 — PIM for Groups and cleanup. Two role-assignable groups made eligible (a "SharePoint hub owner" and a "Teams voice on-call" group). Documentation written for the runbook shelf, one training session delivered.

Outcome: zero permanent tenant-privileged accounts, one Entra ID P2 licence added per admin, one quarterly access review on the ops calendar. Total elapsed effort by the engineer: roughly 40 hours across the six weeks.

MSP checklist

For partners running multiple tenants under GDAP, PIM is the mechanism that keeps the "one compromised engineer laptop = every customer tenant" scenario from being real. The additional moves on top of the single-tenant rollout above:

• Every GDAP role in Entra Admin Partner Portal is Eligible, not Active. The default GDAP relationship grants active roles — remove those and re-add through PIM for Groups.
• Approval requires a second engineer in the same partner tenant, not the customer. Customers won't approve a Global Admin request at 2 a.m., but an on-call partner engineer will.
• Activation duration is short (1–2 hours) and scoped to the ticket. Ticket number required in the justification, cross-referenced from the PSA on the way in.
• Every customer tenant activation lands in the partner SIEM, not just the customer's own logs. Correlate against the ticket queue — an activation without a matching ticket is the first sign of engineer-account compromise.
• Separate partner-admin accounts from operations-user accounts. The engineer's day-to-day mailbox account is not the account that carries GDAP eligibility; those are two logins, ideally on two devices.

Wrong-fit cases — where PIM is not the answer

PIM is the right control for humans holding directory roles. It is the wrong control for:

• Service principals and managed identities. These do not activate anything. Restrict what they can hold with least-privileged Graph and RBAC assignments and rotate credentials through workload identity federation — see service principals and managed identities.
• App owners on registered applications. Application owner is not a directory role and PIM does not gate it. Use role-assignable groups plus PIM for Groups to make ownership eligible.
• Tenants without Entra ID P2. P2 is per-user per-month; if the business genuinely cannot license it for the admin population, the fallback is a small, named group of standing admins with mandatory phishing-resistant MFA and Conditional Access enforcing sign-in from a Privileged Access Workstation. Worse than PIM, but a real control — do it while the licence business case is being written, not instead of it.
• Emergency response. Break-glass accounts sit outside PIM by design. If an incident depletes the eligible admin pool, you use break-glass — not a workflow that requires a live approver.
• Guest/B2B accounts. Guests can hold Entra roles, but the operating model here is usually different — cross-tenant access settings and entitlement management do the heavy lifting; PIM handles the last mile if a partner engineer really does need to activate a role in your tenant.

Common failure modes

• The approver group is one person. They go on holiday, activation grinds to a halt, standing access gets granted "just for this week" — and stays.
• Approval is required on daily-driver roles. Admins learn to activate speculatively at the start of the day, defeating the whole point.
• Break-glass accounts are never tested. A monthly rotation with a written log is the difference between "we have break-glass" and "we discovered our break-glass didn't work during the incident."
• Alerts fire on every activation. After a fortnight nobody reads them. Alert on tier-1 outside business hours, on activation-without-ticket, and on more than N activations per hour — not on every activation.
• Access reviews are set to reviewer = self. Everyone approves their own eligibility. Reviewer should be the role owner or the group that owns the workload, not the holder of the assignment.

Related reading

• Conditional Access design — the authentication context PIM binds to.
• Break-glass accounts — the counterweight to PIM.
• Microsoft 365 admin role design — which roles to hand out in the first place.
• How to set up PIM for Global Administrator — the click-path for the tier-1 role.
• Entra Suite explained — the licensing bundle that includes P2 alongside Identity Governance and Internet Access.