Entra ID PIM: Speed Up Activations, Backed by Measurements

You activate a role in Privileged Identity Management (PIM), the activation turns green, and yet access is still denied for dozens of minutes. The problem almost never comes from PIM itself, but from the assignment model you chose and from downstream services.

This tutorial shows you how to time the real delay with Microsoft Graph, choose the right group model, and then measure the gain you obtain.

Why PIM validates the activation without access following

According to the Microsoft documentation on role activation, PIM creates the active assignment of a Microsoft Entra role within seconds. That says nothing about what applications see. Three mechanisms can delay effective use: group membership propagation, SCIM provisioning to SaaS applications, and cached permissions.

Field reports diverge. On Microsoft Q&A, administrators report in 2025 up to 2 hours before Purview permissions take effect after a group-based activation, and 30 to 40 minutes for Exchange and Teams (discussion on PIM and Purview roles). These are testimonials, not Microsoft commitments. Conversely, MVP Andy David indicates that his group-based activations remain fast, including for SharePoint (discussion on PIM escalation delays).

Delays therefore vary from tenant to tenant. It is better to measure yours than to rely on an average.

Two group models, only one avoids the membership change

The question to ask is simple: what does the activation change, a role or a group membership? Microsoft describes two group-based approaches and, for SharePoint, Exchange and the Purview portal, explicitly recommends the first one, with PIM for Microsoft Entra roles rather than PIM for Groups.

The SharePoint case illustrates the risk. Microsoft's troubleshooting page (access error to SharePoint or OneDrive after PIM activation) describes a delay of up to 24 hours when the SharePoint Administrator role is assigned to a group the user is only eligible for membership of. The two official solutions: a direct role eligibility, or adding the user to the group followed by making the group eligible for the role.

To manage group eligibility at scale, an option has existed since November 2025. Entitlement Management access packages can assign eligible group memberships and ownerships, with self-service requests and extensions. The feature is generally available, after a public preview in August 2025 (Microsoft Entra what's new archive). For configuration basics, see our guide on Entra ID PIM and just-in-time privileged access.

Implementation: timing the activation with Microsoft Graph

The script below activates a role or a group membership for your own account, then records two durations. PimProvisionedSeconds is the time before PIM declares the request Provisioned. ProbeOkSeconds is the time before a Graph request that requires the privilege finally succeeds. The gap between the two is the wait you actually experience. A line is appended to a CSV file on each trial, and the activation is then deactivated.

The script uses only v1.0 endpoints, via Invoke-MgGraphRequest. Microsoft states that, starting 28 October 2026, applications and scripts that call the PIM "Iteration 2" beta APIs (Azure resources, Microsoft Entra roles and groups) will fail, and that you need to migrate to the Iteration 3 APIs (Microsoft Entra what's new archive). Check your other PIM automations on this point.

1#Requires -Modules Microsoft.Graph.Authentication
2[CmdletBinding()]
3param(
4    [Parameter(Mandatory)][ValidateSet('Role','Group')][string]$Mode,
5    [string]$RoleName,
6    [string]$GroupId,
7    [string]$ProbeUri = 'https://graph.microsoft.com/v1.0/auditLogs/directoryAudits?$top=1',
8    [string]$Duration = 'PT1H',
9    [int]$TimeoutMinutes = 60,
10    [int]$PollSeconds = 10,
11    [string]$OutCsv = '.\pim-activation-timings.csv'
12)
13 
14# Parameter validation depending on the mode
15if ($Mode -eq 'Role' -and -not $RoleName) { throw 'Le mode Role exige -RoleName.' }
16if ($Mode -eq 'Group' -and -not $GroupId) { throw 'Le mode Group exige -GroupId.' }
17 
18# Minimal delegated scopes depending on the mode
19$scopes = @('AuditLog.Read.All')
20if ($Mode -eq 'Role') { $scopes += 'RoleAssignmentSchedule.ReadWrite.Directory', 'RoleManagement.Read.Directory' }
21else { $scopes += 'PrivilegedAssignmentSchedule.ReadWrite.AzureADGroup' }
22Connect-MgGraph -Scopes $scopes -NoWelcome
23 
24$base = 'https://graph.microsoft.com/v1.0'
25$me = Invoke-MgGraphRequest -Method GET -Uri ($base + '/me?$select=id,userPrincipalName')
26 
27# Activation schedule: immediate start, limited duration
28$schedule = @{
29    startDateTime = (Get-Date).ToUniversalTime().ToString('yyyy-MM-ddTHH:mm:ssZ')
30    expiration    = @{ type = 'afterDuration'; duration = $Duration }
31}
32 
33# Building the request depending on the mode
34if ($Mode -eq 'Role') {
35    $filter = [uri]::EscapeDataString(('displayName eq ''{0}''' -f $RoleName))
36    $defs = Invoke-MgGraphRequest -Method GET -Uri ($base + '/roleManagement/directory/roleDefinitions?$filter=' + $filter)
37    if (@($defs.value).Count -ne 1) { throw ('Role introuvable ou ambigu : {0}' -f $RoleName) }
38    $target     = $RoleName
39    $requestUri = $base + '/roleManagement/directory/roleAssignmentScheduleRequests'
40    $common     = @{ principalId = $me.id; roleDefinitionId = $defs.value[0].id; directoryScopeId = '/' }
41} else {
42    $target     = $GroupId
43    $requestUri = $base + '/identityGovernance/privilegedAccess/group/assignmentScheduleRequests'
44    $common     = @{ principalId = $me.id; groupId = $GroupId; accessId = 'member' }
45}
46$activate = $common + @{ action = 'selfActivate'; justification = 'Mesure du delai PIM'; scheduleInfo = $schedule }
47 
48# Start the stopwatch then send the activation request
49$sw = [System.Diagnostics.Stopwatch]::StartNew()
50$request = Invoke-MgGraphRequest -Method POST -Uri $requestUri -Body ($activate | ConvertTo-Json -Depth 5) -ContentType 'application/json'
51 
52$pimSeconds = $null
53$probeSeconds = $null
54while ($null -eq $probeSeconds -and $sw.Elapsed.TotalMinutes -lt $TimeoutMinutes) {
55    # Step 1: request status on the PIM side
56    if ($null -eq $pimSeconds) {
57        $state = Invoke-MgGraphRequest -Method GET -Uri ($requestUri + '/' + $request.id)
58        if ($state.status -eq 'Provisioned') { $pimSeconds = [int]$sw.Elapsed.TotalSeconds }
59        elseif ($state.status -in 'Failed','Denied','Canceled','Revoked') { throw ('Activation en echec : {0}' -f $state.status) }
60    }
61    # Step 2: probe a Graph request that requires the privilege
62    try {
63        Invoke-MgGraphRequest -Method GET -Uri $ProbeUri | Out-Null
64        $probeSeconds = [int]$sw.Elapsed.TotalSeconds
65    } catch {
66        Start-Sleep -Seconds $PollSeconds
67    }
68}
69 
70# Deactivation so a clean trial can be rerun
71$deactivate = $common + @{ action = 'selfDeactivate' }
72try {
73    Invoke-MgGraphRequest -Method POST -Uri $requestUri -Body ($deactivate | ConvertTo-Json -Depth 5) -ContentType 'application/json' | Out-Null
74} catch {
75    Write-Warning ('Desactivation manuelle necessaire : {0}' -f $_.Exception.Message)
76}
77 
78# Result: one line per trial, accumulated in the CSV
79$result = [pscustomobject]@{
80    Date                  = Get-Date -Format s
81    Mode                  = $Mode
82    Target                = $target
83    PimProvisionedSeconds = $pimSeconds
84    ProbeOkSeconds        = $probeSeconds
85}
86$result | Export-Csv -Path $OutCsv -Append -NoTypeInformation -Encoding UTF8
87$result

This probe only sees what Graph sees. For Exchange, SharePoint or Purview, keep the script as a PIM reference point and manually time the first successful access in the relevant portal. A token obtained before the activation reproduces the caching behaviour; sign in again to compare with a fresh token.

Procedure: measure, restructure, measure again

The goal is to compare two models on the same account, with several trials each, rather than relying on a single timing.

11..3 | ForEach-Object {
2    .\Measure-PimActivation.ps1 -Mode Group -GroupId '00000000-0000-0000-0000-000000000000'
3}

11..3 | ForEach-Object {
2    .\Measure-PimActivation.ps1 -Mode Role -RoleName 'Security Reader'
3}

1Import-Csv -Path .\pim-activation-timings.csv |
2    Where-Object { $_.ProbeOkSeconds } |
3    Group-Object -Property Mode |
4    ForEach-Object {
5        [pscustomobject]@{
6            Mode            = $_.Name
7            Essais          = $_.Count
8            MoyenneSecondes = [math]::Round(($_.Group | ForEach-Object { [int]$_.ProbeOkSeconds } | Measure-Object -Average).Average)
9        }
10    }

The expected gain is calculated in minutes per activation. Ten activations per week with 40 minutes of wait avoided represent 6 h 40 of time recovered.

SaaS accounts: provision before activation

For third-party applications provisioned by SCIM, Entra has to update another system. Microsoft recommends separating baseline access from privileged access: users remain active members of a baseline group, which keeps their account provisioned with no privilege or a low-privilege role. A second group, managed by PIM, carries the eligible privileged membership.

The account already exists, so the activation only changes the privileged membership. It triggers accelerated provisioning, documented at around 2 to 10 minutes, whereas an ordinary membership change waits for the 40-minute cycle. The Microsoft Entra what's new archive states, for just-in-time application access generally available since March 2024, an activation time reduced from more than 40 minutes to about 2 minutes for non-Microsoft applications.

The limit of 5 activations per 10 seconds applies to the enterprise application, not to the tenant. Imagine an on-call team of eight engineers who all activate their access when an incident opens: the first five are provisioned in accelerated mode, the next three fall back to the normal cycle. Stagger activations or review how your groups are split if this scenario is plausible in your environment.

The application may add its own delay: validate how it refreshes permissions rather than promising two-minute access. And direct eligibility for a Microsoft Entra role never replaces provisioning of privileges at the vendor.

Troubleshooting: tokens, caches and residual delays

After activation, the PIM token refresh link redirects to the Azure portal with feature.tokencaching=false, which disables the portal's token cache. It is a troubleshooting aid limited to the portal, not a tenant setting that affects Microsoft 365 or SaaS applications. The activation documentation also suggests signing out then signing back in when an application caches access, and Andy David notes that a private browsing session generally fixes slow access.

Propagation on the Purview side deserves particular attention: the same administrators report removal delays of up to 2 hours, which is a security problem in addition to a comfort issue. For an overview of these components, see our article on the architecture and key components of Microsoft Entra ID.

Frequently asked questions

Should we abandon PIM for Groups?

No. It remains relevant for just-in-time application access, where activation triggers accelerated provisioning. For SharePoint, Exchange and Purview roles, however, Microsoft recommends active users in a group eligible for the role, with PIM for Microsoft Entra roles.

Why does the sixth user wait 40 minutes?

Accelerated provisioning covers the first five activations per 10-second window, for each enterprise application. From the sixth onwards, the membership is provisioned at the next synchronisation cycle, that is 40 minutes.

How do we manage group eligibility at scale?

Entitlement Management access packages can assign eligible group memberships and ownerships. The feature has been generally available since November 2025, with self-service requests and extensions.

Are my current PIM scripts affected by an API retirement?

Yes if they call the PIM Iteration 2 beta APIs (Azure resources, Microsoft Entra roles, groups): they will fail from 28 October 2026. Migrate to the Iteration 3 APIs, relying on Microsoft's announcement.

Three actions to reduce the wait this week

If your administration team is small, or if you can automate assignments by script, direct role eligibility is the simplest choice. If you need centralised management, use a role-assignable group with active members and group eligibility for the role. For SaaS, always separate the baseline group and the privileged group. If you are still hesitating between PIM and a third-party tool, our comparison Entra PIM, CyberArk and Delinea lays out the selection criteria.

Going further

• Privileged Identity Management for groups (Microsoft Learn): the two group models, application provisioning and the limit of 5 requests per 10 seconds
• Access error to SharePoint or OneDrive after PIM activation: the 24 h delay and the two official solutions
• Microsoft Entra what's new archive: JIT provisioning, eligible access packages and retirement of the PIM beta APIs
• Privileged Access Groups by Thomas Naunheim: an older expert analysis of propagation delays in M365 portals and the limits of privileged groups