Use a central access workflow that issues temporary credentials only after authentication and policy checks, then revokes them when the session ends or the time to live expires. That approach works for both people and machines because access is created on demand, scoped to the job, and removed before it can become permanent standing privilege.
How JIT Access Should Be Built for Both People and Machines
The design goal is not merely “temporary access,” but temporary access that is created only when the request is justified, bounded to the minimum useful scope, and tied to a short-lived session or token with a clear expiry. That means the same access workflow can serve both humans and machine identities if the control plane can issue, constrain, and later revoke access cleanly.
The practical distinction is in how the request is proven. Human access usually flows through interactive authentication, approval, and session controls, while machine access is often driven by workload context, attestation, or a signed request from an already trusted runtime. In both cases, the decision should be policy-based rather than manual, because manual exception handling is what tends to leave standing permissions behind.
Temporary access also needs to be treated as a complete lifecycle, not a one-time grant. If the credential, token, role assignment, or certificate outlives the task, then JIT has failed operationally even if the original request was time limited. For machine-heavy environments, that means the expiration of the access grant and the expiration of the credential itself must be aligned.
Useful reference points for the underlying mechanics are NHIMG’s Ultimate Guide to NHIs, the static vs dynamic secrets guidance, and the SPIFFE workload identity specification, which is a strong model for short-lived, workload-bound identity.
What Prevents Standing Permissions From Creeping Back In
The usual failure mode is not the initial grant, it is drift. Teams add a temporary role, token, API key, or certificate for convenience, then leave behind a broader entitlement, a reusable secret, or an indirect path that still authorizes the same action after the job is done. JIT only works when the default state is no access, not “access unless someone remembers to remove it.”
For human identities, the most common leak is excess role reuse or lingering group membership. For machine identities, it is long-lived secrets, wide-scoped service accounts, or fallback credentials that remain valid after the ephemeral path is issued. That is why JIT controls should be paired with inventory, ownership, and automated revocation, otherwise the temporary path becomes an extra path rather than the only path.
The best operating model is to issue the narrowest credential possible, set a TTL that matches the task window, and ensure the access method cannot silently extend itself. Where a system supports both ephemeral and persistent access methods, the persistent method should be removed or disabled for the sensitive operation, not left in place as a backup.
Helpful supporting material includes Guide to NHI Rotation Challenges, Machine-to-Machine Identity Maturity Model, and CIS Controls v8, which reinforces account management, access control, and auditability.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207), CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Temporary access depends on short-lived secrets and credential lifecycle control. |
| NHI-02 — Identity Lifecycle and Offboarding | JIT must remove access cleanly so temporary grants do not become standing privilege. | |
| NHI-05 — Least Privilege and Scoped Access | JIT access works by constraining permissions to the minimum task scope. | |
| Recommendation — Use short-lived credentials and revoke them automatically when the session ends. Automate deprovisioning to ensure access disappears at expiry or task completion. Scope each temporary grant to the minimum permissions needed for the job. | ||
| NIST Zero Trust (SP 800-207) | 3.2 — Policy Engine and Policy Decision Point | JIT requires policy-based authorization before access is issued. |
| 3.3 — Policy Enforcement Point | Access must be enforced at runtime and revoked when the session ends. | |
| Recommendation — Enforce policy decisions before issuing any temporary access. Route access through enforcement points that can terminate it immediately. | ||
| CIS Controls v8 | 6 — Access Control Management | JIT access is an access-control pattern that needs least privilege and removal of stale permissions. |
| 5 — Account Management | Temporary human and machine access must be provisioned and revoked through controlled account processes. | |
| Recommendation — Remove unused permissions and constrain access by business need. Automate account provisioning and revocation for all temporary access. | ||
| NIST CSF 2.0 | PR.AA-01 — Identities and Credentials Issued, Managed, Verified, Revoked, and Audited | JIT access depends on issuing and revoking credentials cleanly within a governed lifecycle. |
| PR.AA-04 — Access Permissions Managed | The model requires permissions to be scoped and removed so they do not persist as standing access. | |
| Recommendation — Track issuance and revocation for every temporary credential. Continuously review and remove permissions that outlive their task. | ||
Practitioner Guidance
What to verify: Confirm that the temporary grant is the only working path for the task, and that expiry removes both access and the underlying credential or session. If you can still complete the job with a leftover role membership, shared secret, or non-expiring token, the JIT design is incomplete.
Implementation sequence: Start with the policy decision, then issue the short-lived credential, then bind it to the specific resource and time window, then revoke on completion or expiry. For machine identities, make the default path ephemeral first, because retrofitting revocation onto long-lived secrets is usually where standing privilege survives.
Common mistake: Treating approval as the control instead of the expiry and revocation mechanics. Approval may justify access, but only automated teardown prevents the approved access from becoming standing access after the work finishes.
Practitioner takeaway: JIT is only real when the access path is both time limited and self-cleaning, with no hidden fallback that preserves privilege after the session ends.
Related resources from NHI Mgmt Group
- How should security teams implement just-in-time access without leaving standing privilege behind?
- How should security teams run access reviews for non-human identities?
- How should security teams govern non-human identities that have persistent access?
- How should security teams implement just-in-time access for Kubernetes production clusters without creating standing privilege risk?
