Privileged Identity Management in Microsoft Entra ID: A Production-Grade Guide to Avoiding Lockouts, Delays, and Token Abuse

TL;DR: PIM in Microsoft Entra ID is powerful but full of operational traps — token caching causes 15–40 minute delays in Exchange and SharePoint, the "require MFA on activation" setting has a documented bypass, and a misconfigured approval workflow can lock your entire tenant out of privileged roles. This guide walks through every critical configuration step, explains the underlying technical causes, and covers the edge cases that will bite you in production.

---

The Problem

You rolled out Privileged Identity Management across your tenant. Global Admin, Exchange Admin, SharePoint Admin — all converted to eligible assignments. Compliance is happy. Your CISO signed off on the project. Then, on a Tuesday at 10 PM, a junior engineer activates the SharePoint Admin role to fix a broken site collection permission, waits 20 minutes, and calls you because nothing changed. The role shows as active in the Entra portal, the audit log confirms the activation, but SharePoint still treats him as a regular user.

The second production issue tends to appear a few months after go-live when your security team reviews the Conditional Access logs and notices that users are activating Global Admin without a fresh authentication prompt. You have "Require MFA on activation" enabled in the PIM role settings — it says so right there in the portal. But the event log shows no MFA step for these activations. The users already had active browser sessions with a valid MFA claim, and PIM treated that as sufficient. That is not a configuration error on your part. That is the designed behavior, and it means a stolen AITM (Adversary-in-the-Middle) token — which retains the MFA claim — can be used to activate privileged roles without any additional authentication challenge.

The third common scenario is the lockout. You're hardening PIM, you configure approval requirements for Global Admin activation, and you realize later that you accidentally set all Global Admin and Privileged Role Administrator assignments to eligible-only, with no active assignments remaining. If the break glass accounts are not listed as approvers — or if the approver list is empty — the next person who tries to activate a role sits in pending state indefinitely. No one can approve because only a Global Admin or Privileged Role Admin can approve, and both require approval to activate. You are now in a tenant lockout.

---

Why This Happens

Token Caching in Microsoft 365 Workloads

PIM role activation in Entra ID works by modifying the user's directory role memberships at the Entra ID layer. However, Microsoft 365 workloads — Exchange Online and SharePoint Online in particular — do not read role memberships directly from the directory in real time. They rely on OAuth access tokens and their own internal service-side caches. When a user activates a role directly via PIM for Microsoft Entra roles, Exchange and SharePoint receive the updated role information only when the user's access token is refreshed.

In practice this means that a direct PIM role assignment takes between 15 and 40 minutes to propagate into Exchange Online and SharePoint Online. The delay is not a bug — it is a structural consequence of how token-based authorization works across distributed services.

The situation is worse for PIM for Groups. When you assign a user as an eligible member of a group, and that group is mapped to SharePoint site permissions, the propagation delay can reach up to 24 hours. Microsoft has confirmed this in their support documentation. The underlying reason is that SharePoint Online's group membership sync is a background job that runs on its own schedule, independent of both Entra ID's role propagation and Exchange's token refresh cycle.

The MFA Bypass in PIM Activation Policies

The "On activation, require Azure AD MFA" setting in PIM role policy checks whether the user's current session has an MFA claim. If the user authenticated with MFA within the same session — even hours earlier — PIM considers the condition satisfied and does not prompt for a new authentication. An AITM phishing attack, which intercepts the authenticated session cookie or steals the refresh token after a legitimate MFA login, gives the attacker a token with a valid MFA claim. That token passes PIM's MFA check.

Refresh tokens in Entra ID can remain valid for up to 90 days. An attacker who steals a refresh token during a legitimate session does not need to act immediately. They can wait until the legitimate user has an eligible privileged role active and then use the stolen refresh token to obtain a new access token with elevated claims. The elevated access then persists for the duration of the activation window.

Approval Workflow Deadlock

PIM approval workflows have a structural risk that is easy to trigger during hardening projects. If every account capable of approving a Global Admin activation is itself assigned to those roles as eligible-only with approval required, you have a circular dependency. The tenant is not literally broken, but no one can elevate to the roles needed to fix the configuration.

---

Step-by-Step Solution

Step 1: Audit Your Current Eligible and Active Assignments

Before changing any policy, build a complete picture of who has what. The following PowerShell retrieves all currently eligible PIM assignments across the directory:

# List all eligible PIM assignments
Connect-MgGraph -Scopes "RoleManagement.Read.Directory", "Directory.Read.All"
$eligibleAssignments = Get-MgRoleManagementDirectoryRoleEligibilityScheduleInstance -All -ExpandProperty 'principal,roleDefinition'
$eligibleAssignments | Select-Object `
    @{N="User";E={$_.Principal.AdditionalProperties.displayName}},
    @{N="Role";E={$_.RoleDefinition.DisplayName}},
    @{N="Expires";E={$_.EndDateTime}},
    @{N="MemberType";E={$_.MemberType}} |
  Format-Table -AutoSize

Pay attention to the MemberType column. Assignments showing Group indicate the role access comes through PIM for Groups — these carry the extended SharePoint propagation delay and the privilege escalation risk described later. Any user with a null expiration under Expires has a permanent eligible assignment.

To see what is currently active — particularly useful during incident response:

# Show currently active (elevated right now) role assignments
Get-MgRoleManagementDirectoryRoleAssignmentScheduleInstance -All -ExpandProperty 'principal,roleDefinition' |
  Where-Object { $_.AssignmentType -eq "Activated" } |
  Select-Object `
    @{N="User";E={$_.Principal.AdditionalProperties.userPrincipalName}},
    @{N="Role";E={$_.RoleDefinition.DisplayName}},
    @{N="Since";E={$_.StartDateTime}},
    @{N="Until";E={$_.EndDateTime}} |
  Format-Table -AutoSize

Cross-reference the Until column against your configured maximum activation windows. Any activation significantly longer than your configured maximum warrants immediate investigation.

For ongoing operational monitoring, export the last 30 days of activation history:

# Audit PIM role activations from the last 30 days
Connect-MgGraph -Scopes "AuditLog.Read.All", "Directory.Read.All"
$startDate = (Get-Date).AddDays(-30).ToString("yyyy-MM-ddT00:00:00Z")
Get-MgAuditLogDirectoryAudit -Filter "activityDisplayName eq 'Add member to role completed (PIM activation)' and activityDateTime ge $startDate" |
  Select-Object ActivityDateTime,
    @{N="User";E={$_.InitiatedBy.User.UserPrincipalName}},
    @{N="Role";E={$_.TargetResources[0].DisplayName}},
    @{N="IPAddress";E={$_.InitiatedBy.User.IpAddress}} |
  Export-Csv -Path "pim_activations_$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation

Review the output for activations outside business hours, from unusual IP addresses or countries, or from users who do not normally use a given role.

Step 2: Establish Break Glass Accounts Before Tightening Policies

This step must come before any changes to approval workflows. Create at least two break glass accounts with the following properties:

• Permanently active Global Administrator assignment (not eligible — this is the one exception to the no-permanent-assignment rule)
• Excluded from all Conditional Access policies, including MFA requirements and device compliance
• Credentials stored offline in a physical safe — not in any password manager or vault accessible from the network
• Named conspicuously, for example breakglass-01@yourdomain.onmicrosoft.com, so any use triggers immediate investigation
• Sign-in monitoring via Entra ID diagnostic logs or Microsoft Sentinel with an immediate alert on any interactive login

The break glass accounts must be listed as approvers in every approval workflow for Global Admin and Privileged Role Admin. Verify this explicitly after configuration by checking the approval policy in PIM settings for each Tier-0 role. Permanent active assignments for all other operational accounts should be disallowed — the break glass exception is narrow and specific.

Step 3: Fix the MFA Bypass Using Authentication Context

Replace or supplement the "Require MFA" checkbox in PIM role settings with an Authentication Context–based Conditional Access policy.

In the Entra portal:

1. Navigate to Protection > Conditional Access > Authentication context and create a new context, for example c1, labeled "PIM Tier-0 Activation."
2. Create a new Conditional Access policy targeting that authentication context.
3. Set Grant to require MFA (or require authentication strength with phishing-resistant MFA).
4. Set Sign-in frequency to Every time under Session controls. This forces a fresh authentication regardless of whether the session already contains an MFA claim.
5. In PIM role settings for Global Admin, Privileged Role Admin, and other Tier-0 roles, set the activation requirement to use this Authentication Context.

This configuration means every activation attempt triggers a new authentication challenge, even if the user logged in with MFA five minutes earlier. A stolen AITM token that carries the original MFA claim will fail the re-authentication step because the attacker does not have access to the user's MFA device for a fresh challenge.

Important known limitation: after a user successfully activates a role on a compliant device, they can subsequently use the activated role from a different, non-compliant device. The authentication context validated the activation moment, not the ongoing session on other devices. To close this gap, you need a second Conditional Access policy that targets the role directly to enforce device compliance throughout the entire activation window.

There is also a 10-minute window edge case described in the pitfalls section that the Authentication Context configuration does not fully address.

Step 4: Configure Activation Duration Limits

PIM supports activation durations between 1 and 24 hours. The default in many tenants ends up at 8 hours because administrators copy settings from documentation examples without adjusting them. Recommended maximum activation durations:

• Global Administrator: 2 hours
• Privileged Role Administrator: 2 hours
• Security Administrator: 4 hours
• Exchange Administrator: 4 hours
• SharePoint Administrator: 4 hours

Reducing the activation window directly limits how long a compromised elevated session can be exploited, including the stolen refresh token scenario where an attacker uses a 90-day valid refresh token to obtain access tokens with elevated claims.

Step 5: Address SharePoint and Exchange Propagation Delays

For Exchange: inform administrators that after role activation they need to wait 15–40 minutes before the role is effective. To speed up the session-side token refresh in the current browser, navigate to https://aka.ms/pim/tokenrefresh immediately after activation. This forces token refresh in the current session and reduces the effective wait from up to 40 minutes to a few minutes in most cases.

For SharePoint with PIM for Groups, the up-to-24-hour propagation delay is not acceptable in most operational scenarios. Two approaches:

• Option A (recommended): Do not use PIM for Groups to control SharePoint admin access. Assign the SharePoint Administrator role directly via PIM for Microsoft Entra roles. The delay drops to 15–40 minutes.
• Option B: If group-based assignment is required, add the user to the group as a permanent member first, then make the group eligible via PIM for Groups for directory role assignments only. SharePoint sees the static group membership and syncs it on its normal schedule. PIM controls the directory role claim.

Step 6: Implement Continuous Activation Auditing

Build alerting around the audit data. Minimum alerts that should be active in Microsoft Sentinel or Defender XDR:

• Any Global Admin or Privileged Role Admin activation — immediate alert, every time
• Any activation from an IP address not seen in the past 30 days for that user
• Any user who activates more than two roles within a single day
• Any break glass account login — critical alert with escalation

Pair these alerts with the PowerShell audit script from Step 1 running as a scheduled Logic App or Azure Automation runbook, exporting results to a storage account for retention beyond the default 30-day Entra ID log retention period.

---

Common Pitfalls and Edge Cases

Pitfall 1: The 10-Minute Re-Authentication Window

If a user activates a first eligible role through Authentication Context (completing full re-authentication), and then activates a second eligible role within 10 minutes, Entra ID does not require re-authentication for the second activation. The 10-minute window applies across Microsoft Entra roles, Azure resource roles, and PIM for Groups. An attacker with access to the session during this window can activate additional roles without triggering another authentication prompt. The only mitigation currently available is monitoring — alert on any user who activates two or more Tier-0 roles within a single 10-minute window, as this pattern is unusual for legitimate operational work.

Pitfall 2: PIM for Groups Creates Invisible Privilege Escalation Paths

PIM for Groups is convenient — eligible group membership can control both application access and directory roles in one policy. The risk is that groups accumulate memberships and permissions over time. A group created for a SharePoint project gets added as a member of another group that was mapped to a role two organizational restructurings ago. Activating membership in what appears to be a limited-scope group can transitively grant Global Administrator access through a chain of nested group memberships that no one has reviewed recently.

Audit group nesting for any group used in PIM for Groups configurations on a quarterly basis. Any activation path that transitively reaches Global Admin, Privileged Role Admin, or Security Admin is a Tier-0 activation and requires corresponding authentication and approval requirements — even if the initial activation appears to be for a lower-privilege group.

Pitfall 3: Stolen Refresh Tokens Enable Delayed Privilege Abuse

A refresh token stolen through credential phishing or malware does not need to be used immediately. With a validity window of up to 90 days, an attacker can hold a stolen refresh token and wait for the legitimate user to activate a privileged PIM role during normal operations. At that moment, the attacker exchanges the stolen refresh token for a new access token that includes the elevated role claims. This elevated access token is valid for the full duration of the activation window.

The activity is difficult to distinguish from legitimate use in basic audit logs because the access token was issued against the legitimate user's identity. Mitigations include enabling Continuous Access Evaluation (CAE) to reduce effective token lifetimes, building behavioral baselines for each privileged account so anomalous token use from new IP addresses or devices triggers alerts during activation windows, and requiring a ticket number on activation to create an audit correlation trail.

Pitfall 4: Approval Workflow Misconfiguration Leading to Lockout

The lockout scenario deserves explicit emphasis because it is easy to trigger during security hardening. The conditions: all Global Admin and Privileged Role Admin accounts are eligible-only, approval is required to activate, and the approver list is empty or points to accounts that cannot themselves activate without being approved. This creates a circular dependency.

To verify your configuration does not have this vulnerability: immediately after any PIM policy change, attempt a test activation from a non-break-glass account and confirm the approval request reaches a working approver. Do not assume the configuration is correct because the portal accepted it. Also confirm that the approver account itself has an active (not eligible) assignment that does not require further approval. Run this validation every time you modify approval settings, not just when you initially configure PIM.

---

Summary

• Propagation delays are structural. Direct PIM role assignments take 15–40 minutes to become effective in Exchange Online and SharePoint Online. PIM for Groups activations can take up to 24 hours to propagate in SharePoint. Use https://aka.ms/pim/tokenrefresh after activation to speed up token refresh in the current session, and prefer direct Entra role assignment over group-based assignment for time-sensitive operations.

• "Require MFA on activation" does not force re-authentication. A valid MFA claim from any point in the current session satisfies the check. For Tier-0 roles, replace it with an Authentication Context–based Conditional Access policy with Sign-in frequency set to "Every time." Note the 10-minute window: a second eligible role activated within 10 minutes of the first does not trigger re-authentication.

• Approval workflows require explicit approvers with standing access. The most dangerous misconfiguration in PIM is an approval-required Tier-0 role where no approver has an active assignment. Break glass accounts must be permanently active Global Admins and listed as approvers in every Tier-0 activation policy. Validate the full approval workflow end-to-end after every policy change.

• PIM for Groups carries transitive privilege escalation risk. Nested group structures can make a seemingly limited-scope group activation effectively a Tier-0 activation. Audit all groups used in PIM for Groups configurations quarterly for transitive Global Admin membership.

• Stolen refresh tokens are valid up to 90 days. An attacker who steals a token does not need to act immediately — they can wait for a legitimate activation window and then operate under the user's elevated claims. Enable CAE, build behavioral baselines, and pair activation events with anomalous session monitoring to detect this pattern before significant damage occurs.