Why does just-in-time access still fail in practice?

Why This Matters for Security Teams

Just-in-time access is meant to shrink privilege windows, but in real environments it often inherits the same friction and drift that made standing access risky in the first place. If approvals are slow, queues are manual, or deprovisioning depends on human follow-up, the “temporary” grant lasts long enough to become routine. That is especially dangerous for secrets-bearing workloads and NHI flows, where access often unlocks APIs, deployment paths, or sensitive data rather than a single app screen.

The problem is not the concept. The problem is operational fit. The OWASP Non-Human Identity Top 10 treats weak lifecycle control and overexposed credentials as recurring failure modes, and NHIMG research on The State of Secrets in AppSec shows how long remediation and fragmented control erode confidence even when teams believe they are managing secrets well. The same pattern appears in JIT programs: the control exists, but the process around it is slower than the risk it is meant to contain. In practice, many security teams discover JIT failure only after privilege has already been used outside the intended task boundary, rather than through deliberate access review.

How It Works in Practice

Effective JIT is not just “request, approve, revoke.” It is a tightly bounded access workflow with an explicit purpose, a short TTL, and automated removal that does not depend on a ticket being closed on time. For human users, that often means privileged elevation is tied to a named change, a narrow scope, and session monitoring. For NHIs and agents, the model is stricter: the grant should be task-specific, ephemeral, and ideally issued against workload identity rather than a reusable shared secret.

Current guidance suggests pairing JIT with identity primitives that prove what the workload is, not just what token it holds. That usually means workload identity via OIDC, SPIFFE/SPIRE, or a similar cryptographic assertion, plus policy evaluation at request time. The access decision should consider context such as environment, purpose, risk level, and whether the requested action matches the approved task. This is why JIT works better when it is backed by Ultimate Guide to NHIs style lifecycle discipline and enforced with rules that can revoke or deny access automatically.

• Issue the minimum privilege needed for one task, not a reusable admin bundle.
• Set a short TTL and revoke on completion, timeout, or context change.
• Bind the grant to workload identity, not a shared account or copied token.
• Log the reason, approver, runtime context, and revocation event for auditability.
• Use policy-as-code so the approval criteria and runtime checks stay consistent.

Where implementation teams get into trouble is when JIT is layered on top of legacy credential stores, shared service accounts, or manual deprovisioning queues. Those controls tend to break down when access is granted for long-running pipelines, cross-team break-glass scenarios, or agentic workflows that can chain tools faster than humans can revoke them because the revocation path is slower than the privilege path.

Common Variations and Edge Cases

Tighter JIT usually increases operational overhead, so organisations have to balance speed against control. That tradeoff becomes visible in emergency access, production support, and machine-to-machine integrations where a request cannot wait for multiple approvers. Best practice is evolving here, and there is no universal standard for every environment.

One common edge case is “shared temporary access,” where teams create a single elevated account for a shift, incident, or project. That may reduce ticket volume, but it reintroduces ambiguity about attribution and revocation. Another is access for autonomous systems: agents may need repeated short-lived grants, but if the workflow assumes a human will click approve every time, the process becomes a bottleneck rather than a control. The more reliable pattern is policy-driven issuance with deterministic expiry and automated revalidation, as discussed in Guide to NHI Rotation Challenges.

JIT also fails when revocation depends on downstream systems that do not honor TTL consistently, or when cached sessions, API keys, and long-lived refresh tokens outlast the intended privilege window. In those cases, the visible grant ends, but the effective access remains. Organisations should treat that as a design defect, not an exception to accept.

Related resources from NHI Mgmt Group

• When do NHI access reviews create more value than a one-time cleanup?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• What is the difference between reviewing human access and reviewing NHIs?