Just-in-time access only removes standing privilege in one model

At a glance

What this is: This is an analysis of three just-in-time access patterns and the finding that only direct permission assignment truly eliminates standing privilege.

Why it matters: IAM and PAM teams need to distinguish access that is merely time-boxed from access that is actually removed, because the wrong model leaves privilege creep, shared credential risk, and audit ambiguity in place.

👉 Read P0 Security's analysis of the three JIT models and standing access

Context

Just-in-time access is often treated as a single control, but in practice it can be implemented in different ways with very different governance outcomes. The key question is whether access is truly removed at the permission layer or only wrapped in a timer and workflow.

For identity programmes, that distinction matters because standing roles, shared credentials, and delayed revocation create different risk profiles. In mature IAM and PAM design, the control objective is not simply shorter access windows, but the elimination of persistent privilege where the use case allows it.

The article frames JIT as an architectural choice, not just an operational convenience, and that is the right lens for practitioners evaluating legacy privileged access patterns versus more granular permission assignment.

Key questions

Q: What breaks when privileged access is not governed with least privilege and JIT?

A: What breaks is containment. If a privileged account remains broadly usable all the time, a single compromise can become administrative access with little resistance. Least privilege and just-in-time access reduce the blast radius by limiting what the account can do and for how long, especially in cloud and hybrid estates.

Q: When does just-in-time access reduce more risk than it adds?

A: Just-in-time access reduces more risk when the organisation can reliably automate approval, scope the privilege to a task, and revoke it immediately after use. It adds risk when teams keep broad base roles, weak review processes, or manual workflows that delay revocation. JIT is most effective as part of a broader zero-standing-privilege model.

Q: How do security teams know whether JIT access is actually reducing risk?

A: Look for shorter credential lifetime, fewer always-on permissions, and lower exposure of credentials in code, pipelines, and runtime environments. If the same identities remain broadly reachable or access still persists between tasks, JIT is only changing the workflow, not the risk model.

Q: How should teams choose between checkout, timed membership, and permission-level JIT?

A: Use checkout only for legacy systems that cannot be reworked quickly, timed membership for short-lived escalation, and permission-level assignment for workflows where least standing privilege is the goal. The decision should follow the system’s constraints and the risk of persistent access, not the convenience of the process.

Technical breakdown

Credential check-out keeps shared secrets in play

Credential check-in/check-out is the oldest JIT pattern: a user borrows a shared privileged credential from a vault, uses it for a window, and returns it later. The access window is shorter, but the underlying secret still exists and the privileged role still has its full permissions all the time. That means attribution becomes weak, enforcement depends on users following the process, and compromise of the shared credential still exposes the full standing entitlement behind it. The model reduces friction only a little and does not remove the core risk.

Practical implication: treat checkout-based JIT as a legacy containment pattern, not as true standing-access removal.

Timed group membership shifts privilege, not entitlement

Timed group membership adds a user to a privileged group for a short period and then removes them automatically. This is better than shared checkout because it removes the secret-sharing problem and works well for episodic escalation, such as incident response. But the permission model remains role-based, so the longstanding privileged role still exists and the group structure still determines how much access is granted. In other words, the timer applies to membership, not to privilege design. The control is useful, but it still leaves a durable authorization structure behind.

Practical implication: use timed membership for bounded escalation, but do not confuse it with elimination of persistent privilege.

Permission-level JIT is the only model that removes standing access

Permission assignment changes the unit of control from roles to task-scoped permissions. A user receives only the permissions needed for a specific job, and those permissions are detached when the task ends. That is the only approach in the article that actually removes longstanding access and overpermissioning rather than merely time-boxing them. It also aligns with how agentic identity solutions are being designed, because agents should not inherit broad standing privileges when they can be granted task-specific permissions and revoked after execution.

Practical implication: reserve permission-level JIT for the highest-value workflows where reducing persistent privilege is the actual objective.

NHI Mgmt Group analysis

Standing privilege is not removed until the entitlement itself disappears. Timed workflows can make access feel controlled while leaving the underlying authorization structure intact. That is a governance distinction, not a cosmetic one, because auditors and attackers care about what remains possible between sessions. Practitioners should treat permission-level removal as the control boundary, not the timer.

Credential check-out creates the illusion of JIT without changing the exposure model. Shared secrets still concentrate risk, and the same account can be touched by multiple users over time. That breaks attribution and preserves the attack value of the credential if it is ever compromised. The relevant governance question is whether the organisation has simply wrapped an old privileged account in a process.

Timed group membership reduces friction for escalation but leaves privilege architecture standing. This model works when a team needs short-lived elevation for a known role, but it does not solve overbroad role design. The role remains available for future assignment, which means the long-term control problem has only moved one layer deeper. Teams should recognise that this is an operational convenience, not a full privilege-removal strategy.

Task-scoped permission assignment is the closest fit to true zero standing privilege. It forces teams to define what access is needed for the task itself and to revoke it when the task ends. That discipline is harder to implement, but it is the only pattern in the article that meaningfully reduces the standing-access attack surface. For IAM and PAM programmes, that is where JIT becomes a governance model rather than a workflow tweak.

What this signals

Standing privilege only disappears when access is granted at the permission level. That distinction is now central to IAM and PAM design because many organisations have called timer-based workflows JIT while leaving the actual entitlement structure untouched. Teams should expect more scrutiny of whether their access model is truly removing privilege or simply rebranding it.

Permission-level JIT creates a new governance bar for non-human identities as well as people. If an organisation is using the same privileged patterns for automation or AI-assisted workflows, it risks recreating durable access under a different actor type. The programme question is whether the identity can be scoped to a task and then cleanly revoked.

JIT is becoming an architecture decision, not a feature decision. Security teams should be prepared to justify why a given system still needs shared credentials or always-on roles, especially where sensitive administrative access is involved. The more mature the programme, the more it will separate legacy containment from true privilege elimination.

For practitioners

• Audit which JIT model you are actually running Map each privileged workflow to credential checkout, timed membership, or direct permission assignment, then document whether standing roles or shared credentials still persist underneath the process.
• Separate escalation use cases from daily access Reserve timed group membership for episodic elevation such as incident response, and stop using it as the default pattern for everyday engineering access.
• Define task-scoped permission sets Identify the smallest permissions required for each repeatable task and attach them directly to the identity only for the duration of that task.
• Retire shared privileged accounts where possible Replace vault-based check-out patterns with individually attributable access paths so the control outcome is revocation, not just temporary borrowing.
• Align agent access with the same JIT standard Use the same permission-level logic for AI agents and other non-human identities so long-lived privileges are not recreated under a different actor type.

Key takeaways

• Just-in-time access is not a single control model, and the implementation choice determines whether standing privilege remains in place.
• Timer-based approaches can improve workflow and reduce some exposure, but they do not fully solve overpermissioning or shared credential risk.
• Direct permission assignment is the only pattern in the article that actually removes longstanding access instead of wrapping it in time limits.

Key terms

• 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.
• 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.
• Credential Check-Out Process: A credential check-out process is a controlled way to grant temporary access to privileged or administrative credentials. It typically requires justification, approval, and time-bound expiration so access does not persist longer than needed. This reduces standing privilege and helps limit damage if a user account is compromised.
• Task-scoped permission assignment: A JIT pattern where specific permissions are attached directly for a defined task and then removed when the task ends. It is the closest of the common JIT models to true privilege minimisation because it removes the need for a permanent privileged role.

What's in the full article

P0 Security's full blog post covers the implementation tradeoffs this analysis deliberately leaves at a higher level:

• Detailed comparison of credential check-out, timed group membership, and direct permission assignment
• Practical examples of where each JIT pattern fits legacy systems, escalation workflows, and day-to-day engineering access
• Discussion of why shared credentials and role persistence undermine the promise of standing-access removal
• The article's maturity framing for teams deciding which JIT model to standardise on first

👉 P0 Security's full post explains the three JIT patterns and the tradeoffs behind each one

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.