How should organisations decide which JIT model to use?

Use credential checkout only for legacy systems that cannot be redesigned, timed group membership for short escalation workflows, and direct permission assignment for day-to-day sensitive access. If the goal is truly to remove standing privilege, direct permission assignment is the model that gets closest to that outcome.

Why This Matters for Security Teams

Choosing a JIT model is not a preference exercise. It determines whether access is temporary in practice or merely “reviewed later” on paper. The wrong model can leave standing privilege in place, create brittle approval paths, or block urgent work and push teams toward shadow access. NHI Mgmt Group notes that 97% of NHIs carry excessive privileges, which makes the model choice a control decision, not an administrative detail.

Security teams also need to account for how access is actually consumed. Legacy systems often only support checkout-style workflows, while modern platforms can enforce narrower, task-based permissions more cleanly. That distinction matters because JIT should reduce blast radius, not just add another ticketing step. NIST’s NIST Cybersecurity Framework 2.0 frames this as an access governance and risk treatment problem, not a tool selection problem. In practice, many security teams discover the mismatch only after a privileged workflow has already been used as the easiest path around control friction.

How It Works in Practice

Most organisations should choose the JIT model based on the access pattern, system capability, and revocation requirement. The three common patterns solve different problems:

• Credential checkout fits legacy platforms that cannot accept fine-grained policy changes. It is useful when a user or operator must borrow a credential for a bounded task, but it is the weakest option for long-term control because the secret itself still exists and must be protected.
• Timed group membership works well for short escalation workflows where the target system already uses RBAC. The user enters a privileged group for a defined window, then exits automatically when the window closes.
• Direct permission assignment is the closest model to zero standing privilege for day-to-day sensitive access. It avoids over-broad group inheritance and lets teams bind access to a narrower business purpose.

The practical test is simple: if the system can evaluate access at runtime and revoke it automatically, direct permission assignment is usually the cleanest choice. If the system only understands group membership, timed membership is the compromise. If the platform is too old to support either, checkout becomes a containment pattern rather than a true least-privilege design. Guidance on this distinction aligns with NIST governance expectations and with NHI risk lessons from the Ultimate Guide to Non-Human Identities.

For a concrete example of why the distinction matters, NHI Mgmt Group has documented how exposed tokens and hard-coded credentials are repeatedly abused in enterprise environments, including the JetBrains GitHub plugin token exposure and Hard-Coded Secrets in VSCode Extensions research.

These controls tend to break down when the target environment mixes modern IAM with brittle legacy privilege pathways, because teams then rely on the weakest supported mechanism for the entire access flow.

Common Variations and Edge Cases

Tighter JIT control often increases operational overhead, so organisations have to balance reduction in standing privilege against speed, user friction, and system compatibility. That tradeoff is real, especially in environments with inherited admin models or third-party operations.

Current guidance suggests a few practical exceptions. Checkout may be acceptable for vendor-maintained systems or emergency break-glass access where the application cannot support direct assignment. Timed group membership is usually the best compromise for helpdesk, SRE, or operations escalation when approvals must remain simple and auditable. Direct permission assignment is best when access should be narrow, attributable, and easy to revoke without waiting for group propagation.

There is no universal standard for exactly how short “just in time” should be. Best practice is evolving toward task duration and risk-based TTLs rather than a fixed number of minutes or hours. Teams should also avoid using timed access as a substitute for offboarding, because expired elevation does not fix poor identity lifecycle controls. NHI Mgmt Group’s broader findings on exposed secrets and misconfigured controls in enterprise workflows reinforce that JIT works best when paired with rotation, logging, and removal of standing paths to privilege.

In environments with highly automated CI/CD, multi-account cloud estates, or delegated platform engineering, direct permission assignment can become the preferred default because group inheritance is too coarse and checkout is too slow for repeatable operations.

Related resources from NHI Mgmt Group

• How should security teams decide whether JIT access is safe for non-human identities?
• How can organisations decide whether a computer-use model belongs in production IAM?
• When should organisations prioritise Zero Standing Privilege for non-human identities?
• What is the difference between JIT access and Zero Trust for NHIs?