TL;DR: Standing privilege in Azure leaves users, service principals, managed identities, automation, vendors, and AI agents with access that outlives the work, expanding blast radius even when authentication is strong, according to Sonrai Security. The real control problem is permissions, not sign-in, and JIT only works when it covers every identity type and right-sizes roles first.
At a glance
What this is: This is an analysis of just-in-time access in Azure, with the central finding that standing privilege, not login strength, is what keeps cloud blast radius large.
Why it matters: IAM, PAM, and NHI teams need to treat Azure access as a permissions problem across every identity type, or JIT will miss the identities that matter most.
Context
Just-in-time access in Azure is a permissions-control pattern, not a login control. It assumes access should exist only when work is active, then disappear when the task ends, which is why standing privilege becomes the real governance gap for cloud identity programmes.
The article focuses on how that gap extends beyond human admins to service principals, managed identities, automation, third parties, and AI agents. Once permission persists after the task is over, the environment carries residual blast radius that traditional authentication controls do not remove.
Key questions
Q: What breaks when Azure JIT only covers human admins?
A: A JIT programme that stops at human administrators leaves service principals, managed identities, automation, vendors, and AI agents with standing permission. That means the real blast radius remains intact even if human access is temporary. The governance failure is selective coverage: the identities most likely to hold durable permissions are excluded from the control model.
Q: Why does standing privilege increase the impact of compromised cloud credentials?
A: Standing privilege leaves access available even when it is not actively needed, which gives attackers a larger window to reuse stolen credentials. In AWS and other cloud platforms, that makes compromised accounts more useful for lateral movement, data access, and persistence. Time-limited access reduces that exposure by shrinking the period in which stolen credentials remain valid.
Q: How do security teams know whether JIT is actually reducing risk?
A: Measure the privilege width of each grant, the frequency of repeated elevations, and how often sessions remain active after the task is complete. If users repeatedly request broad access for routine work, or if sessions continue after the business need ends, JIT is acting as a convenience layer rather than a control improvement.
Q: What is the difference between Entra PIM and network-based JIT VM access?
A: Entra PIM governs privileged role activation at the IAM layer, so it controls whether an identity has a privileged permission and for how long. Network-based JIT VM access only opens management ports temporarily. One limits authorisation, the other limits connectivity, and both are needed when Azure privilege and access paths must be controlled separately.
Technical breakdown
Why standing privilege persists in Azure role assignments
In Azure, the risky object is often the permission itself rather than the credential used to get there. An identity can authenticate through SSO, a managed identity, or another non-password path and still retain broad access long after the original task ended. That is why standing privilege survives in human accounts, service principals, and automation alike. The problem is lifecycle drift: access is granted for one need, then never revisited when the need changes. JIT changes the default from persistent entitlement to time-bound activation, which narrows exposure without forcing a redesign of the entire cloud estate.
Practical implication: Treat Azure permission review as a lifecycle issue, not an authentication issue.
How Azure JIT differs from traditional PAM
Traditional PAM was built around protected privileged sessions, usually for on-premises infrastructure. Azure shifts the control point to the permissions layer, where an identity may not need a vault-brokered password at all. Network controls can limit how a user reaches a VM, but they do not change what that identity can do once authenticated. That is why Azure access control has to focus on role scope, entitlement state, and task-limited authorization rather than only session brokering. The article’s core architectural point is that the entry path and the permission boundary are separate problems, and Azure makes the second one dominant.
Practical implication: Align PAM design to permission scope and activation state, not just session mediation.
Why non-human identities make Azure JIT harder
Service principals, managed identities, CI/CD automation, vendor accounts, and AI agents often carry the permissions that human admins never touch directly. These identities usually fall outside the normal review paths, even though they can read secrets, alter role assignments, or operate across subscriptions. In practice, this means a JIT programme that only covers humans leaves the largest residual access surface untouched. The article’s message is that cloud privilege control fails when it assumes only people need activation workflows. Non-human identities need the same right-sizing, eligibility review, and revocation discipline as human roles, or the blast radius simply shifts.
Practical implication: Bring every non-human identity into the same privilege governance model as human admins.
Threat narrative
Attacker objective: Use persistent Azure permissions to reach secrets, escalate access, or alter cloud resources beyond the original task scope.
- Entry occurs when an identity authenticates with valid cloud credentials and inherits permissions that were granted for an earlier task.
- Escalation happens when that identity already has broad Azure rights, such as access to secrets, role assignments, or subscription-wide changes.
- Impact follows when the same standing privilege lets an attacker or misused automation move beyond the original need and expand blast radius.
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.
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
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 Azure governance failure, not sign-in weakness: the article is right to separate authentication from authorisation. Azure environments often keep permissions alive long after the task that justified them has ended, which means the real control gap is lifecycle drift in entitlements. The practitioner takeaway is to treat unused privilege as residual attack surface, regardless of whether the identity is human or non-human.
Just-in-time access exposes an identity blast radius problem: JIT is only effective when the underlying role is already right-sized. An eligible Owner role is still an Owner role, so activation control without scope reduction only defers risk rather than shrinking it. For cloud programmes, the meaningful control is not merely temporary activation, but temporary activation of a narrowly bounded permission set.
Non-human identities are where Azure privilege governance most often fails: service principals, managed identities, vendor accounts, automation, and AI agents rarely enter the same review path as people. That creates a governance blind spot because the identities most likely to hold durable permissions are the ones least likely to be recertified. Teams need to treat NHI entitlements as first-class citizens in the privilege model.
Permissions-on-demand is a better frame than session-only PAM for cloud: the article shows why jump boxes and VM access controls do not solve the cloud authorisation problem. The relevant control plane is the IAM layer, where role definitions and entitlement state determine what an identity can do after authentication succeeds. Practitioners should read Azure JIT as a permissions governance pattern, not a connectivity feature.
Ephemeral access debt: the article surfaces a useful concept for cloud programmes that still tolerate standing entitlements. Every permission that remains after work is complete creates an accumulated exposure debt, especially when multiple identity types inherit it. The disciplined response is to measure privilege persistence as a governance liability, not a convenience trade-off.
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.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
What this signals
Ephemeral access debt: cloud teams should treat every standing entitlement as residual exposure that accumulates across human and non-human identities. JIT helps only when the programme removes access state after the work ends, not when it simply makes activation slightly harder.
Azure access control is maturing from session protection to permission governance. That shift matters because service principals, managed identities, vendor access, and AI agents can hold more meaningful rights than human users, yet they are less likely to enter traditional review cycles.
For practitioners
- Right-size roles before enabling JIT Review whether the baseline Azure role is already broader than the actual task. An eligible assignment to a large built-in role still creates excessive blast radius when activated, so narrow the role first and only then make it eligible for time-bound access.
- Bring non-human identities into access reviews Inventory service principals, managed identities, automation accounts, vendor accounts, and AI agents alongside human users. Check which permissions are actively used, which are left standing, and which should move to on-demand activation or be removed outright.
- Use approval context to record why access exists Require a reason for activation and keep the approval trail attached to the specific task. That record supports audit, helps identify repeat access requests, and makes it easier to spot roles that should never have been standing in the first place.
- Match activation windows to the actual work Set the JIT window to the duration of the task, not to a default that feels administratively easy. Long windows recreate standing privilege with extra steps and weaken the main benefit of temporary authorisation.
- Review eligible assignments that are never activated Find roles that are eligible in PIM but never used and decide whether they should be removed or redesigned. Inactive eligibility usually signals stale governance rather than a real operational need.
Key takeaways
- Azure JIT is useful only when it shrinks standing privilege across the full identity estate, not just among named administrators.
- The main evidence in the article is that overprivileged cloud identities keep access alive after the task is done, which preserves blast radius.
- The practical response is to right-size roles, include non-human identities in reviews, and make activation temporary by design.
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, NIST CSF 2.0 and CSA Cloud Controls Matrix 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 centers on Azure identities carrying access beyond what the task requires. |
| NHI-01 — Improper Offboarding | The article describes permissions that remain after work ends or identities are no longer needed. | |
| NHI-07 — Long-Lived Secrets | Standing privilege persists as durable access state even when the original task is over. | |
| Recommendation — Remove excess Azure permissions and scope NHI entitlements to the minimum task need. Revoke stale Azure entitlements when the business need ends and eligibility no longer exists. Reduce long-lived Azure access by converting persistent privilege into time-bound activation. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The piece is about controlling the lifecycle and use of authenticators and access state. |
| Recommendation — Apply authenticator lifecycle controls to expire and revoke privileged access on schedule. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Azure JIT here is fundamentally about managing permissions and entitlements across identities. |
| Recommendation — Review entitlements regularly and restrict authorisations to approved, time-bound access. | ||
| MITRE ATT&CK | TA0004;TA0006;TA0008 — Privilege Escalation; Credential Access; Lateral Movement | The article’s risk model maps to escalation and expansion of access once standing privilege exists. |
| Recommendation — Map overprivileged Azure identities to escalation and lateral-movement tactics in your detections. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | The article is about cloud IAM governance across human and non-human identities. |
| Recommendation — Use cloud IAM controls to govern entitlement assignment, activation, and revocation across Azure. | ||
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.
- Eligible Role: An eligible role is a privileged entitlement that exists in advance but is not active until a user requests and receives activation. In cloud environments, eligibility only works well when the role catalogue stays aligned with current operational tasks and the activation process is fast enough for real engineering work.
- Permissions-first PAM: Permissions-first PAM is a cloud control approach that governs what an identity can do, not just how it connects to a system. It shifts focus from session brokering to entitlement scope, making it better suited to Azure, service principals, managed identities, and AI-driven workflows.
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 24, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org