Just-in-Time Access: Do You Really Need It?

Just-in-time (JIT) access grants privileged access only when someone needs it, for a set window, and removes it automatically afterward. Do you really need it? If people in your organization hold admin rights around the clock that they use for a few hours a month, yes. That standing access is the thing attackers are counting on.

I get this question a lot, usually from teams that already have a vault and are wondering whether JIT is a real control or another line item. Fair question. Here’s how I answer it.

A common version of this: The question usually comes right after the vault project is done. Credentials are rotated, sessions are recorded, and then someone points out that the same handful of admins can still check out domain admin whenever they like. That’s when JIT stops looking like a line item, because the vault controls how a credential is used, not whether anyone should be able to hold it at 3 a.m. on a Sunday.

What is just-in-time access?

The idea is simple: nobody holds privilege by default. When an engineer needs to restart a production database or change a firewall rule, they request access, it’s approved (by a person or by policy), they get it for a defined period, and then it goes away without anyone having to remember to remove it.

There are a few ways to implement that, and they’re not equivalent:

Approach	How it works	Trade-off
Elevate an existing account	The user’s own account gets admin rights or a privileged role for the window, then loses them	Simple and auditable per person, but the account still exists as a target between sessions
JIT group or role membership	The user is added to a privileged group (an AD group, a cloud role, a SaaS admin role) and removed when the window ends	Works with almost anything that honors groups; watch for cached tokens and sessions that outlive the membership
Ephemeral accounts	A privileged account is created for the session and deleted afterward	Leaves nothing standing to steal, but needs strong automation and solid logging to tie actions back to a person
Credential checkout	The user checks a privileged credential out of a vault, and it’s rotated on check-in	A vault-centric form of JIT; the account is permanent, but the password isn’t known for long

Most real programs use a mix. A cloud console might use JIT role assignment, Windows servers might use ephemeral local admin, and network gear might still run on vaulted credentials with checkout and rotation.

Just-in-time access vs. vaulting and standing access

Vaulting and JIT get lumped together, but they answer different questions.

A vault protects the credential. The password is long, rotated and never written on a sticky note, and sessions can be brokered and recorded. That’s essential, and it’s where most privileged access management programs start. But the privilege itself is still standing. The account is a domain admin on Tuesday at 3 a.m. whether anyone needs it or not.

JIT removes the privilege when it’s not in use. An attacker who compromises a user’s identity between sessions finds an account with nothing interesting attached to it.

The two are complementary, not competing. Vaulting without JIT leaves standing privilege behind a better lock. JIT without vaulting can leave you elevating accounts whose credentials are weak or shared. In mature programs, the vault holds what has to stay permanent and JIT handles everything else.

Where JIT access fits best

Some places get far more value from JIT than others.

• Cloud consoles and infrastructure. Cloud IAM roles are powerful, numerous and easy to over-grant. Time-bound role assignment is one of the most effective controls you can put in front of production cloud accounts.
• IT and infrastructure admins. Most admins don’t need domain or server admin rights all day. They need them for specific tasks. JIT shrinks the window without slowing the work much, if the request flow is fast.
• Third-party vendors. A vendor with a permanent VPN account and standing access is a gift to attackers. Vendor access should be requested, approved, time-boxed and recorded, every time.
• SaaS admin roles. Admin rights in your identity provider, collaboration suite or CRM are often overlooked and frequently standing.

Where it fits less well: tightly scripted automation, service accounts and some operational technology environments, where a delay in getting access can be a safety or uptime problem. Those need different controls, at least for now.

Just-in-time access tools

Most major PAM and identity vendors now offer JIT in some form. I’m not ranking them; the right one depends on where your privileged access actually lives.

• BeyondTrust Entitle focuses on JIT access to cloud, SaaS and infrastructure permissions through request and approval workflows, including from chat tools. (I hold BeyondTrust’s Entitle certification.)
• CyberArk offers JIT elevation and zero-standing-privilege access for cloud and on-premises targets alongside its vault. Here’s how it compares with BeyondTrust and Delinea.
• Delinea offers JIT elevation and time-bound access across its server and cloud products.
• Microsoft Entra Privileged Identity Management (PIM) makes users eligible for Entra and Azure roles rather than permanently assigned, with time-limited activation, approval, justification and MFA on activation. If you’re a Microsoft shop, start here for Entra and Azure roles.

For how the big three PAM platforms compare more broadly, see CyberArk vs. BeyondTrust vs. Delinea.

Prerequisites and pitfalls

JIT is not where a PAM program starts. A few things need to be in place first, and a few traps catch almost everyone.

Know where your standing privilege is. You can’t remove standing access you haven’t found. Discovery of privileged accounts, groups and cloud roles comes first.

Govern who’s eligible. JIT controls when someone has access. Something still has to decide whether they should be able to request it. That’s an identity governance job, and it’s why I like eligibility for privileged roles to flow from your IGA program rather than living as a separate list in the PAM tool.

Keep break-glass separate. If your JIT platform, identity provider or approval chain is down, you still need a way in. Maintain a small number of emergency accounts that are vaulted, monitored and tested, and that don’t depend on the systems they’re meant to recover.

Watch for approval fatigue. If every request needs a human approval, approvers start approving everything without reading, and you’ve rebuilt a rubber stamp. Use policy-based auto-approval for low-risk, well-understood requests (on-call engineer, their own systems, during their shift) and save human approval for the unusual ones.

Automate or it won’t last. If getting access takes 20 minutes, engineers will lobby for standing access, and they’ll usually win. JIT has to be faster than the workaround.

Where it tends to go wrong: Picture an on-call engineer paged at 2 a.m. who has to file a request, wait for an approver who is asleep, and then wait again for provisioning. After a few nights like that, the team asks for a standing exception for on-call staff, and it gets granted. The fix is to pre-approve the predictable cases by policy, so the human approvals that remain are rare enough to actually get read.

The short answer

You need just-in-time access if you have privileged accounts that hold full admin rights all day while doing nothing with them, and almost everyone does. Start where standing privilege is riskiest and easiest to remove: cloud admin roles and vendor access. Keep your vault for what has to stay permanent, keep break-glass outside the JIT path, and make the request flow fast enough that nobody wants to go around it. JIT is also the main step toward zero standing privileges, which is a bigger conversation for another post.

More PAM field notes live in the PAM topic hub.