What is just-in-time (JIT) access?

Just-in-time access is the practice of granting cloud credentials only when a specific need exists, scoped to that task, and expiring them automatically once the window closes. No one holds standing access to sensitive systems. Access is created on request and disappears without manual intervention.

What is standing access and why is it a problem?

Standing access means credentials exist continuously, whether or not anyone is actively using them. An engineer gets added to an admin group on day one. The credentials sit there for months. They are used occasionally but present always.

The problem is not that the engineer is untrustworthy. The problem is that static, long-lived credentials are exposed to a long list of risks: key theft, phishing, session hijacking, accidental exposure in logs, and the simple fact that people make mistakes when they have more power than they need for a given moment. Standing access makes every one of those risks permanent. JIT makes them temporary by design.

How does a JIT flow work?

A typical JIT flow has five steps.

First, an engineer requests access for a specific task — “I need to restart the payment processor in the production account.” Second, they provide a reason, which becomes part of the audit record. Third, the request is evaluated: low-risk requests can auto-approve instantly; higher-risk ones route to a teammate for a quick approval. Fourth, short-lived credentials are issued — typically through AWS STS, with a session duration matched to the task. Fifth, the credentials expire automatically. There is nothing to revoke and no ticket to close.

The whole flow, for a low-risk auto-approved request, can take under ten seconds. For something requiring a peer review, it adds a minute or two. That is the full cost.

How is JIT different from a VPN?

A VPN controls network-layer access — which hosts and ports you can reach. JIT controls what cloud API calls you can make. They operate at different layers and address different threats.

You can have both. A VPN ensures you are on a trusted network before the JIT request is even submitted. JIT ensures that once you are on the network, you still cannot take sensitive cloud actions without an explicit grant. You can also have one without the other. Many cloud-native teams operate without a traditional VPN and rely on identity and JIT controls entirely.

Does a small team actually need JIT access?

Small teams are often where JIT matters most, not least.

When a team is small, the default move is to give everyone admin access because it is easier than managing fine-grained roles. That works until it does not: one leaked API key, one compromised laptop, one accidental terraform destroy run against the wrong workspace, and the blast radius is total. Small teams typically have fewer controls elsewhere — less security monitoring, less formal change management — so the access layer carries more weight.

JIT does not require a dedicated identity platform or months of setup to deliver value at small scale. The core behavior is simple: nobody holds production access unless they asked for it in the last hour.

Is JIT access just enterprise PAM?

No, and this confusion causes teams to dismiss it as out of scope.

Traditional Privileged Access Management tools were designed for large organizations with dedicated identity teams, complex approval hierarchies, and months of integration work. They can implement JIT, but JIT itself is not a PAM concept — it is an access pattern. The underlying mechanism, requesting short-lived credentials scoped to a task and letting them expire, can be implemented simply and works at any team size.

Treating JIT as “enterprise only” leads teams to skip it until they are large enough to feel the pain, by which point they have years of standing access to unwind.

How does JIT differ from break-glass access?

JIT is the normal workflow. Break-glass is the emergency exception.

In a JIT model, engineers request access regularly for routine tasks — debugging, deploying, reviewing logs. The flow is fast enough to be part of daily work. Break-glass access is a separate mechanism for situations where normal approval is not possible: a production outage at 3am, an on-call engineer who needs elevated access immediately with no one available to approve.

Break-glass grants broader access, typically with no pre-approval, but with heavy logging and mandatory post-hoc review. Using it should be rare and always flagged. JIT is what you use the rest of the time.

Korvalis implements JIT as a default access pattern, with session scoping, audit logging, and automatic expiry built in, so teams do not need to choose between speed and control.