How should teams implement just-in-time access for privileged operations?

Why This Matters for Security Teams

JIT access is the practical answer to a problem that standing privilege cannot solve: privileged operations need to happen fast, but they should not remain available after the task ends. For non-human identities, the risk is larger because service accounts, automation tokens, and API keys are often reused across pipelines and environments. NHIMG research shows that 97% of NHIs carry excessive privileges, which makes temporary elevation a governance issue, not just an access request workflow. See the Ultimate Guide to NHIs and the Ultimate Guide to NHIs — Key Challenges and Risks for the broader NHI risk model.

The control objective is simple: issue privilege only when a task, approver, and expiry can be verified, then revoke it automatically. That sounds straightforward, but teams often miss the surrounding controls that make JIT real. Without scoped approvals, good logging, and post-session review, JIT becomes a manual exception process that still leaves hidden standing access behind. OWASP’s OWASP Non-Human Identity Top 10 is useful here because it frames excessive privilege and secret misuse as recurring identity failures, not one-off incidents. In practice, many security teams encounter privilege creep only after an automation account has already been used outside its intended task scope.

How It Works in Practice

Teams should treat JIT as a full workflow, not a button that grants temporary admin rights. Start by defining the operation type that qualifies for elevation, the approving authority, the maximum duration, and the exact resource scope. For NHIs, the request should bind access to workload identity, task ownership, and a narrowly defined policy. That means the identity requesting privilege is proven cryptographically, the purpose is explicit, and the session expires automatically whether or not a human remembers to close it.

For implementation, current guidance suggests pairing PAM with policy-as-code so approval is evaluated at request time, not through static role assignment. A well-run process typically includes:

• request context: ticket, change record, incident ID, or automated job reference
• approval rules: role, risk tier, system criticality, and separation of duties
• credential issuance: short-lived token, certificate, or scoped session
• revocation: automatic expiry plus forced invalidation at session end
• audit trail: who approved, what was issued, what was used, and what was revoked

That model lines up with Zero Trust thinking in the OWASP Non-Human Identity Top 10 and with the identity lifecycle focus in the Guide to NHI Rotation Challenges. Use the same logic for secrets: if a job needs a token, issue an ephemeral one instead of extending the life of a long-lived credential. The operational goal is to make privilege measurable, reviewable, and removable. These controls tend to break down in high-frequency CI/CD environments because repeated approvals push teams back toward permanent entitlements and shared tokens.

Common Variations and Edge Cases

Tighter JIT controls often increase operational overhead, so organisations must balance speed against assurance. That tradeoff is real in emergency response, release pipelines, and agentic automation where delays can interrupt service recovery or production deployments. Current guidance suggests using different approval paths for different risk levels rather than forcing every privileged action through the same process.

One common variation is “break-glass” access for incidents. This should remain exceptional, heavily logged, and time-boxed, with after-action review mandatory. Another is delegated JIT for NHIs that operate continuously but need occasional elevation. In those cases, the safer pattern is a narrowly scoped workload identity with just-in-time secrets, not a broad standing role. The 52 NHI Breaches Analysis is a useful reminder that reused secrets and overbroad access repeatedly show up in real incidents. OWASP also notes that identity compromise often escalates when approvals and revocation are disconnected, so OWASP Non-Human Identity Top 10 remains a practical reference for control design.

There is no universal standard for every expiry window, but best practice is evolving toward the shortest duration that still permits the task. If the environment cannot enforce automatic revocation, the design is not true JIT yet. Manual cleanup after the fact is where temporary privilege quietly becomes standing access.

Related resources from NHI Mgmt Group

• How should security teams implement just-in-time privileged access in cloud environments?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• When do NHI access reviews create more value than a one-time cleanup?