Just-in-time access only works when policy, approval, and expiry align

At a glance

What this is: This is Teleport’s analysis of how just-in-time access can be built into policy, approval workflows, short-lived privilege, and unified infrastructure access.

Why it matters: It matters because IAM, PAM, and infrastructure teams need JIT controls that actually constrain standing privilege across cloud and platform access rather than adding another approval layer on top.

By the numbers:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, meaning organisations failing to scope AI access properly are 4.5x more likely to experience a security incident.

👉 Read Teleport's analysis of just-in-time access and least-privilege workflows

Context

Just-in-time access is a policy problem before it is a tooling problem. The control only works when requests, approvals, role scope, and expiry are enforced as one identity workflow rather than as separate exceptions layered onto broad standing access. In practice, the risk is not that JIT exists, but that it is applied inconsistently across infrastructure identities, roles, and approval paths.

For IAM and PAM teams, the key question is whether elevation is truly ephemeral and resource-scoped, or simply a temporary wrapper around overly broad access. That distinction matters across NHI governance because service accounts, administrative roles, and infrastructure access all fail in similar ways when request logic, approval thresholds, and audit logging are not unified. The same governance pattern also becomes relevant as organisations extend identity controls to AI systems.

Teleport’s article is a typical example of a mature JIT implementation discussion rather than a breach-driven warning. The underlying governance challenge is familiar: if access can be requested, approved, and expired in different ways across different systems, least privilege becomes hard to prove and easy to bypass.

Key questions

Q: How should security teams implement just-in-time privileged access in cloud environments?

A: Start with the most sensitive administrative paths, then require approval, session bounds, and automatic expiry for each elevation event. JIT works best when it is paired with central policy, strong logging, and a clear offboarding path for temporary rights. The goal is to make privilege a short-lived state, not a persistent account property.

Q: Why do access control models still fail in mature IAM programmes?

A: They fail when the programme focuses on granting access but not on removing it. Even well-designed RBAC or PBAC policies can leave excessive permissions in place if offboarding, recertification, and exception management are weak. The control weakness is usually persistence, not the access model itself.

Q: What breaks when just-in-time access is bolted onto broad admin roles?

A: Broad admin roles turn JIT into temporary over-privilege instead of least privilege. The request may be time-limited, but the underlying entitlements still exceed what the task requires, which means the organisation has reduced duration without reducing blast radius.

Q: How do security teams know if just-in-time access is actually working?

A: Look for short-lived sessions, automatic revocation, and complete request-to-access logs. If approvals are still creating durable permissions, or if teardown depends on manual cleanup, then the programme is only partially ephemeral. Effective JIT should leave little or no reusable privilege behind after the task ends.

Technical breakdown

JIT access as native RBAC policy

The article describes JIT as a native policy layer rather than an exception flow. In that model, role-based access control defines which roles can be requested, and identity provider traits can map users into requestable access paths. The important technical shift is that request-time enforcement happens through policy evaluation, not through manual privilege elevation. Access is still certificate-backed and time-bounded, but the real control point is the role definition and the request constraints attached to it. That prevents users from asking for arbitrary access while preserving auditable workflow consistency.

Practical implication: model JIT at the role and policy layer first, then verify that every privileged path is requestable only through approved RBAC rules.

Approval workflows need contextual guardrails

Teleport’s workflow design uses contextual approval thresholds, ticket prompts, regex validation, and on-call integrations to decide whether a request should be auto-approved or escalated for review. This matters because approval is not just a human checkpoint, it is part of the enforcement chain. If approvers can bypass context or if requests can be approved without validating purpose, timing, or reviewer independence, JIT becomes a convenience feature rather than a control. The technical issue is governance logic: the approval path must be able to distinguish routine operational need from privileged overreach.

Practical implication: tie approval criteria to role, purpose, and operational context so elevated access cannot be approved without a verifiable business reason.

Ephemeral access only works when expiry is enforced automatically

Short-lived access depends on the system calculating duration from policy, request parameters, and session constraints, then revoking access without manual intervention. That is materially stronger than asking users or admins to remember to remove elevation later. The article also notes that access should not begin before a defined start time, which is useful for scheduled maintenance and controlled change windows. The architectural point is simple: expiry must be enforced by the identity service itself, or the temporary privilege window can silently become standing access.

Practical implication: enforce automatic expiry and start-time boundaries at the identity layer so no privileged session can outlive its approved window.

NHI Mgmt Group analysis

JIT access fails when organisations treat elevation as an exception instead of a governed identity state. The article shows why bolted-on JIT controls struggle in cloud-native environments: request, approval, and expiry must behave like one policy system, not separate workflow steps. That is especially true when privileged access spans humans and infrastructure identities, because the same standing-access problem appears across PAM, NHI, and platform operations. The practitioner conclusion is that elevation must be designed as a first-class identity state, not an ad hoc override.

Least privilege by design is the more durable model because it starts from the resource, not the request. Teleport’s approach is directionally important because it forces access decisions to be calculated against the minimal set of roles needed for a specific asset. That aligns with OWASP Non-Human Identity Top 10 concerns about overprivilege and with the NHI governance reality that broad roles are often the real source of privilege creep. The practitioner conclusion is that requestable access should be derived from asset scope, not inherited from generic admin patterns.

Unified access logging matters because fragmented JIT systems create blind spots faster than they reduce risk. When requests, approvals, and certificates live in separate silos, audit evidence becomes incomplete and revocation logic becomes inconsistent. A centralised control plane gives security teams one place to inspect elevation behavior across SSH, Kubernetes, databases, and cloud consoles. The practitioner conclusion is that JIT maturity is as much about evidence integrity as it is about speed.

Ephemeral credential trust debt: Temporary access still creates governance debt when policy does not fully define who can request what, why, and for how long. The value of short-lived access disappears if the surrounding identity model still assumes broad baseline privilege. The practitioner conclusion is that temporary access must be treated as a lifecycle control, not a one-time workflow fix.

JIT for infrastructure is only effective when approval logic, time limits, and role scope are enforced together. If any one of those controls is optional, the access path reverts to standing privilege with a delay. That is why least privilege, revocation, and auditability need to be engineered as one operating model. The practitioner conclusion is to validate the full request-to-expiry chain, not just the approval step.

From our research:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to The 2026 Infrastructure Identity Survey.
• In the same survey, 70% of organisations grant AI systems more access than they would give a human employee doing the same job, which shows how quickly policy and practice diverge.
• For a deeper governance baseline, compare this with Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for the lifecycle controls that keep temporary access from becoming standing privilege.

What this signals

Ephemeral access will not fix weak governance if policy scope remains broad. The next phase of JIT maturity is not faster approvals, but tighter identity design across requestable roles, expiry logic, and audit integrity. Teams that already rely on infrastructure identity controls should treat JIT as a lifecycle control that must survive scale, not as a convenience workflow for operations.

The governance signal is that access controls are converging across human, NHI, and infrastructure workflows. If requestable access is still tied to manual review in one environment and automated expiry in another, the organisation is carrying two different trust models at once. That inconsistency becomes visible quickly when privileged activity expands across cloud and platform estates.

For practitioners

• Map every privileged path to a requestable role Inventory who can request access to SSH, Kubernetes, databases, cloud consoles, and internal apps, then confirm the requestable roles are tightly bounded by resource scope and deny rules.
• Automate expiry at the identity service Set access duration from policy and session constraints so elevated access expires automatically without manual revocation tasks or help desk intervention.
• Bind approvals to contextual evidence Require ticket IDs, reason prompts, or on-call status before elevation is approved, and reject any request that cannot be tied to an auditable operational need.
• Consolidate JIT audit trails Route request, approval, and certificate events into one audit log so reviewers can trace the full privilege lifecycle across infrastructure types.
• Review whether JIT is replacing standing privilege or masking it Test whether a granted session is truly ephemeral or just a temporary wrapper around overbroad default access that remains in place after the request closes.

Key takeaways

• JIT only reduces risk when role scope, approval logic, and automatic expiry are enforced as one identity control.
• The real weakness in many implementations is not request speed, but the persistence of broad entitlements behind a temporary workflow.
• Unified logging and lifecycle enforcement determine whether JIT is a governance control or just a delayed form of standing privilege.

Key terms

• JIT — Just-in-Time Access: A security approach that grants access permissions only for the duration needed to complete a specific task, then automatically revokes them. JIT access eliminates standing privileges for NHIs, dramatically reducing attack surface.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Least Privilege: A security principle requiring that every identity — human or non-human — is granted only the minimum permissions necessary to perform its function. Least privilege is the single most effective control for reducing NHI blast radius.
• Approval Threshold: An approval threshold is the rule that determines how many reviewers, what kind of reviewers, or what contextual evidence is required before access is granted. In practice, it is the governance gate that turns a request into an auditable decision rather than a manual favour.

What's in the full article

Teleport's full article covers the operational detail this post intentionally leaves for the source:

• Role-by-role configuration examples for requestable access paths across infrastructure systems
• Approval rule examples using ticket prompts, reviewer thresholds, and on-call integrations
• Access duration logic that determines when elevated access begins and how it expires
• Centralised audit logging across SSH, Kubernetes, databases, and cloud consoles

👉 Teleport's full post covers the JIT policy logic, approval thresholds, and expiry behaviour in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.