“Just in Time (JIT) access” is a simple concept but can be architected in multiple ways with significant tradeoffs.
In this blog, we’ll break down the three major ways of achieving JIT, only one of which actually removes longstanding access altogether.
These three types are:
- credential check-in/checkout
- timed group membership
- JIT permission assignment
All three achieve some version of JIT, but only the latter removes the need for longstanding admin credentials altogether.
In assessing these three approaches, the goals of JIT should be to:
- Reduce the number of users with unused sensitive permissions
- Reduce the risk of a compromised credential
- Improve user experience for complicated login flows
Most approaches do something to reduce the number of unused permissions, but can lead to a false sense of security, as longstanding permissions switch to a role rather than a user account.
Below are the three patterns of JIT I see, in rough order of maturity:
1. Credential check-in/checkout
(Illustration: focus is on the provider owning the check-in/check-out process – a manual effort to check-out the key and then check it back in.)
Users of older Privileged Access Management (PAM) systems might be surprised to learn they’ve been doing JIT all along! In this model, shared user accounts like “devops” or “admin” sit in a vault, and users check out an access key for a window of time before checking it back in.
The appeal of this approach is simplicity; you can bolt this onto basically any environment without rearchitecting your IAM. The downside is that you’re transparently using shared credentials with extra steps. The roles still exist with all their permissions all the time, attribution gets fuzzy the moment two people touch the same role, and the whole thing depends on humans actually following the manual flows.
Tying back to our assessment, we’ve slightly reduced the number of users with unused permissions by making them request access, but we’ve made the user experience more complicated while doing nothing to change the risk of a compromised credential. Typically companies will monitor their more sensitive accounts with manual alerting via their SIEM.
Ideal use cases: Tracking manual access to legacy systems
Worst use case: Controlling developer access to complex systems
Pros: Simple to implement, Straightforward to monitor
Cons: Doesn’t remove longstanding access, doesn’t fix over-permissioning, increased user complexity, can introduce shared credential risk if not properly monitored or enforced.
2. Timed Group Membership
(Illustration: roles are always sitting there and attached to users, but users are just added and then removed to the group that has access to the role.)
Most approaches to JIT temporarily add the user to a group for privilege escalation workflows, such as the reliability engineer getting added to the devops group for four hours upon an incident getting triggered. The group maps to a longstanding “devops-role,” and membership expires automatically.
This is genuinely better than the checkout process because there are no shared secrets, and the workflow is simple enough that engineers will actually use it. The catch is that permissions are only as limited as your group structure. The model only works if your groups are carefully crafted and maintained, something no organization feels great about. You’ve also still got the longstanding role sitting there fully permissioned, waiting for someone to be assigned to it, so longstanding permissions are only one layer deeper.
Ideal use cases: Privilege escalation for incident response
Worst use case: Day-to-day access
Pros: Can be used to restrict longstanding access to high risk groups, Straightforward permission escalation workflows
Cons: Doesn’t actually reduce permissions or longstanding roles, Can create user experience friction if used for day-to-day access
3. JIT Permission Assignment
(Illustration: the shift to permissions rather than roles, where the longstanding roles have disappeared completely.)
When someone pictures JIT, this is typically what they’re thinking: a user requests specific permissions, they get attached directly to the user for the duration of the task, and then removed when they’re needed. This means that there are no standing roles or pre-built groups necessary.
This is the only model that actually eliminates longstanding access and overpermissioning rather than time-boxing it. When the engineer isn’t doing deployment work, there is no devops-role sitting in the account for an attacker to assume.
Many companies don’t follow this model because it’s challenging to set up and maintain. Someone has to define what “the permissions needed for this task” actually means, and you need tooling that can attach and detach policies reliably. This functionality that’s extremely challenging to build yourself.
This is also the way that most agentic identity security solutions work, as agents are prone to abuse longstanding access. Instead, teams are looking to properly assign permissions to an agent to accomplish its task and then revoke after the task is completed.
Ideal use cases: Day-to-day engineering access to sensitive resources
Worst use case: Legacy systems
Pros: Drastically reduces your identity attack surface, clear & auditable engineering workflows for getting access to a specific machine
Cons: Implementation and management complexity
What to choose
Most organizations will benefit from combining all three of these approaches, depending on their internal systems. Checkout flows are better than nothing for legacy systems, timed group access is a meaningful upgrade for escalations, and direct permission assignment is where you actually want to end up – because the goal of JIT was never “access with a timer…” it was no standing access at all.
Because there are many ways to go about accomplishing JIT, it’s more important than ever for teams to carefully consider their approach. While JIT is simple in theory, architectural decisions have major ramifications for both ongoing maintenance and day-to-day usage.