By the end of this sheet you have a tenant where Global Administrator and Security Administrator are held eligible rather than standing, each with a deliberate activation window, a named approver population, and a recorded justification, and you have proved it works by activating a role, finding the three audit events it produced, and deactivating it again. This is the first role set, not the last one, and doing it small is the point.
Before you start
You need Microsoft Entra ID P2 or Microsoft Entra ID Governance licences covering every user who will hold an eligible assignment plus every user who will approve one, since approvers consume the pool whether or not they ever hold the role. You need at least Privileged Role Administrator to edit role settings and create assignments, and in practice you will want Global Administrator for the first pass. You need at least two emergency access accounts already in place, permanently and actively assigned Global Administrator, before you convert anything, because the whole point of this exercise is removing standing access and you do not want the tenant’s only standing access to be the thing you just removed. If those accounts do not exist yet, build them first; the article on the role model in this wave covers what they should look like in 2026, and it is not what most runbooks still say. Finally, you want the Microsoft Graph PowerShell SDK installed if you intend to use the consolidated block at the end, and the RoleManagement.ReadWrite.Directory scope consented.
Step 1: Record the current state before you change a single setting
Microsoft does not publish the out-of-box values of the PIM role policies, and the values circulating in blog posts are unsourced. The only trustworthy baseline is the one you read out of your own tenant, so read it first and keep it.
In the Microsoft Entra admin center, go to ID Governance, then Privileged Identity Management, then Microsoft Entra roles. Open Roles, select Global Administrator, and open Role settings. Write down four numbers and one word: the Activation maximum duration, the current value of On activation, require, whether Allow permanent eligible assignment is on, whether Allow permanent active assignment is on, and the two expiry durations if they are not permanent. Repeat for Security Administrator. Do this before you touch anything, because these are the numbers you will be asked to justify changing, and because a policy someone tuned two years ago is exactly the kind of artefact that survives a redesign by being invisible.
While you are on the same page, capture the standing assignments themselves. In Microsoft Entra roles, open Assignments and filter to the Active tab, then export. That export is your rollback plan and your evidence pack. The single most common way this work goes wrong is that somebody converts an assignment they did not realise a service depended on, and the export is what turns that from an outage into a five-minute reversal.
Step 2: Pick the first role set, and keep it to two
Microsoft’s deployment plan is unambiguous about where to begin: ensure that all Global Administrator and Security Administrator roles are managed using PIM first, because they are the users who can do the most harm when compromised. That is the right starting pair and I have never found a reason to argue with it. Global Administrator is the obvious one. Security Administrator is the one people forget, and it is arguably the more dangerous omission, because a Security Administrator can edit Conditional Access policy, which means they can weaken or remove the very controls you are about to build on top of activation.
Resist the urge to convert twenty roles in the first pass. Two roles converted properly, with the settings understood and the users trained, is a foundation. Twenty roles converted in an afternoon is a support queue, and the fastest way to have a PIM rollout reversed by an executive is to have it break something on a Friday. The roles in the tables below beyond the first pair are there so you can see how the reasoning changes with the role’s shape, and they are the natural second and third waves rather than part of this one.
Step 3: Configure the role settings
Still in Role settings for Global Administrator, choose Edit. The settings below are Microsoft’s own deployment-plan example posture with my reasoning attached, and they are the posture I ship.
| Setting | Value | Why |
|---|---|---|
| Activation maximum duration | 1 hour | Global Administrator work is bursty and specific. An hour is enough to do a tenant-level change and short enough that a forgotten activation closes itself before the end of a meeting. If an hour genuinely is not enough, that is usually a sign the task belongs to a lesser role. |
| On activation, require | Microsoft Entra Conditional Access authentication context | The multifactor authentication option reuses the claim from the morning sign-in and therefore challenges nobody in the common case. The authentication context option issues a real claims challenge that a Conditional Access policy you control answers. Set this to multifactor authentication for now if the context is not built yet, and treat it as temporary: the build sheet for that policy is later in this wave and it is the highest-value change here. |
| Require justification on activation | Yes | Free text, unvalidated, and still worth having. It is the field that makes an audit record legible to a human six months later, and it costs the user four seconds. |
| Require ticket information on activation | Yes | Correlation with a ticketing system is not enforced, so this is documentation rather than control. Enable it anyway on the tenant-wide roles: it changes what people type into the justification box, and it gives the reviewer a thread to pull. |
| Require approval to activate | Yes, approvers explicitly selected | Global Administrator is the role where a second human genuinely adds signal. Leaving approvers unselected silently falls back to the active Privileged Role Administrators and Global Administrators, which makes the approver population accidental. Select it deliberately, and select at least two people. |
| Allow permanent eligible assignment | No, expire eligible assignment after 6 months | Eligibility is a smaller liability than standing access, not a free one. Forcing renewal is what stops the project-based grants of 2023 from still being live in 2027. |
| Allow permanent active assignment | No | This is the switch that protects the design from its own administrators. With it off, nobody can grant standing Global Administrator without an end date, including the person who set it. The emergency access accounts are the deliberate exception and are excluded from this work entirely. |
| Require multifactor authentication on active assignment | Yes | Challenges the administrator creating a direct active assignment, at the moment of creation. It does not challenge the recipient and it does not challenge anyone using the role, so do not count it as a use-time control. |
Security Administrator takes the same shape with one deliberate difference: give it a two-hour activation window rather than one. Security work involves reading through a lot of signal before acting, and a one-hour window on an investigative role produces re-activations rather than discipline. Keep approval on it, because the ability to edit Conditional Access policy is exactly the capability that could unwind the activation controls this wave is building.
For the second and third waves, the reasoning shifts with the role. These are the postures I use, and each of them tracks Microsoft’s own example rows in the deployment plan.
| Role | Duration and gates | Why the shape changes |
|---|---|---|
| Exchange Administrator | 2 hours, authentication required, no ticket, no approval | Two reasons for the longer window and the missing gates. Exchange work is genuinely longer-running than directory work, and in my experience the role takes noticeably longer than the directory’s few seconds to become usable in the workload itself, so a short window burns part of itself on propagation. Microsoft publishes no number for that lag on the direct role path, so treat it as practitioner observation rather than a documented figure. Approval and the ticket field are both dropped because this role is used often enough that either one degrades into a reflex, which matches Microsoft’s own example posture for it. |
| Helpdesk Administrator | 8 hours, ticket required, no approval | This is a shift-shaped role, not a task-shaped one. An eight-hour window matches a working day and produces one activation per shift instead of six. The ticket field is the control that matters here: every helpdesk action should already have a ticket, so requiring one costs nothing and makes the audit trail correlate with the service desk. |
| Privileged Role Administrator | 1 hour, approval by another Global Administrator | This is the role that edits PIM itself. Treat it exactly as strictly as Global Administrator, because someone holding it can rewrite every setting in this table. |
Step 4: Design the approver population, and name it
Approvers can be selected as individual users or as groups, and you should almost always select a group, because individuals leave and a policy that names a departed employee is a policy that has quietly stopped working. Create a normal Entra security group, assigned membership, and put the humans in it.
Use a naming convention that survives the estate growing. Mine is SEC-PIM-Approvers-<Role>, so the Global Administrator approver group is SEC-PIM-Approvers-GlobalAdmin and the Security Administrator one is SEC-PIM-Approvers-SecurityAdmin. The prefix groups everything security-owned in an alphabetical list, the middle segment tells the next administrator which product created the dependency, and the suffix means you never have to open a group to know what it gates. Give each group a description that names the PIM policy it serves, because the link from group to policy is not discoverable from the group object.
Worked example. A four-person identity team runs a tenant. Two of them, the identity lead and the infrastructure manager, are eligible for Global Administrator. All four are eligible for Security Administrator. The approver group for Global Administrator, SEC-PIM-Approvers-GlobalAdmin, contains the identity lead, the infrastructure manager, and the head of IT, who holds no privileged role at all and never activates anything. That last inclusion is the design decision worth copying. Because nobody can approve their own request, a two-person approver group made only of the two eligible users means either of them can be blocked by the other’s absence, and both of them are approving each other’s work in a closed loop. Adding a third approver who is outside the activation population breaks the loop, guarantees cover, and puts one person in the chain whose only job at that moment is to ask why. That person costs one licence from the pool, and it is the best-value licence in the tenant.
Two failure modes to check for before you move on. If every Global Administrator and Privileged Role Administrator ends up eligible-only, approval required, and no approver is actually able to act, tenant administration is locked, and the documented way out is the emergency access accounts. And approval requests expire after twenty-four hours with no configurable window, so an approver population that is entirely in one timezone and takes a long weekend will produce resubmissions rather than approvals. Check the coverage, not just the count.
Step 5: Convert the standing assignments to eligible
Now the actual conversion, and PIM ships a tool that makes it a bulk operation rather than a manual grind. Under Privileged Identity Management, open Discovery and insights for Microsoft Entra roles, still marked preview and still the fastest path. It offers three workstreams. Reduce Global Administrators lists the current Global Administrators with the option to Make eligible in bulk or to Remove assignment outright. Eliminate standing access extends the same treatment to the other privileged roles. Review service principals lists non-human identities holding privileged roles, and offers only removal, for the structural reason covered in the anchor article: a service principal cannot be made eligible because it cannot activate.
The Reduce Global Administrators flow also offers to require all Global Administrators to review their own access, which is a reasonable thing to run alongside the conversion in a large estate and unnecessary in a small one where you already know every name on the list. Work through Global Administrator first. For each standing assignment, the decision is one of three: make it eligible, remove it entirely because the person does not need the role at all, or leave it active because it is an emergency access account. There is no fourth answer, and “leave it for now, we will look at it later” is how estates end up back where they started. If you cannot decide, remove it and let the person ask, which they will do within a day if they genuinely needed it and never will if they did not.
Do the conversion in one sitting per role and tell the affected users before you do it, not after. The user experience change is real: the role disappears from their account until they go and get it. An administrator who discovers that alone, mid-incident, becomes an opponent of the project permanently.
When you are finished, the target state for each converted role is zero permanently active assignments other than the emergency access accounts. That is Microsoft’s own wording and it is the number to hold yourself to. If the conversion goes wrong, the reversal is symmetrical and immediate: the assignment can be made active again from the same blade, which is why the export from Step 1 was worth taking.
Step 6: The end-to-end test
Nothing above is finished until someone has actually activated a role and you have found the evidence. Use a real eligible user, not yourself if you are also an approver, because the no-self-approval rule will make the test misleading.
Have the user open Privileged Identity Management, then My roles, then Microsoft Entra roles, and select Activate against Global Administrator. They should be asked for a duration no longer than one hour, a justification, and a ticket reference, and the request should then sit pending approval rather than completing. An approver receives an email and approves it from Approve requests. Expect the email to take between three and ten minutes in most tenants; Microsoft’s own figure is that ninety percent arrive in that window and some take up to fifteen minutes. If it has not arrived in twenty, the approver is not who you think it is.
Once approved, the assignment exists within seconds in the directory. Have the user confirm they can perform a Global Administrator action, and expect at least one workload to lag: the documented remedy is signing out and back in, and it is not a workaround, it is how token-based role state works.
Now find the evidence. In the Entra audit log, filter Service to PIM and look for the trio the activation produced: Add member to role requested (PIM activation), the approval event, and Add member to role completed (PIM activation). The ticket number appears on the Activity tab of the request event. The approver is the actor shown as Initiated by on the approval event, and the requester appears on the Targets tab. When the window expires, or when the user deactivates by hand, a fourth event appears: Remove member from role (PIM activation expired). If you cannot find these four events, the activation did not happen the way you think it did, and the audit trail is the only witness that does not have an opinion.
Finish by having the user deactivate manually. They will not be able to do it in the first five minutes: an assignment cannot be removed within five minutes of being created. That is the guardrail, not a fault, and knowing it in advance saves a support call. While you are in the audit log, look once for the event named Add member to role outside of PIM (permanent). It should be absent. Its presence, now or at any point in the future, means somebody has granted a standing assignment through the ordinary roles experience and walked around everything you just built. That single event name is the most valuable thing in this article to put into a saved query.
The same work as one runnable block
The portal is the right teaching medium for a first pass because the settings page is where the reasoning lives. For a repeat, for a second tenant, or for a change you want under version control, here is the equivalent in Microsoft Graph PowerShell. The role settings are expressed as rules on a unifiedRoleManagementPolicy, each rule addressed by a fixed identifier, and the two that carry most of the posture above are Expiration_EndUser_Assignment for the activation window and Enablement_EndUser_Assignment for the justification, ticket and multifactor requirements.
# Written against Microsoft.Graph PowerShell 2.38.1 and Microsoft Graph v1.0.
# Pin the module if you are scripting this for reuse. Cmdlet parameter sets move
# between releases, and a sheet that does not say what it was written against ages
# badly and fails in ways that look like your mistake.
$ErrorActionPreference = 'Stop'
# Two different scopes are needed: one for the assignments, one for the policy rules.
# The request cmdlets live in Microsoft.Graph.Identity.Governance;
# the policy-rule cmdlets live in Microsoft.Graph.Identity.SignIns.
Connect-MgGraph -Scopes "RoleManagement.ReadWrite.Directory",
"RoleManagementPolicy.ReadWrite.Directory",
"Directory.Read.All"
# CONTEXT ASSERTION. Fill these in before you run anything below. A build sheet
# executed against the wrong tenant is the worst outcome this series can produce,
# and the check costs two lines.
$ExpectedTenantId = '<your tenant id>'
$ExpectedAccount = '<the account you intend to be>'
$mgContext = Get-MgContext
if ($mgContext.TenantId -ne $ExpectedTenantId) { throw "Wrong tenant: $($mgContext.TenantId)" }
if ($mgContext.Account -ne $ExpectedAccount) { throw "Wrong identity: $($mgContext.Account)" }
# PIM assignment and activation requests are asynchronous. Poll to a terminal
# state before asserting success, and never remove access on the strength of a
# request that is still pending. The status values below are the documented set
# on the Graph request resource, which these requests inherit: Canceled, Denied,
# Failed, Granted, PendingAdminDecision, PendingApproval, PendingProvisioning,
# PendingScheduleCreation, Provisioned, Revoked, ScheduleCreated. Two of those
# are deliberately not in $done. ScheduleCreated is transitional on these
# surfaces: no Entra role or PIM for Groups example rests a request there, and
# every call below settles at Provisioned, or Revoked for a removal. Granted is
# where a future-dated activation parks until its start time, and it stays
# cancelable; nothing below is date-shifted, so Granted is transitional here
# too. Date-shift a scheduleInfo block and neither is safe to leave out.
function Wait-Pim {
param([scriptblock]$Refresh, [int]$TimeoutSec = 120)
$done = @('Provisioned','Revoked')
$failed = @('Failed','Denied','Canceled')
$waiting = @('PendingApproval','PendingAdminDecision')
$deadline = (Get-Date).AddSeconds($TimeoutSec)
do {
Start-Sleep -Seconds 5
$r = & $Refresh
if ($r.Status -in $waiting) {
# Expected whenever the policy requires approval. Not a failure.
Write-Host "Request is $($r.Status): waiting on an approver, which is the gate working. Re-run this poll after the decision."
return $r.Status
}
} until ($r.Status -in ($done + $failed) -or (Get-Date) -gt $deadline)
if ($r.Status -in $failed) { throw "Request ended '$($r.Status)'." }
if ($r.Status -notin $done) { throw "Still '$($r.Status)' after $TimeoutSec seconds." }
$r.Status
}
# 1. Resolve the role by its immutable ID, then confirm the ID is what you think.
# Never key a state change on a display name: names are localised, and Microsoft
# renames them (Password Administrator became Helpdesk Administrator).
$RoleId = '62e90394-69f5-4237-9190-012177145e10' # Global Administrator
(Get-MgRoleManagementDirectoryRoleDefinition -UnifiedRoleDefinitionId $RoleId).DisplayName
$assignment = Get-MgPolicyRoleManagementPolicyAssignment `
-Filter "scopeId eq '/' and scopeType eq 'DirectoryRole' and roleDefinitionId eq '$RoleId'"
$policyId = $assignment.PolicyId
# 2. Read the current state FIRST. This is Step 1 of the sheet, in one line.
Get-MgPolicyRoleManagementPolicyRule -UnifiedRoleManagementPolicyId $policyId |
Select-Object Id, AdditionalProperties | Format-List
# 3. Activation maximum duration = 1 hour.
# Rollback: re-run this with the maximumDuration you recorded in step 2.
$expiration = @{
"@odata.type" = "#microsoft.graph.unifiedRoleManagementPolicyExpirationRule"
id = "Expiration_EndUser_Assignment"
isExpirationRequired = $true
maximumDuration = "PT1H"
target = @{ caller = "EndUser"; operations = @("all"); level = "Assignment" }
}
Update-MgPolicyRoleManagementPolicyRule -UnifiedRoleManagementPolicyId $policyId `
-UnifiedRoleManagementPolicyRuleId "Expiration_EndUser_Assignment" -BodyParameter $expiration
# 4. Require justification, ticket, and multifactor authentication on activation.
# Swap MultiFactorAuthentication out once the authentication context is built;
# that is a different rule (AuthenticationContext_EndUser_Assignment) and its own build sheet.
# Rollback: re-run this with the enabledRules you recorded in step 2.
$enablement = @{
"@odata.type" = "#microsoft.graph.unifiedRoleManagementPolicyEnablementRule"
id = "Enablement_EndUser_Assignment"
enabledRules = @("Justification","Ticketing","MultiFactorAuthentication")
target = @{ caller = "EndUser"; operations = @("all"); level = "Assignment" }
}
Update-MgPolicyRoleManagementPolicyRule -UnifiedRoleManagementPolicyId $policyId `
-UnifiedRoleManagementPolicyRuleId "Enablement_EndUser_Assignment" -BodyParameter $enablement
# 5. Make a standing administrator eligible instead, expiring in 6 months.
# Rollback: same call with action = "adminRemove".
$user = Get-MgUser -UserId "[email protected]"
$req = New-MgRoleManagementDirectoryRoleEligibilityScheduleRequest -BodyParameter @{
action = "adminAssign"
principalId = $user.Id
roleDefinitionId = $RoleId
directoryScopeId = "/"
justification = "PIM rollout wave 1: convert standing GA to eligible"
scheduleInfo = @{
startDateTime = (Get-Date).ToUniversalTime()
expiration = @{ type = "afterDuration"; duration = "P180D" }
}
}
Wait-Pim { Get-MgRoleManagementDirectoryRoleEligibilityScheduleRequest `
-UnifiedRoleEligibilityScheduleRequestId $req.Id }
# 6. Remove the standing ACTIVE assignment that is now redundant. DESTRUCTIVE, and
# it is only safe because step 5 reached a terminal state above. Do not reorder these.
# Rollback: same call with action = "adminAssign" plus a scheduleInfo block.
$req = New-MgRoleManagementDirectoryRoleAssignmentScheduleRequest -BodyParameter @{
action = "adminRemove"
principalId = $user.Id
roleDefinitionId = $RoleId
directoryScopeId = "/"
}
Wait-Pim { Get-MgRoleManagementDirectoryRoleAssignmentScheduleRequest `
-UnifiedRoleAssignmentScheduleRequestId $req.Id }Three failure modes to expect from that block. The policy assignment filter is the part people get wrong: scopeType must be DirectoryRole and scopeId must be the single forward slash that means tenant root, and a mistyped filter returns an empty collection rather than an error, so the script then fails on a null policy identifier several lines later with a message that points nowhere near the real problem. Check that $policyId is populated before you continue. The second is the scope split: managing assignments and managing the policy rules that govern them are separate permissions, and consenting only to RoleManagement.ReadWrite.Directory gets you a script that creates assignments happily and then fails on the first policy update. The third is ordering: run step 6 before step 5 and you will have removed a person’s access before granting them the eligibility that replaces it, which is a self-inflicted outage of exactly the length of your attention span.
One honest boundary. There is no supported way to script the bulk Make eligible action from Discovery and insights as a single call; the equivalent is enumerating the active assignments and issuing the pair of requests above for each one, which is what the block does for a single user. The portal experience is genuinely the faster path for the first conversion, and the script is the right medium for everything after it.
Where this goes next
You now have a working just-in-time estate for two roles, with the audit trail to prove it and a rollback path if it bites. Two things are deliberately unfinished. The activation gate is still the weak one, because On activation, require is set to multifactor authentication and that reuses the morning’s claim; replacing it with an authentication context backed by a phishing-resistant strength is the highest-value change left, and it has its own doctrine article and build sheet in this wave. And this pattern does not scale past a handful of roles, because the policy is per role and tenant-wide, so two populations who need the same role under different conditions cannot both be served. The answer to that is groups, and that is the next article.
Governance
‹ Previous: [PIM 2] The Assignment Model: Roles, Settings, and the Shape of an Activation
Next: [PIM 3] PIM for Groups: Privilege in Bundles ›
