JIT access is an architectural outcome, not a feature checkbox

At a glance

What this is: This article argues that just-in-time access is an architectural outcome, not a feature, and that most implementations still preserve standing privilege.

Why it matters: It matters because IAM, PAM, and NHI programmes need controls that remove dormant privilege at runtime, not just shorten the window in which existing access can be used.

👉 Read Britive's analysis of why JIT access must be an architectural choice

Context

Just-in-time access is meant to ensure privileged access exists only when a task requires it, but many implementations still leave credentials, roles, or approval paths in place. That is a governance problem as much as a technical one, because the access model still presumes standing privilege and later review rather than runtime creation and destruction.

For identity teams, the issue spans human admin access, service accounts, and AI-driven workflows that request privileges continuously. When environments are cloud-native and machine identities are multiplying, access models built around static entitlements and manual approvals stop matching how work is actually executed.

The key question is not whether access expires eventually. It is whether the permission ever exists outside the task that needs it. For teams using the NHI Lifecycle Management Guide, the distinction is central to provisioning, rotation, and offboarding decisions.

Key questions

Q: How should security teams tell true JIT access from time-limited access?

A: True JIT creates privilege at the moment of need and destroys it when the task ends. Time-limited access often only shortens the use window for permissions that already exist. If a role, token, or password remains valid when no work is happening, the model is still carrying standing privilege.

Q: Why do vaulted credentials still create risk in privileged access programs?

A: Vaults improve secret custody, but they do not eliminate the permission itself. If the identity can still authenticate to a target system outside the task, the attack surface still exists. The security question is not where the credential is stored, but whether privilege survives between executions.

Q: Should organisations prioritize zero standing privilege for service accounts?

A: Yes, because service accounts often carry the longest-lived and least reviewed access in the environment. Zero standing privilege reduces the chance that a dormant credential becomes a standing path into production systems. The practical test is whether access can be issued, limited, and revoked automatically without breaking operations.

Q: When does approval-based access still leave too much privilege in place?

A: Approval workflows are insufficient when they only gate access checkout and do not remove the underlying entitlement from the target system. If the same permission can be reused later without a fresh runtime decision, the control reduces friction but not standing access. That is a governance gap, not true JIT.

Technical breakdown

What standing privilege really means in JIT access

Standing privilege exists when an identity has permission before the task begins, even if the credential is hidden behind a vault or a workflow. In that model, the access may be delayed, time-limited, or approval-gated, but it still exists on the target system or in the control plane. True JIT changes the lifecycle: access is created only at execution time, evaluated against policy in real time, and destroyed when the task ends. That is what separates ephemeral authorisation from access checkout with a timer attached.

Practical implication: map every privileged path to determine whether the permission is minted at runtime or merely concealed until use.

Why vaulted credentials do not equal zero standing privilege

A vault can improve custody of secrets, but vaulting alone does not remove privilege from the environment. If a password, token, or role still exists before and after the task, the attack surface remains. Compromise, replay, and misconfiguration still have something to target when nothing legitimate is happening. In other words, the credential's location changes, but the lifecycle does not. That is why vault-based access often reduces visibility while preserving the same underlying authorisation model.

Practical implication: treat vaulting as a storage control, not as proof that JIT or ZSP has been achieved.

How runtime authorisation changes the control model for NHIs and AI systems

Cloud automation, service accounts, and AI-driven processes do not fit neatly into human-style approval windows. They request access repeatedly, execute quickly, and often operate continuously across systems. A runtime authorisation model evaluates the requesting identity, resource, environment, and risk at the moment of action, then removes the permission once the task is complete. That mechanism matters because it aligns access creation with actual execution instead of with a pre-approved entitlement that lingers beyond necessity.

Practical implication: design privileged access so non-human identities receive task-scoped permissions that disappear after execution, not after review.

NHI Mgmt Group analysis

JIT is not a feature category, it is an authorisation lifecycle decision. The article is right to separate time limits from true privilege removal. A timer on existing access still leaves the standing permission model intact, which means the programme has reduced duration without changing exposure. Practitioners should treat any JIT implementation that preserves dormant permission as partial control, not ZSP.

Vaulted access preserves the same trust assumption that attackers exploit. The permission may be hidden, but the environment still contains an authorisable object before and after work is done. That means the control model still assumes access can exist safely when unused, which is exactly the premise JIT was meant to eliminate. The implication is that storage controls and lifecycle controls are not interchangeable.

Runtime authorisation becomes the decisive control plane as NHIs outnumber people. Once service accounts, automation, and AI systems are part of the access model, human-oriented approval windows stop scaling. NHI governance works only when permission creation, use, and destruction are bound to the task itself. Practitioners should stop judging JIT by workflow friction and start judging it by whether any standing privilege survives between executions.

Zero standing privilege is only real when permission never outlives execution. The distinction matters because many programmes claim progress while still retaining static entitlements behind a different interface. That preserves the attack surface, complicates offboarding, and weakens audit claims about who or what could act at a given moment. Security teams should reframe success around eliminable privilege, not just shortened access windows.

From our research:

• From our research: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• From our research: 59.8% of organisations see value in a solution that simplifies non-human access management and introduces dynamic ephemeral credentials, according to The 2024 Non-Human Identity Security Report.
• For lifecycle governance, see NHI Lifecycle Management Guide for provisioning, rotation, and offboarding patterns that align access with task completion.

What this signals

Ephemeral authorisation will become the differentiator between real privilege reduction and cosmetic JIT. As environments expand across cloud, SaaS, and automation layers, programmes that only hide credentials will keep inheriting the same risk. The next maturity step is not more checkout workflow, it is tighter runtime binding between identity, policy, and task.

With 59.8% of organisations already seeing value in dynamic ephemeral credentials, the market is signalling that static access checkout is no longer enough. Teams should expect tighter scrutiny of any JIT claim that cannot show actual permission destruction.

A useful operational concept here is lifecycle residue: any privilege that still exists after the task has finished. Once that residue is measured, it becomes easier to compare vault-based access, approval-based access, and true runtime authorisation in one control framework.

For practitioners

• Audit whether permissions ever exist outside the task Trace privileged pathways from request to destruction and check whether any credential, role, or entitlement remains present before the work starts or after it ends.
• Separate storage controls from lifecycle controls Document which access paths are merely vaulted and which are actually minted and destroyed at runtime, then remove any assumption that concealed credentials equal zero standing privilege.
• Apply the same access lifecycle to humans, NHIs, and AI systems Use one governance standard for admin users, service accounts, and agent-driven workflows so exceptions do not reintroduce persistent privilege under a different label.
• Measure success by the absence of dormant privilege Set programme metrics around how much privileged access remains between tasks, how quickly it is removed, and how often access can be replayed without a new runtime decision.

Key takeaways

• JIT only changes risk when it removes privilege at execution time, not when it simply shortens the window for existing access.
• Vaults, roles, and approvals can all coexist with standing privilege, so governance must measure whether permissions survive between tasks.
• For NHI and automation-heavy environments, runtime authorisation is the control that makes zero standing privilege real rather than aspirational.

Key terms

• JIT — Just-in-Time Access: A security approach that grants access permissions only for the duration needed to complete a specific task, then automatically revokes them. JIT access eliminates standing privileges for NHIs, dramatically reducing attack surface.
• Zero Standing Privilege: A control model in which an identity does not keep persistent access unless it is actively needed. For NHIs, this means credentials and permissions are issued for a narrow task and then removed. It reduces the time window and reuse value of stolen access.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• Lifecycle Residue: Any permission or credential that still exists after the work it was meant to support has finished. It is a useful governance concept for JIT and NHI programmes because it reveals when a control shortens access but fails to remove the underlying privilege.

What's in the full article

Britive's full blog post covers the operational detail this post intentionally leaves for the source:

• The step-by-step distinction between time-limited roles, vaulted access, and runtime-minted permissions
• The vendor's explanation of how target-system permissions are created and destroyed without a vault
• The evaluation questions Britive suggests for checking whether a JIT model really removes standing privilege
• The article's discussion of how humans, service accounts, and AI agents fit into the same access lifecycle

👉 Britive's full blog post explains the runtime access model, ZSP distinction, and NHI implications in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.