Azure RBAC with PIM: Just-in-Time Access Guide · CloudEngineerHub
Azure9 min read1 views
Just-in-Time Privileged Access: Azure RBAC with PIM Done Right
Standing Owner rights are a breach multiplier. Make Azure RBAC just-in-time with PIM: activation design, approvals, alerting, break-glass discipline, and tiering.
C
CloudEngineerHub Team
Published: September 6, 2026· Last Updated: September 28, 2026·9 min read
Just-in-Time Privileged Access with Azure RBAC and PIM
Standing Owner rights on a production subscription is how breaches become catastrophes and how honest mistakes become outages. Privileged Identity Management (PIM) for Azure resources converts "always-on admin" into "admin for four hours, with a reason, an approval, and a log entry" — and once you've operated that way, going back feels negligent. This guide covers the eligible-vs-active model, the role settings that actually matter, approval and alerting design, break-glass discipline, and the tiered admin model that separates control-plane power from data-plane access.
Visual Walkthrough
Just-in-time privilege: the audited path from standing eligibility to action.
C
CloudEngineerHub Team
Author
The CloudEngineerHub editorial team — Microsoft endpoint management and cloud engineers writing hands-on guides on Intune, Azure, Entra ID, Autopilot, Defender and PowerShell. Every article is reviewed against current Microsoft documentation.
Interactive FlowPIM Activation — Eligible to Active, Safely6/6
1
Eligible assignment
Admin holds the role as eligible — not active — by default.
request
2
Request activation
Justification + ticket reference required by policy.
gate
3
MFA + approval
Authentication strength and approver gate (if configured).
active
4
Time-boxed active role
Role active for the configured window only.
audit
5
Everything audited
Activation, actions and expiry logged for review.
6
Auto-expiry
Window closes; admin returns to eligible state.
PIM Activation — Eligible to Active, Safely. 1. Eligible assignment: Admin holds the role as eligible — not active — by default. — 2. Request activation: Justification + ticket reference required by policy. — 3. MFA + approval: Authentication strength and approver gate (if configured). — 4. Time-boxed active role: Role active for the configured window only. — 5. Everything audited: Activation, actions and expiry logged for review. — 6. Auto-expiry: Window closes; admin returns to eligible state.
Prerequisites
Microsoft Entra ID P2 licensing — PIM for Azure resources is a P2 feature, non-negotiable
Privileged Role Administrator (or Global Administrator) to configure PIM and its role settings
A management group hierarchy that matches your org (at minimum: root MG → platform MG → workload MGs → subscriptions) — PIM settings inherit, so structure precedes policy
Azure Monitor/Log Analytics wired to your subscriptions if you want the detection queries in this guide running on real data
An inventory of current standing assignments: run az role assignment list --all before touching anything
Why PIM for Azure resources, specifically
Two different privileged planes live in Azure and they get confused constantly:
Entra roles (Global Admin, Security Admin) govern the identity control plane.
Azure RBAC roles (Owner, Contributor, Reader, and thousands of data-plane actions) govern Azure resources.
PIM exists for both, but the mechanics differ: Entra role PIM activates through Graph; Azure resource PIM lives in the Azure Resource Manager world, with its own schedules and settings per subscription, resource group, or management group. This guide is about the Azure resource side — where standing Contributor rights on a subscription quietly grant the ability to delete every resource in it.
Eligible vs active: the core mental model
Eligible assignment: the identity may activate the role. Nothing is granted until activation, which is time-boxed, justified, and optionally approved.
Active assignment: the role is live now — time-bound if you're disciplined, permanent if you weren't.
Target state: eligible assignments for humans, zero permanent active assignments for humans, and permanent assignments reserved for managed identities and break-glass accounts. Every "permanent active human assignment" you leave behind is a finding on the next security review.
Bash
1
2
3
4
5
6
7
8
# Before: inventory every standing assignment across the estate
az role assignment list --all --output table
# After: what eligible (not yet activated) assignments exist under a subscription
az rest --method GET \
--url"https://management.azure.com/subscriptions/$SUB_ID/providers/Microsoft.Authorization/roleEligibilitySchedules?api-version=2020-10-01" \
--query"value[].{principal: properties.principalId, role: properties.roleDefinitionId, status: properties.status}" \
-o table
Role settings that actually matter
Per-role settings govern activation behavior — set them at the management group level where they should inherit, and tighten per-subscription where workloads are sensitive:
Setting
Recommended
Why
Max activation duration
4–8 hours
Long windows are standing access with paperwork
Require MFA on activation
Yes
The activation credential is itself privileged
Require justification
Yes
Free-form evidence; enforce a ticket-ID convention
Require ticket information
Yes (for production scopes)
Ties activation to change records
Require approval
Owner/Contributor on prod: yes
Two-person rule for destructive capacity
Approvers
2+ from an on-call group
Any one of them can approve; quorum without bottleneck
Allow permanent eligible assignment
Yes (with access reviews)
Eligibility isn't access; reviews police it
Allow permanent active assignment
No (humans)
Reserve for managed identities and break-glass
The two settings tenants under-tune: activation duration (8+ hours recreates standing access in disguise) and approval for only the roles that can destroy things. Approving every Reader activation is how PIM programs die of friction — calibrate approval to blast radius.
MFA on activation: close the phishing window
Requiring MFA at activation means a stolen password alone can't reach your production control plane — the attacker also needs the second factor at the moment of use. For accounts using phishing-resistant methods (FIDO2, WHfB), activation inherits that strength. This single setting converts PIM from an audit checkbox into a real security control.
Approval workflows without becoming a ticket queue
Approval belongs on production Owner/Contributor and on anything touching data exfiltration paths (storage contributor on sensitive accounts, for instance). Design the approver population like the Intune MAA pattern from the companion discipline: a dedicated group, on-call rotation, a stated SLA (4 business hours is defensible), and an escalation path. Approvers see the justification and ticket ID — which is why the justification convention (CHG0012345 | failover drill) is mandatory from day one.
Field note: A media client approved 100% of activations for eight straight months — the approval workflow had become a rubber stamp. The fix was data: a monthly report of activation count by role and by approver, reviewed in the ops meeting. Approval quality improves the moment someone specific sees approval statistics with their name on them.
Field note: A retail tenant discovered during an access review that their PIM "eligible" assignments were nearly all permanent-active anyway — the previous admin had checked "allow permanent active assignment" on every role because it was faster. Flipping that single setting off and forcing re-eligibility cut standing privileged identities from 61 to 6 in one afternoon, with zero user-facing impact: activation still took under a minute.
Alerting, access reviews, and the evidence trail
PIM for Azure resources generates alerts out of the box — suspicious activations, assignments created outside PIM, stale eligible assignments — and P2 adds access reviews for both eligible and active assignments. Make both real:
Route PIM events into your SIEM. Role assignment writes are visible in the Activity Log, and the queries are simple:
KQL
1
2
3
4
AzureActivity
| where TimeGenerated > ago(30d)
| where OperationNameValue =~ "MICROSOFT.AUTHORIZATION/ROLEASSIGNMENTS/WRITE"
| project TimeGenerated, Caller, ResourceGroup, Properties_d
Any Caller that isn't your PIM automation or an approved break-glass runbook deserves a look — it's how out-of-band assignments get created.
2. Quarterly access reviews on eligible assignments, with recertification by resource owners, not by the identity team guessing.
3. Monitor break-glass usage continuously — see below.
Visual Walkthrough
The five-step evaluation every role assignment request passes.
Decision TreeAzure RBAC Evaluation — Union, then Deny5/5
Decision gate
Action attempted
RBAC is additive (union) until a deny assignment appears.
Assignment matched
1
Scope walk
Check assignments from resource upward: RG → subscription → MG.
2
Union of roles
All matching assignments combine — multiple roles add up.
3
PIM elevation
Eligible roles can be activated for just-in-time access.
4
Action allowed
Data/action permission verified against the role definition.
Deny or none
1
Deny assignment check
Deny assignments always win — read them first.
2
No assignment found
Scope walk came up empty; access denied by default.
3
Request elevation
PIM request or assignment via owner — never widen broadly.
4
Least privilege wins
Smallest sufficient scope is the durable answer.
Azure RBAC Evaluation — Union, then Deny. Gate: Action attempted — Assignment matched: Scope walk — Assignment matched: Union of roles — Assignment matched: PIM elevation — Assignment matched: Action allowed — Deny or none: Deny assignment check — Deny or none: No assignment found — Deny or none: Request elevation — Deny or none: Least privilege wins
Break-glass accounts: designed, sealed, watched
Every tenant needs two cloud-only accounts that survive a catastrophic identity outage — CondId exclusions, hardware-backed credentials (FIDO2 keys in sealed envelopes, multi-party access), Owner at the root management group or on critical subscriptions, and no interactive daily use. The discipline:
Credentials sealed with split knowledge; opening one is an incident-logged event by definition.
Sign-in monitoring that pages on any authentication:
A quarterly "break-glass drill" that actually signs in and performs a read action — proving the path works before the day you need it.
Break-glass accounts are the exception that proves the PIM model: permanent, powerful, sealed, and watched like hawks. Anything less powerful than break-glass should be PIM-eligible.
The tiered admin model: control plane vs data plane
Structure privileged access as layers, and assign identities to exactly one layer:
Data-plane RBAC (Key Vault Administrator, Storage Blob Data Contributor)
Grant via Azure RBAC (not legacy access policies), scoped to specific vaults/containers
3 — Operations
CI/CD identities, managed identities
Least-privileged built-ins
Managed identities with exact-scoped assignments; no human standing access
Two design rules carry most of the value. First, separate administrative identities from daily identities — the admin account that reads email is the admin account that gets phished. Second, cut data-plane scope precisely: a Key Vault RBAC assignment scoped to one vault, not a subscription-wide role "for convenience." Legacy Key Vault access policies are still found in older tenants; migrate to Azure RBAC for the data plane so everything reports and reviews in one system.
Also know the emergency valve at the top: Global Administrators can elevate their own Azure access (the "Access management for Azure resources" toggle in Entra) to gain User Access Administrator at root scope. It's logged and it's auditable — treat any use as an incident-worthy event, because it bypasses your careful tiering.
Key takeaways
PIM for Azure resources (Entra ID P2) converts standing Contributor/Owner rights into time-boxed, justified, optionally approved activations — humans get eligible assignments, permanent active is for managed identities and break-glass only.
Tune per-role settings where they bite: 4–8 hour activations, MFA on activation, justification with ticket-ID convention, approval reserved for production Owner/Contributor and destructive capacity.
Approval workflows need an on-call approver group, a stated SLA, and monthly activation statistics — otherwise they decay into rubber stamps.
Route role-assignment writes and break-glass sign-ins into your SIEM; out-of-band assignments and break-glass usage are the two signals that must page someone.
Run quarterly access reviews on eligible assignments with resource owners as reviewers.
Structure access in tiers (identity/control plane → workload → data plane → operations), split admin from daily identities, and scope data-plane RBAC to specific resources using Azure RBAC rather than legacy Key Vault access policies.
Break-glass: two cloud-only accounts, hardware credentials sealed with split knowledge, permanent top-tier rights, and continuous sign-in alerting with quarterly drills.
Frequently asked questions
Should activations require approval, or is MFA plus justification enough?
For Reader and non-production scopes, MFA plus justification is proportionate. For production Owner/Contributor and sensitive data-plane roles, require approval — the two-person rule matters precisely where one activation can destroy or exfiltrate. The failure mode to avoid is approval everywhere: it floods approvers until they stop reading justifications.
How is PIM for Azure resources different from PIM for Entra roles?
They're separate systems with separate settings: Entra role PIM governs directory roles and activates via Graph, while Azure resource PIM governs RBAC at management group/subscription/resource scope and lives in ARM (its schedules appear under Microsoft.Authorization with their own API versions). Configure both, and don't assume settings copied over — they don't.
What do we do with the service principals that currently hold standing Owner?
Migrate them to managed identities or workload identity federation with least-privileged, exact-scoped assignments, and keep time-bound active assignments where automation genuinely needs elevation. Service principals can't do interactive MFA, so the control shifts to scope precision and CI/CD governance — an Owner-forever app registration is the standing-access problem wearing a different hat.
Comments
0No comments yet — be the first to share your thoughts.