Just-in-Time Access Request

Expanded Definition

Just-in-Time Access Request is an access pattern in which privilege is granted only after a request is approved by policy and only for the time window needed to complete a specific task. In NHI security, the pattern is used to reduce standing privilege for service accounts, API-driven workflows, and operator sessions that interact with sensitive systems. It is closely related to Zero Standing Privilege, but the term focuses on the request and authorization event that activates access rather than the broader governance model.

Definitions vary across vendors on whether the request must be human approved, fully automated, or tied to a workflow system. The practical common ground is that the request should be auditable, time bounded, and scoped to a narrow resource set. This maps naturally to least privilege and session control guidance in the OWASP Non-Human Identity Top 10 and the control intent in NIST SP 800-53 Rev 5 Security and Privacy Controls. The most common misapplication is treating a one-time approval as true just-in-time access when the credential or token remains reusable after the task is complete.

Examples and Use Cases

Implementing Just-in-Time Access Request rigorously often introduces workflow latency and operational friction, requiring organisations to weigh faster recovery and lower exposure against a slightly slower path to privileged work.

• A contractor receives temporary access to a production support console for a maintenance window, then the grant expires automatically when the job closes.
• An on-call engineer requests a short-lived elevated role to rotate secrets during an incident, with the access broker logging the ticket ID and expiry time.
• A deployment pipeline requests access to a repository secret only during a release step, rather than keeping a long-lived token in the runner environment.
• A cloud operations team uses a just-in-time workflow to unlock database administration rights for a single change request, then revokes the session at completion.

These patterns are easier to justify when organisations understand how often NHIs are overexposed; NHI Mgmt Group notes that Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges. For a real-world failure mode, Microsoft SAS Key Breach illustrates why access that should have been temporary must not persist beyond the task it was meant to support.

Why It Matters in NHI Security

Just-in-Time Access Request matters because NHIs do not forget to revoke themselves. If temporary privilege is not enforced correctly, a short operational need can become a standing foothold for lateral movement, secret abuse, or unintended data access. This is especially important where machine identities interact with production systems, CI/CD tooling, or third-party services, because the blast radius of a missed revocation is often larger than the original task.

The governance value is clear in the NHI risk data published by NHI Mgmt Group: Ultimate Guide to NHIs reports that only 20% of organisations have formal processes for offboarding and revoking API keys. Just-in-time controls help close that gap by making access expiration part of the process rather than an afterthought. They also complement the broader control intent in NIST SP 800-53 Rev 5 Security and Privacy Controls, where access enforcement and auditability are core expectations. Organisations typically encounter the operational necessity of just-in-time access only after a stale credential or forgotten privilege has already been abused, at which point the pattern becomes unavoidable to address.

Related resources from NHI Mgmt Group

• What is Just-in-Time (JIT) access and why is it important for NHI security?
• When do NHI access reviews create more value than a one-time cleanup?
• When does just-in-time access reduce risk for agentic AI, and when does it fall short?
• How should security teams govern just-in-time access for non-human identities?