top of page
Search

PIM (Privileged Identity Management) Deployment Gotchas

  • 4 days ago
  • 8 min read

Privileged Identity Management is one of the best security features in Entra ID P2 (formerly Azure AD Premium P2). It enforces just-in-time admin access, reduces standing privileges, and gives you an audit trail of who activated what role and when. On paper, it's perfect. In practice, I've seen PIM deployments lock out admins, break service principals, cause MFA loops, and get quietly abandoned because "it's too hard to use."


The problem isn't PIM itself — it's that most deployments skip the planning phase and go straight to "let's make Global Admin require activation." Then someone gets locked out during a P1 incident, approvers are unreachable, and the whole thing gets rolled back.

In this post, I'll walk through the real-world gotchas you'll hit during PIM deployment — not the ones in Microsoft's docs, but the ones that cause emergency change requests at 2am — and how to avoid them.


Prerequisites

Before deploying PIM, you need:

  • Entra ID P2 licenses for all users who will activate privileged roles

  • Global Administrator or Privileged Role Administrator role

  • At least two break-glass accounts configured and tested

  • MFA enforced for all privileged users (PIM activation requires MFA)

  • Conditional Access policies documented (they interact with PIM in unexpected ways)

  • A rollback plan (seriously, have this ready before you start)


Step 1 – Discover Your Current Privileged Role Assignments

Before you enable PIM, you need to understand who has what roles right now. Go to Entra ID > Roles and administrators and check assignments for high-value roles:

  • Global Administrator

  • Privileged Role Administrator

  • Security Administrator

  • Exchange Administrator

  • SharePoint Administrator

  • Application Administrator

Export the list. You'll need it for:

  1. Converting standing assignments to eligible (PIM-managed)

  2. Identifying service accounts and automation that will break if you remove standing access

  3. Planning approval workflows based on current role usage


The Gotcha: Service Principals with Role Assignments

PIM only works for user accounts. If you have service principals (app registrations, managed identities) assigned to privileged roles for automation or integrations, those assignments cannot be made eligible. They must remain as permanent assignments.

Common examples:

  • Automation runbooks that manage Entra ID users

  • Third-party SaaS apps with admin permissions

  • Managed identities for Azure Logic Apps doing admin tasks

Fix: Identify these before you remove standing role assignments. Use this query in Cloud Shell (Azure CLI):

az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles" --query "value[].{RoleName:displayName, RoleId:id}" -o table

# For each high-value role, get assignments
az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/{roleId}/members" --query "value[].{DisplayName:displayName, ObjectType:['@odata.type']}" -o table

Look for #microsoft.graph.servicePrincipal in the output. Those must stay as permanent assignments.


Step 2 – Configure Break-Glass Accounts Before Enabling PIM

Critical gotcha: If you enable PIM for Global Admin and something goes wrong (MFA failure, approval workflow breaks, PIM service outage), you need a way back in.

Break-glass accounts are emergency admin accounts with permanent Global Administrator assignments that are excluded from all Conditional Access policies and excluded from PIM.


How to Set Them Up

Create two accounts (redundancy in case one is compromised):

  1. Naming: breakglass1@yourdomain.com, breakglass2@yourdomain.com

  2. Password: Long, random, stored in a physical safe or password manager with multi-person access

  3. MFA: Disabled (yes, really — these accounts bypass MFA so they work during MFA outages)

  4. Conditional Access: Explicitly excluded from all CA policies

  5. Role assignment: Permanent Global Administrator (never PIM-managed)

  6. Monitoring: Alert on any sign-in activity to these accounts (they should never be used except in emergencies)

Use this Sentinel query to alert on break-glass usage:

SigninLogs
| where UserPrincipalName in ("breakglass1@yourdomain.com", "breakglass2@yourdomain.com")
| where ResultType == 0  // Successful sign-in
| project TimeGenerated, UserPrincipalName, IPAddress, Location, AppDisplayName

The Gotcha: Conditional Access "All Users" Policies

Even if you think you've excluded break-glass accounts, check every CA policy. If you have a policy that applies to All users without explicit exclusions, it will block your break-glass accounts.

Go to Entra ID > Security > Conditional Access and audit every policy. Add break-glass accounts to the Exclude > Users list.


Step 3 – Enable PIM for Low-Risk Roles First

Do not start with Global Administrator. Start with a lower-risk role like Helpdesk Administrator or User Administrator to test the workflow.

Enable PIM for a Role

  1. Go to Entra ID > Privileged Identity Management > Azure AD roles

  2. Select Roles > choose User Administrator

  3. Click Settings > Edit

  4. Configure:

- Activation maximum duration: 8 hours (default is fine for testing) - Require approval: No (enable later once workflow is validated) - Require MFA on activation: Yes (always) - Require justification: Yes

  1. Click Update


Convert Standing Assignments to Eligible

  1. Go to Roles > User Administrator > Assignments

  2. For each user with a permanent assignment:

- Click Remove - Then click Add assignments > select the same user - Set Assignment type: Eligible - Set Duration: Permanent (or time-bound if you want assignments to expire)

  1. Click Assign


The Gotcha: Users Don't Know About PIM

If you convert assignments without telling users, they'll try to do their job, find they can't, and create a ticket. Then you'll spend hours explaining PIM instead of deploying it.

Before converting roles, send a communication:

  • What changed: "Your admin role is now eligible instead of permanent"

  • How to activate: Step-by-step with screenshots (portal.azure.com > PIM > My roles > Activate)

  • When to activate: "Activate only when you need admin permissions, not preemptively"

  • How long it lasts: "Activations last 8 hours by default"


Step 4 – Test Activation Before Rolling Out Broadly

Have a test user activate the role and perform a real admin task (create a user, reset a password, etc.). Watch for:


Gotcha 1: MFA Prompt Loops

PIM requires MFA to activate a role. But if you have Conditional Access policies that also require MFA for certain admin actions, users can get stuck in MFA loops.

Example: User activates User Administrator (MFA prompt 1), then tries to create a user in Entra ID portal (CA policy triggers MFA prompt 2).

Fix: Ensure CA policies recognize that the user already satisfied MFA during PIM activation. Use the Require multi-factor authentication control, not custom MFA policies.


Gotcha 2: Activation Delays

Role activations are not instant. There's usually a 1–3 minute delay before the role becomes active. Users will activate, immediately try to perform an admin action, get "Access Denied," and assume PIM is broken.

Fix: Add this to your user guidance: "After activating, wait 2–3 minutes before performing admin tasks."


Gotcha 3: Role Assignment Scope Confusion

PIM supports directory-level and administrative unit-scoped roles. If you assign an eligible role scoped to an administrative unit, users won't have tenant-wide permissions even after activation.

Fix: When assigning eligible roles, double-check the Scope setting. For most admins, you want Directory scope, not AU scope.


Step 5 – Configure Approval Workflows (Carefully)

For high-risk roles like Global Administrator, you probably want approval required for activation. But if you configure this wrong, you'll block legitimate access during emergencies.

How to Set Up Approvals

  1. Go to PIM > Azure AD roles > Settings

  2. Select Global Administrator > Edit

  3. Enable Require approval to activate

  4. Add at least three approvers (redundancy is critical)

  5. Set Approval timeout: 1 hour (default 8 hours is too long)


The Gotcha: All Approvers Are Unavailable

If you configure approval with only one or two approvers, and they're on vacation / sick / in a different time zone, activations will be blocked.

Fix:

  • Minimum 3 approvers per role

  • Use a distribution group or mail-enabled security group as the approver (so approval notifications go to multiple people)

  • Exclude Global Admin from approval workflows for at least 2–3 trusted admins (they can activate without approval during emergencies)


Approval Notification Configuration

By default, approval requests are sent via email and Azure portal notifications. But if approvers don't check email or aren't logged into Azure, requests sit unanswered.

Fix: Integrate approvals with Microsoft Teams:

  1. Go to PIM > Settings > Notifications

  2. Enable Send notifications to Teams

  3. Add approvers to a dedicated Teams channel (e.g., "PIM Approvals")

This ensures approval requests are visible in real-time.


Step 6 – Roll Out to Global Administrator (With a Rollback Plan)

Once you've validated PIM with lower-risk roles, you can enable it for Global Administrator. But have a rollback plan ready.


Pre-Rollout Checklist

  • [ ] Break-glass accounts tested and verified

  • [ ] At least 3 approvers configured for Global Admin role

  • [ ] All Global Admins notified and trained on activation process

  • [ ] Service principals with Global Admin roles identified and documented (they'll stay permanent)

  • [ ] Conditional Access policies audited for MFA loops

  • [ ] Emergency contact list for PIM-related lockouts


Rollback Plan

If something goes wrong:

  1. Use break-glass account to sign in

  2. Go to PIM > Azure AD roles > Global Administrator > Settings

  3. Disable "Require approval" (so admins can self-activate)

  4. Re-assign permanent Global Admin to key users temporarily

  5. Investigate root cause before re-enabling PIM


Troubleshooting

Problem: User activated a role, but still can't perform admin tasks.

  • Cause: Role activation delay (1–3 minutes) or cached token issue.

  • Fix: Wait 3 minutes, then sign out and sign back in. Token refresh forces the new role assignment to take effect.

Problem: Approvers aren't receiving approval requests.

  • Cause: Email notifications going to spam, or approvers not checking Azure portal.

  • Fix: Check PIM > Settings > Notifications and enable Teams notifications. Verify approver email addresses are correct.

Problem: PIM activation fails with "MFA required" even though user has MFA configured.

  • Cause: Conditional Access policy blocking sign-in or requiring re-authentication.

  • Fix: Check Entra ID > Sign-in logs for the user. Look for CA policy failures. Adjust CA policies to exempt PIM activation flows if needed.

Problem: Service principal automation broke after enabling PIM.

  • Cause: You removed a permanent role assignment from a service principal (PIM doesn't support SP eligible assignments).

  • Fix: Re-assign the role as permanent to the service principal. Only user accounts should use eligible assignments.


Hardening Considerations

Once PIM is deployed, harden the configuration:

  • Enable privileged access review (quarterly reviews of who has eligible roles)

  • Set maximum activation duration to 4 hours for high-risk roles (Global Admin, Privileged Role Admin)

  • Require justification and ticket number for all activations (audit trail)

  • Enable alerts for suspicious activations (e.g., activations from unfamiliar locations)

  • Monitor activation patterns — if an admin activates Global Admin every single day, they probably need a less privileged role for daily tasks


Final Thoughts

PIM is one of those features that looks simple in a demo but gets messy the moment you deploy it in a real environment. I've seen rollouts fail because nobody thought about service principals. I've seen teams abandon PIM after accidentally locking out all Global Admins during a CA policy change. And I've seen approval workflows configured so poorly that critical activations took 12+ hours because approvers were asleep.


The key to successful PIM deployment isn't rushing to enable it for every role on day one. It's starting small, testing thoroughly, and understanding how PIM interacts with the rest of your identity stack — Conditional Access, MFA, service principals, existing automation, and user workflows.


Start with low-risk roles. Validate activation flows. Train your users. Set up proper approval workflows with redundancy. And always have break-glass accounts ready before you touch Global Administrator.


Once it's tuned properly, PIM is fantastic. You'll have full visibility into who's using privileged roles, when, and why. You'll eliminate standing admin access. And when an admin account gets compromised, the blast radius is dramatically smaller because there's no permanent Global Admin token sitting around waiting to be stolen.


Just don't skip the planning phase. Your 2am self will thank you.

In a future post, I'll cover Conditional Access policy design for zero trust — because PIM and CA work together, and getting that integration right is the difference between airtight security and constant user friction.

 
 
 

Comments

Subscribe

Thanks for submitting!

bottom of page