TL;DR: Azure PIM turns permanent Azure role assignments into time-bound activations, but the article argues that least privilege still depends on scope, role design, and recurring access reviews, according to Sonrai Security. Standing privilege remains the real cloud risk when eligibility becomes a substitute for governance.
At a glance
What this is: Sonrai Security explains that Azure PIM can time-bound privileged role use, but it does not by itself solve standing privilege, over-scoped roles, or weak access review discipline.
Why it matters: IAM, PAM, and cloud security teams should treat PIM as one control in a broader privilege-governance model, not as proof that least privilege has been achieved.
Context
Most cloud privilege problems are not caused by a lack of tooling. They persist because permanent role assignments, broad scopes, and stale eligibilities remain in place long after the original need has passed. In Azure, that means the real issue is not only activation control but whether the underlying role model still matches the work.
Just-in-time privileged access reduces the exposure window, but it does not automatically right-size permissions or govern workload identities. For identity teams, the governance question is whether PIM is being used as a gating layer for standing privilege or as evidence that privilege itself has been corrected.
Key questions
Q: What breaks when Azure PIM is treated as least privilege by itself?
A: PIM only governs when a role activates, not whether the role is scoped correctly or still needed. If teams treat eligibility as proof of least privilege, they keep oversized permissions, unmanaged workload identities, and stale assignments in place. The result is time-bounded excess rather than real privilege reduction.
Q: Why does standing privilege still create cloud risk after PIM is enabled?
A: Because the underlying role can remain too broad, even if it is only active for a short time. An attacker who reaches a privileged identity can still exploit the full permission set during the activation window, so the risk moves from permanence to exposure control, not away from excessive access.
Q: What are the signs that Azure PIM is not reducing privilege enough?
A: Watch for long activation durations, broad subscription-level scopes, frequent approvals that users bypass through workarounds, and recurring eligible assignments that are never removed. Those signals indicate that the organisation has time-bounded access on paper but has not actually reduced privilege.
Q: How should teams govern workload identities alongside Azure PIM?
A: They should treat service principals and managed identities as a separate governance stream, because PIM does not natively manage them. That means ownership, scope, rotation, and revocation need dedicated controls, otherwise the strongest controls in Azure only cover the human side of the privilege model.
Technical breakdown
How Azure PIM separates eligibility from activation
Azure PIM introduces two states for privileged access: eligible and active. Eligible means the identity can request elevation, while active means the role is live for a limited period. That split is useful because it forces a deliberate activation step, but it does not change what the role can do. If the scope or role is oversized, PIM simply time-bounds excessive access rather than removing it. The technical distinction matters because access expiry is the actual control, not the eligibility record itself.
Practical implication: Treat eligibility as a gate, not as a substitute for role design or scope review.
Why Azure RBAC and PIM solve different problems
Azure RBAC defines what an identity can do and where it can do it. PIM controls when that RBAC permission becomes active and under what conditions, such as MFA, justification, or approval. That separation is important because teams often assume PIM enforces least privilege on its own. It does not. A Global Administrator assignment remains Global Administrator during activation, and an overly broad subscription role remains overly broad even if it is time-limited. Least privilege still starts with the role model.
Practical implication: Review role scope and permission breadth before deciding whether PIM is even governing the right access.
Where PIM stops in cloud identity governance
PIM covers Azure directory roles, Azure resource roles, and group-based access, but it does not natively manage service principals or managed identities. That gap matters because workload identities are often the identities with the least human oversight and the longest-lived exposure. In practical terms, PIM can reduce standing privilege for human-administered roles while leaving machine access outside the same governance boundary. The broader lesson is that just-in-time access in cloud only works when governance extends beyond interactive users.
Practical implication: Inventory workload identities separately and govern them with controls that match their non-human lifecycle.
Threat narrative
Attacker objective: The objective is to reach an already privileged cloud identity and use its existing permissions to perform high-impact actions without needing to escalate first.
- Entry begins when an attacker reaches an identity that still has standing cloud privilege, rather than needing to defeat a separate escalation barrier.
- Escalation follows the absence of scoping discipline, because an over-privileged role already contains the permissions needed for high-impact actions.
- Impact occurs when permanent or loosely governed access allows resource tampering, credential exposure, or administrative misuse before review cycles catch it.
Breaches seen in the wild
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Standing privilege is the control failure, not just a configuration smell: Azure PIM is useful because it time-bounds role activation, but the deeper issue is that many cloud estates still keep powerful roles alive by default. That means the primary governance problem is not activation workflow, it is the persistence of privilege that should never have remained standing. Practitioners should treat the remaining always-on footprint as the real risk surface.
Just-in-time access does not equal least privilege: A time-limited Global Administrator role is still a Global Administrator role. This article reinforces a pattern we see across cloud programmes: teams adopt temporal controls before they have resolved scope, role design, and review discipline. The result is a narrower exposure window around the same excessive permissions, which is governance theatre unless the underlying assignments are corrected.
Cloud PAM has to extend beyond the PIM boundary: PIM addresses interactive elevation in Azure, but it leaves workload identities, service principals, and multi-cloud privilege outside the same operating model. That creates a split governance model where human admin access is regulated more tightly than machine access. The practitioner implication is clear: privilege governance has to follow the identity, not the cloud console.
Azure PIM exposes the access-review illusion: Review cadences are only useful when they examine privilege that still persists long enough to matter. If the organisation relies on eligibility as proof of control, the review process becomes a record of potential access rather than a governance check on actual blast radius. The right question is whether the programme is reducing privilege or merely documenting its existence.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: AI Agent Authorisation Guide
What this signals
Standing privilege is still the cloud norm: Even in organisations that adopt just-in-time access, the hard part is removing old assignments, narrowing scope, and keeping workload identities out of the blind spot. PIM improves the timing of access, but it does not automatically change the ownership model behind the privilege.
Ephemeral activation only works when the underlying entitlement is correct: Time-bounding a role is useful, but the control only shrinks blast radius if the role itself is small enough to begin with. That is why access reviews, role refactoring, and workload identity governance have to move together rather than being treated as separate projects.
For practitioners
- Review standing privileged assignments first Inventory permanent Global Administrator, Owner, and other high-sensitivity assignments before enabling activation controls. Remove old grants, document why each one still exists, and fix the role model before expanding PIM coverage.
- Scope every privileged role narrowly Limit each assignment to the smallest management group, subscription, resource group, or resource that can support the task. A time-limited role with broad scope still creates a large blast radius during activation.
- Set activation windows by task duration Use the actual administrative task as the ceiling for how long a role can remain active. Avoid long windows that simply recreate standing privilege with an expiry timer.
- Separate workload identity governance from PIM Track service principals and managed identities outside the PIM workflow and apply dedicated controls for ownership, authentication, and lifecycle revocation.
- Run recurring access reviews on live privilege Review both eligible and active assignments on a fixed cadence, then act on the results. Eligibility without follow-up action only confirms that stale access still exists.
Key takeaways
- Azure PIM reduces exposure windows, but it does not eliminate standing privilege if roles stay broad or permanently over-assigned.
- The operational evidence in the article is clear: most cloud programmes still struggle with always-on privilege and incomplete just-in-time adoption.
- The control that changes the outcome is not activation alone, but the combination of scope reduction, recurring access review, and separate governance for workload identities.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article centres on cloud roles that remain broader than the task requires. |
| NHI-01 — Improper Offboarding | Stale privileged assignments persist because access is not removed when need ends. | |
| Recommendation — Review cloud role scopes and remove excess privilege before enabling time-bound activation. Revoke unused privileged assignments on a recurring schedule and after role changes. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege is the main control principle behind the article's Azure PIM guidance. |
| Recommendation — Apply AC-6 to ensure every privileged role is narrowed to the minimum scope required. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article focuses on reviewing, activating, and removing privileged access over time. |
| Recommendation — Use CIS-5 to govern privileged account lifecycle, review cadence, and deprovisioning. | ||
| MITRE ATT&CK | TA0004;TA0006 — Privilege Escalation; Credential Access | The risk path is attackers reaching already privileged cloud identities. |
| Recommendation — Map standing privilege exposures to TA0004 and TA0006 in detection and response planning. | ||
Key terms
- Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
- Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.
- Privilege Access Management: Privilege Access Management is the discipline of controlling and monitoring elevated access to critical systems and data. It governs how privileged accounts, credentials, sessions, and commands are issued, used, recorded, and revoked, so administrative power is limited, traceable, and aligned to policy, risk, and operational need.
- Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 20, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org