Just-in-time (JIT) access isn’t easy. This Reddit thread of cybersecurity pros surfaces many of the most common JIT headaches — and you may be encountering those same challenges yourself.
As noted in the thread, no users should be “swimming in access”, especially as standing privileges and over-permissioned accounts continue to be a major source of breaches. The truth is, many JIT models struggle to keep up with today’s fast-moving, cloud-native environments.
At Teleport, we see these challenges firsthand. For JIT to work well within today’s environments, it can’t be bolted on. It needs to be fundamentally integrated with identity, policy, and workflows.
In this post, we’ll explore the features that enable Teleport to tackle these JIT challenges head-on — simplifying least privileged access, streamlining access request/approval workflows, and strengthening infrastructure resiliency.
JIT access as a native policy (not an exception)
In many implementations, just-in-time access operates as an override — a temporary break in the normal rules of access. With Teleport, JIT access is the rule by default. Access requests are fully integrated into role-based access control (RBAC) and configured on a role-by-role basis.
This means engineers do not ask for ad-hoc permissions. Instead, administrators define exactly which roles can be requested using allow.request.roles
, and can restrict access by identity provider traits using claims_to_roles
.
This allows access to roles like dev
, dba
, or prod-admin
, while denying access to more sensitive roles or those not tied to the user's group. Everything is cryptographically enforced by the Auth Service at request time, and applied automatically via SSO, CLI, or API.
Automated approval workflows
With guardrails in place for what can be requested, the next challenge is ensuring approval workflows don’t become bottlenecks.
To do this, Teleport roles support fine-grained controls to determine when and how access requests can be reviewed and approved. This includes the ability to automate request approvals based on role, context, or other defined attributes.
For example, you can condition access requests with:
- A reason with a custom prompt, such as “Please provide your ticket ID”
- One or more approval thresholds, such as “three non-team reviewers OR one super-approver with a valid ticket number”
- Regex-based filters that validate request reasons
- Session moderation or dual-authorization requirements for access to sensitive resources
With plugin integrations, Teleport can auto-approve access if the requester is on-call in tools like PagerDuty or Opsgenie. This increases JIT access speed and policy enforcement while still enabling any necessary on-call firefighting.
Short-lived, ephemeral access
After an access request has been approved, Teleport determines exactly how long access should last and ensures it expires automatically.
Access duration is calculated automatically by analyzing user-request time parameters, role-based security policies, and any current session constraints. This approach prevents privilege over-extension by consistently enforcing the most restrictive time limit — eliminating security gaps that may result from setting duration manually.
You can also specify the earliest times users are permitted to assume elevated privileges (using the --assume-start-time
flag). This ensures that even if a request is approved, the user does not assume access until the right time. Perfect for scheduled maintenance or other pre-planned tasks.
The result is ephemeral, short-lived access that minimizes the risks of standing privileges. Once the certificate expires, access automatically expires, too, removing the need (and risks) posed by manual elevation/revocation.
Least privilege by design
Conventional JIT solutions typically grant permissions through overly-broad/generic roles — counterintuitive to the principle of least privilege. Instead of this approach, Teleport adopts least privilege as the foundation for all access controls, rather than an afterthought.
When a resource is requested, Teleport consults the policy to determine the minimal set of roles required to grant access only to that specific resource, thereby enforcing least privilege.
For example, an engineer can request access to a specific server, database, or Kubernetes cluster, and Teleport calculates which roles would grant that access via search_as_roles
. Admins can restrict this using allow.request.search_as_roles
, ensuring users can only request access to the resources they’re allowed to see, and only if those roles clear deny rules and filters.
Unified access across all infrastructure
Managing multiple just-in-time systems and policies across a myriad of resource types eats away at manual overhead and exposes security gaps that can jeopardize the security benefits of JIT (least privilege, reduced attack surfaces, etc.) altogether.
Teleport eliminates these JIT silos completely by providing a unified access plane that is resource-type agnostic. The same identities, RBAC, access request workflows, approval logic, and certificate-based enforcement are applied equally across all resources, including:
- SSH
- Linux servers
- Kubernetes clusters
- Internal apps
- Databases
- Remote desktops (Windows)
- AWS or GCP console
Because all infrastructure is unified, all JIT activity (requests, approvals, etc.) goes into the same centralized audit log, simplifying compliance and visibility.
Get started with Teleport for JIT access
Teleport simplifies just-in-time access by introducing automating approvals, enforcing least privilege, and ensuring all access is ephemeral and fully auditable — removing manual friction and security gaps for good.
Engineering work gets done faster. Security teams sleep better. And most importantly, infrastructure resiliency increases, even as environments scale, teams grow, and threats evolve.