We often see PIM switched on with every role using the same approval path. Ordinary support work then takes longer than it needs to.
We configure each role around the work it can do. Global Administrator can have a short approval path. A helpdesk role can self-activate for the working window. That is just-in-time (JIT) access. The role is eligible until it is needed, then active only for the window we set. We protect access that can change authentication, policy or the whole tenant. We remove clicks that add no useful protection.
This is the model we use. Build the emergency path first. Then configure the roles and test activation from an ordinary administrator account. Only then remove standing access.
Build break-glass before changing administrator access
Create and test two cloud-only break-glass accounts before you move normal administrators into PIM. Microsoft warns that lockout can happen when every Global Administrator and Privileged Role Administrator is eligible. If approval is also required, nobody may be active to approve the request.
Build and test the emergency path first. The break-glass build and drill covers that process. Then return here and make human administrators eligible.
- Confirm both accounts can sign in.
- Confirm the sign-in alert reaches the people who monitor it.
- Only then move human administrators from active to eligible.
Configure each role for the work it can do
PIM keeps separate settings for every Entra role. A password reset shouldn't follow the same path as a change to Conditional Access.
| Setting | Routine service role | Control-plane role |
|---|---|---|
| Assignment | Eligible | Eligible |
| Activation duration | Up to the working window | 4 hours maximum |
| Justification | Required | Required |
| MFA on activation | Required | Required |
| Approval | Self-activation where the role is narrow | Required for Global Administrator and equivalent access |
| Approver | Not normally required | Named manager, director or control-plane owner |
| Notification | Role owners and security monitoring | Role owners and security monitoring |
Approval should follow impact, not job title
An approver doesn't need an administrator role because they only confirm the work was expected. That lets a director or manager approve a high-impact request without permanent access.
Microsoft recommends at least two approvers. For a small business, one named approver can work once two tested break-glass accounts are in place. Larger teams should use at least two. The person asking for access shouldn't approve it.
Approvers also need an Entra ID P2 or Entra ID Governance licence. Count them before you build the workflow.
Scale the model to the team
One internal IT person shouldn't spend the day waiting for a manager to approve ordinary work. A larger IT team needs separate paths for junior support, senior administrators and managers. It also needs a small group that can change the control plane. MSPs need that separation in their own tenant, in each client tenant and through GDAP.
Choose the total staff, IT-team size and firm type below. The recommendation changes routine access, high-impact approval and the GDAP model. It doesn't give every technician the same path.
Build your access model
Choose the organisation, IT team and firm type. The model below updates to match.
Recommended model
Keep routine access simple and make high-impact access obvious
One internal IT person should not need a manager to approve ordinary work all day. Give that person eligibility for the narrow roles they use, then make Global Administrator and other control-plane roles shorter and louder.
Routine work
Self-activation for the specific service role, with FIDO2, a reason, alerts and up to four hours. Prepare planned work in advance and request only the role and scope it needs.
High-impact access
Global Administrator, Privileged Role Administrator, Conditional Access Administrator and Privileged Authentication Administrator activate for no more than one hour. Use fresh phishing-resistant authentication and notify the business owner. Add owner approval where the delay will not stop an incident response.
Controls to apply
- One separate everyday account and one separate privileged account
- FIDO2 on the privileged account
- Two YubiKey-backed break-glass accounts outside PIM
- No permanent human administrator role
Review cadence
Review eligibility every six months and whenever the IT owner changes.
Make activation quick without making it automatic
PIM doesn't appear like a Windows UAC prompt. If a role isn't active, the administrator gets access denied. They must activate it in My roles first. We make that trip shorter with the Azure mobile app or the saved PowerShell command below. For planned work, they can also schedule a start time.
The command finds the signed-in user's eligible role by display name. It then sends Microsoft Graph a selfActivate request. It keeps the reason, duration and audit record. It stops if the same role exists at more than one scope. The administrator then chooses the right scope in the portal.
The script uses Microsoft's current v1.0 request shape. Test it with an eligible low-impact role before you use it for production work. Your role policy may still require approval, ticket details or an authentication context.
param(
[Parameter(Mandatory)] [string] $Role,
[Parameter(Mandatory)] [string] $Reason,
[ValidateRange(1, 4)] [int] $Hours = 2
)
Import-Module Microsoft.Graph.Authentication
Connect-MgGraph -Scopes @(
'RoleEligibilitySchedule.Read.Directory',
'RoleAssignmentSchedule.ReadWrite.Directory'
)
$me = Invoke-MgGraphRequest -Method GET -Uri '/v1.0/me'
$uri = "/v1.0/roleManagement/directory/roleEligibilityScheduleInstances?`$filter=principalId eq '$($me.id)'&`$expand=roleDefinition"
$eligible = (Invoke-MgGraphRequest -Method GET -Uri $uri).value |
Where-Object { $_.roleDefinition.displayName -eq $Role }
if (-not $eligible) { throw "No eligible PIM assignment found for '$Role'." }
if (@($eligible).Count -gt 1) { throw "More than one eligible '$Role' assignment was found. Activate it in the portal and confirm the required scope." }
$body = @{
action = 'selfActivate'
principalId = $me.id
roleDefinitionId = $eligible.roleDefinitionId
directoryScopeId = $eligible.directoryScopeId
justification = $Reason
scheduleInfo = @{
startDateTime = (Get-Date).ToUniversalTime().ToString('o')
expiration = @{ type = 'AfterDuration'; duration = "PT$($Hours)H" }
}
} | ConvertTo-Json -Depth 5
Invoke-MgGraphRequest -Method POST -Uri '/v1.0/roleManagement/directory/roleAssignmentScheduleRequests' -Body $body -ContentType 'application/json'Use fresh authentication where the role needs it
The standard MFA setting may accept authentication from the current session. Where a role needs a fresh check at activation, we use a Conditional Access authentication context. An Authentication Strength makes the check phishing-resistant. You configure that for each role.
Create and enable the matching Conditional Access policy first. Then configure the authentication context in PIM. If no policy targets that context, PIM requires MFA as a backup. Test the full activation path, including the emergency accounts, before you enforce it.
Test what happens after activation and expiry
Microsoft adds and removes the active assignment within seconds. The application you are administering may still cache the old role. You may need to sign out and back in before new access appears. Cached access can also remain visible briefly after deactivation.
We test one activation through every admin surface the role should use. Then we test expiry and manual deactivation. That shows the team what normal looks like before they need to change something during an incident.
- Activate the narrow role and confirm the request is recorded.
- Confirm approval and notification delivery where enabled.
- Open each admin portal the role needs.
- Deactivate early and confirm the access disappears.
- Record any portal that needs a new session before the role changes appear.
What we check during an audit
We read assignments, eligibility, role settings, the approval chain and activation history together. We also check roles that can reset authentication or alter applications. Those roles need the same review as Global Administrator.
| What we find | What we report |
|---|---|
| Human Global Administrator permanently active | High-impact standing access and the eligible role required |
| Approval required with no named approver | Lockout risk and the approver configuration required |
| Every role requires manager approval | Review routine roles so the control remains usable |
| Eight-hour activation on a high-impact role | Reduce the maximum to the real working window |
| Eligible assignment with no recent use or review | Confirm the person still needs the role |
| No PIM licence | Report the control as not licensed and provide the licence requirement |
Start with one role and run it properly
Build the emergency accounts, choose one administrator and put one high-impact role through this process. Activate it, approve it, use it and let it expire. Once the team knows how the workflow feels, move the remaining roles across in risk order.
The finished model should make routine work easy and high-impact access obvious. If every request feels equally difficult, work on the role design.
Questions people ask
- With PIM, do I have to assign myself admin access manually every time?
- You activate an eligible assignment when you need it. PIM doesn't prompt when an admin page needs more access. You get access denied until you activate the role. Use My roles, the Azure mobile app or the saved command on this page.
- Can elevation be automatic?
- We don't make it automatic because the reason, duration and activation record are the control. The Graph command removes most of the clicking and keeps that record. A future start time lets planned work begin when it is needed.
- Can PIM restrict which roles somebody can request?
- Yes. A person can only activate a role they are already eligible for. Give them the exact roles and scope their job needs. Every role can have its own activation settings.
- Who approves if nobody is a permanent Global Administrator?
- The approver doesn't need an administrator role. A manager, director or owner can approve it because they only confirm the work was expected. Approvers need an Entra ID P2 or Entra ID Governance licence.
- Does every PIM activation need manager approval?
- No. You configure approval for each role. We allow self-activation for narrow routine roles with MFA, a reason, a short window and alerts. That gives enough control. We require approval for roles that can change authentication, policy or the whole tenant.
- Can a junior technician activate password reset access for a shift?
- Yes. Make the technician eligible for the narrow support role or a PIM-enabled group. Set a window that matches the shift. Don't make them request Global Administrator for ordinary helpdesk work.
- What if we don't have P2?
- Reduce standing administrators first. That costs nothing and removes much of the exposure. PIM requires Entra ID P2 or Entra ID Governance for eligible users, approvers and reviewers.