Microsoft Entra ID PIM: a practical setup that doesn't break the team

Standing admin access is a slow-motion incident waiting to happen. Privileged Identity Management (PIM) replaces it with just-in-time elevation — admins are normal users until they need to do something privileged, then they activate a role for a few hours.

I've rolled PIM out at several organizations. Here's the playbook that works.

Step 0: Before you touch a thing

Confirm you have Entra ID P2 licensing. PIM requires it. If you don't, this is the most justifiable P2 purchase your organization can make — the protection it gives is worth far more than its cost.

Step 1: Inventory what's permanent today

Run this query in your tenant:

az rest --method GET \
  --url "https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments?\$filter=principalType eq 'User'" \
  --query "value[].{principal:principalId, role:roleDefinitionId}"

You'll likely find more permanent admin assignments than you expected. This is your baseline.

Step 2: Pick the roles to PIM-ify (in order)

I migrate roles in this order:

1. Global Administrator — biggest blast radius, most worth eliminating standing.
2. Privileged Authentication Administrator — can reset MFA for anyone, including admins.
3. Application Administrator — can grant API permissions on apps.
4. User Administrator — can manipulate user accounts.
5. The rest of the highly privileged roles.

Lower-impact roles like Reports Reader can stay permanent.

Step 3: Configure each role's PIM settings

For each role, in Microsoft Entra → Privileged Identity Management → Roles → Settings:

• Activation maximum duration: 8 hours (no more — humans don't need 24).
• Require justification on activation: Yes. Forces a one-line "I'm activating to fix Y."
• Require ticket information: Optional — if you have a ticketing system, link it.
• Require approval to activate: For Global Admin, yes with at least 2 approvers. For others, justification is enough.
• Require MFA on activation: Yes, always. Even if Conditional Access already required it earlier.

Step 4: Eligible vs Active assignments

PIM has two assignment types:

• Eligible — user can activate the role when needed.
• Active — user has the role right now.

Switch all your admins from Active to Eligible. Now they activate just-in-time.

Keep break-glass accounts as permanent Active for Global Admin. Two of them. Documented. Excluded from Conditional Access. This is your get-out-of-jail-free card if PIM itself breaks.

Step 5: Approvals — be deliberate about who approves whom

Common mistake: "make all admins approvers for each other." This creates circular trust where the same person who needs the elevation can sometimes approve their own peer's elevation in a chain.

What I do:

• Global Admin activations require approval from a different identity — the security team, or the CTO, depending on org.
• Other privileged roles require approval from a manager group rather than peer admins.

Step 6: Access reviews

Configure a quarterly access review per role:

• Reviewers: the role's owner (e.g., the head of platform engineering for engineering admins).
• Decision: if a reviewer doesn't act, default to remove. (Yes, remove. Standing access without active justification gets removed.)
• Apply automatically: Yes.

This is what stops "PIM rot" — the slow accumulation of eligible roles for people who used to need them.

Step 7: Rollout plan that doesn't cause a riot

Don't flip PIM on for everyone overnight. Phase it:

1. Week 1: PIM the IT/Platform team. They'll feel the friction first and give you feedback.
2. Week 2: Adjust based on feedback (most commonly, increase activation duration from 4h to 8h).
3. Week 3: Roll out to all admin role holders. Send a one-page comms that explains: what changes, what to do when activating, who to call if it breaks.
4. Week 4: Enable approval workflows for Global Admin.
5. Month 2: Set up access reviews.

What I monitor afterwards

Three things in the PIM audit log:

• Activation duration distribution. If most activations use the full 8 hours, your max is too tight or your team is gaming it.
• Activations without ticket reference. Justifications like "doing my job" are a smell — coach your admins.
• Failed approvals. Spike means a process gap; investigate.

What PIM does not do

• It doesn't protect you from compromised admin accounts. The attacker just activates a role themselves.
• It doesn't protect you from supply-chain attacks on apps with high privileges.
• It doesn't reduce your need for Conditional Access on admin accounts.

What it does is reduce the window of standing privilege from "always" to "8 hours, when justified, with audit trail." That's enormous.

If you're at a P2-licensed tenant and you haven't deployed PIM yet, this is the highest-impact thing you can do this quarter.