TL;DR: Just-in-time access can shorten exposure windows, but it still behaves like standing privilege because broad entitlements remain active for the granted session, leaving attackers time to exploit compromised accounts, according to SGNL. The real control gap is continuous context-aware authorisation, not timer-based elevation.
At a glance
What this is: This analysis argues that just-in-time access in cloud IAM still functions like standing privilege because the entitlement remains broad and active for the duration of the session.
Why it matters: IAM and PAM teams need to distinguish reduced exposure time from real-time privilege control, especially where cloud conditions, device posture, and attacker activity can change mid-session.
Context
Just-in-time access is a time-boxed privilege model, but it still depends on pre-authorised entitlements that remain active once granted. In cloud IAM, that means the governance problem is not only how long access lasts, but whether the access decision can adapt when the surrounding context changes.
The article’s core point is that timer-based elevation can make reports look cleaner without materially changing risk. For NHI, autonomous, and human identity programmes, the practical question is whether authorisation is still static at the moment it matters or whether it can follow real session conditions.
Key questions
Q: What breaks when just-in-time access is used without live context checks?
A: The control breaks when the system assumes the original approval remains valid for the whole session. Device posture, user activity, and business need can change after access is granted, but a timer alone does not notice. That leaves a broad, active privilege window that attackers can exploit before expiry.
Q: Why does just in time privileged access still create risk in cloud identity environments?
A: Just in time access reduces standing exposure, but it does not remove privilege misuse if the activation process is easy, predictable, or poorly monitored. If an attacker already has session access, they may simply activate the role. If teams give too many eligible roles, they also drift away from least privilege and increase the blast radius of compromise.
Q: How do security teams know if just-in-time access is actually working?
A: Look for short-lived sessions, automatic revocation, and complete request-to-access logs. If approvals are still creating durable permissions, or if teardown depends on manual cleanup, then the programme is only partially ephemeral. Effective JIT should leave little or no reusable privilege behind after the task ends.
Q: How should security teams implement JIT for privileged access?
A: Security teams should implement JIT at the permission layer, not only at the session layer. That means granting the exact entitlement needed for the task, limiting the duration, and removing the right from the target system automatically. A broker alone is not enough if static permissions remain behind it.
Technical breakdown
Why timer-based elevation still creates standing privilege
JIT access is usually implemented as a time-limited grant on top of a broader privilege model. The user requests access, the system approves it, and a session starts with the same entitlements that would otherwise have been permanently assigned. The only thing that changes is duration. That is why JIT can reduce exposure time without changing the underlying trust model. The privilege is still pre-authorised, still broad, and still usable until expiry, which means the control is temporal rather than contextual.
Practical implication: treat timer expiry as one input to access governance, not proof that standing privilege has been removed.
Why cloud context breaks static access windows
Cloud environments move faster than fixed authorization windows. A device can fall out of compliance, a login location can change, a task can end early, or an account can be compromised after the grant is issued. Static JIT policies do not recalculate access when those conditions shift. The session continues because the timer is still valid, even if the business justification and security posture are no longer valid. That makes the real failure not the grant itself, but the assumption that access conditions remain stable for the full window.
Practical implication: align privileged access decisions with live context signals rather than relying on the original grant state.
Why audit visibility lags behind real privilege use
JIT can obscure privilege activity because temporary access may never appear as standing entitlement in a normal review. That creates a blind spot between what entitlement reports show and what the user actually did during the session. A static audit view can therefore miss repeated elevation patterns, short-lived high-risk sessions, and access granted under weak context. In identity governance terms, this is a visibility problem as much as an authorization problem. The environment may look clean on paper while still allowing recurring privileged action in practice.
Practical implication: audit session-level use, not just persistent entitlements, if you want to understand the real access pattern.
Threat narrative
Attacker objective: The attacker wants to turn a temporary elevated session into enough time and scope to carry out privileged cloud activity before the access window closes.
- Entry begins when a cloud account or token is compromised and the attacker waits for a JIT request or session to open.
- Escalation occurs when broad time-boxed entitlements are granted without checking whether the user or device context has changed.
- Impact follows when the attacker uses the active session before the timer expires to perform privileged cloud actions.
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 our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
JIT access is not a replacement for standing privilege if the entitlement remains broad after grant. The timer changes duration, not the authority model. That means the underlying access pattern still behaves like pre-authorised privilege with a smaller window, which is why the control can reduce exposure without changing the security premise. Practitioners should stop treating time-boxing as elimination.
Cloud authorisation that assumes conditions stay stable for the life of a session is already outdated. Device posture, user behaviour, and business need can all shift mid-session, but static JIT models do not re-evaluate those signals. The result is a mismatch between operational pace and access control pace. Practitioners should treat live context as part of the access decision, not an afterthought.
Continuous Identity is the named concept that separates duration control from real privilege control. The article’s substance is that access should follow changing conditions rather than fixed windows. That framing matters because it shifts the question from how long access lasts to whether access is still justified right now. Practitioners should measure whether authorisation can change during the session.
Audit cleanliness can hide governance weakness when temporary grants are invisible in entitlement snapshots. A clean report does not mean a clean control if the environment still allows repeated elevation. The control gap is not only in issuance but also in evidence quality. Practitioners should assume their review process is incomplete if it cannot show session-level privilege use.
For cloud PAM, the decisive design question is whether access can be revoked on context drift, not merely when the clock runs out. If the answer is no, the organisation still has standing risk, just compressed into a shorter period. That distinction is critical for identity governance teams deciding how far JIT can actually take them.
What this signals
Continuous Identity replaces timer-based privilege with session-aware governance. The issue is not whether access expires eventually, but whether it can respond while the session is still live. That makes live context signals part of identity control rather than a separate monitoring layer.
Cloud IAM programmes that rely on JIT should test whether privilege can be withdrawn before a task completes, not just at the end of a preset window. If they cannot, the organisation is still depending on an access model that assumes conditions will stay stable.
Standing-access gap: the article names a real governance gap where temporary access still behaves like standing access because the session remains broad and pre-authorised. Practitioners should use that framing when evaluating whether their privileged access strategy is actually zero-standing privilege or only shorter standing privilege.
For practitioners
- Reassess JIT as a duration control Map every time-boxed privilege policy to the underlying entitlements it exposes, then decide whether the session is still effectively standing access with a timer attached.
- Add live context to privilege decisions Require device posture, user behaviour, and task justification to remain valid after grant, and revoke access when any of those signals drift.
- Review session-level activity, not just entitlements Correlate privileged actions inside temporary sessions with approval records so recurring elevation patterns are visible in audit and governance reviews.
- Define a revocation trigger for context drift Set explicit conditions for terminating elevated access when the business task ends, the login source changes, or the device falls out of policy.
Key takeaways
- Just-in-time access can reduce exposure time in cloud IAM, but it does not by itself remove the broad authority that comes with the granted session.
- The core governance weakness is static authorization, because cloud conditions can change faster than timer-based controls react.
- Teams that want real privilege reduction need session-aware revocation and context-driven decisions, not just shorter elevation windows.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Broad session entitlements create the overprivilege condition this article critiques. |
| NHI-07 — Long-Lived Secrets | Timer-based grants still extend usable privilege for a fixed duration, preserving exposure windows. | |
| Recommendation — Reduce granted scope so temporary access cannot behave like broad standing privilege. Shorten or revoke privileged sessions when the task ends rather than letting them run to expiry. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article centres on how credentials and elevation windows are managed over time. |
| Recommendation — Use authenticator management to bind privilege lifetimes to current need and revoke stale sessions. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The main issue is whether access permissions remain appropriate after grant. |
| Recommendation — Continuously validate entitlements so authorization changes when context changes. | ||
| NIST Zero Trust (SP 800-207) | continuous authorization — Continuous Authorization | The article argues that static windows fail and access must be re-evaluated in session. |
| Recommendation — Apply continuous authorization so access decisions track live conditions instead of timer expiry. | ||
Key terms
- Continuous Identity: A governance model that turns identity data into live access decisions. Instead of relying on static approvals and periodic reviews, continuous identity reevaluates whether access should still exist based on current context such as risk, device state, ticket status, or business need.
- 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.
- Exposure Window: The period in which a credential, session, or privilege grant can be exploited before it is revoked or expires. Shorter windows help, but they do not solve the deeper question of whether the access remains justified for the full time it is active.
- Context-Aware Authorization: Context-aware authorization evaluates signals such as device posture, time, resource sensitivity, and request type before allowing access. It moves IAM away from static permission checks and toward decisions that reflect current risk, which is essential in cloud-native environments with frequent identity changes.
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 12, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org