Just-in-time access still depends on where trust sits

At a glance

What this is: This is an analysis of why just-in-time access is not only a temporary credential pattern, but an architecture question about who controls issuance, trust, and cryptographic custody.

Why it matters: It matters because IAM and NHI teams can reduce exposure windows without really removing standing privilege risk if the trust boundary still sits with the wrong control plane.

👉 Read Akeyless's analysis of just-in-time access and trust boundaries

Context

Just-in-time access is a governance pattern for replacing standing privilege with time-limited access that is issued only when needed. The problem is that expiry alone does not answer who controls the credential path, the cryptographic material, or the policy decision that makes access possible.

For NHI and human IAM programmes alike, that means the real design question is not whether access is temporary, but whether the underlying trust model still leaves a provider, vault, or shared control plane in a position to reconstruct, broker, or retain the decisive credentials.

The article is also relevant to machine identities because the same pattern now covers workloads, CI/CD systems, cloud services, and APIs, where short-lived access can still leave a large governance gap if identity, authorisation, and key custody are not separated.

Key questions

Q: What fails when just-in-time access still leaves the provider in the trust path?

A: The control fails when the credential is temporary but the authority that mints, stores, or can reconstruct it remains persistent. In that case, you have shortened exposure without removing dependence on the same trust boundary, so the real risk shifts from the secret’s lifespan to the platform’s custody of issuance and cryptographic control.

Q: Why do short-lived credentials not solve NHI risk by themselves?

A: Short-lived credentials only shrink the exposure window. They do not remove the underlying permissions attached to the service account, OAuth scope, or workload identity that issued them. If privilege remains broad, an attacker can still abuse fresh tokens repeatedly. Effective control requires both token expiry and scope reduction.

Q: How should security teams evaluate JIT access for workloads and APIs?

A: They should check whether access is created only after identity is verified, whether credentials are bound to a narrow purpose, and whether the issuer can be separated from the sensitive material it protects. If those three conditions are missing, JIT is reducing one problem while preserving another.

Q: What is the difference between JIT access and zero-knowledge custody?

A: JIT access limits how long a credential can be used. Zero-knowledge custody limits who can ever reconstruct the protected key material. They are related but not interchangeable: the first narrows exposure time, while the second changes the trust model by removing the provider from the decryption path.

Technical breakdown

Why temporary credentials do not eliminate standing privilege

Temporary credentials reduce the lifetime of exposed access, but they do not automatically remove the trust relationships that issue, store, and revoke them. In many environments, the credential is ephemeral while the authority that mints it, holds the policy state, or can reissue it remains persistent. That distinction matters because the attack surface shifts from a long-lived secret to the infrastructure and control plane that govern the secret’s lifecycle. JIT access therefore has two layers: the visible credential and the invisible trust boundary behind it. Practical implication: assess whether the system issuing ephemeral access can still become the single point of compromise or abuse.

Practical implication: map who can mint, revoke, and reissue credentials before treating JIT as a completed control.

Identity-first authorisation for NHI and machine identities

In machine-heavy environments, JIT only works when identity is established before access is generated. The article describes a model where cloud IAM, Kubernetes identities, certificates, API keys, and enterprise identity providers authenticate the workload first, then policy determines whether dynamic credentials should exist at all. That is important because NHI governance fails when teams distribute secrets first and infer identity later. Identity-first design reduces credential sprawl, but only if the authentication boundary and authorisation policy are tightly linked. Practical implication: move from secret distribution to identity-gated issuance for workloads and service access.

Practical implication: require identity verification before credential creation for workloads, services, and automation.

Zero-knowledge trust separation changes the control question

The article’s strongest architectural claim is that cryptographic separation can prevent any single system from holding complete key material. In that model, the customer fragment stays under customer control and the provider cannot reconstruct the full encryption key. That changes the governance question from ‘are credentials short-lived?’ to ‘can the platform itself decrypt or reconstruct what it protects?’ For NHI programmes, this is a meaningful boundary because it reduces reliance on vendor trust for the most sensitive material. Practical implication: evaluate whether the architecture removes the provider from key custody or merely obscures that dependency.

Practical implication: verify whether cryptographic custody is truly segregated from the service provider.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
• BeyondTrust breach 2024: A stolen BeyondTrust Remote Support API key let a China state-sponsored actor reset accounts and reach US Treasury workstations in 2024.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Standing privilege is only half the problem: JIT access removes duration, but not necessarily control over the trust path that issues and governs the credential. If the platform that mints temporary access remains the effective custodian of policy and key material, the organisation has reduced exposure time without fully changing its dependency model. The practitioner conclusion is that JIT must be judged as trust architecture, not as a timer on privilege.

Identity-first issuance is the correct baseline for machine access: Workloads, pipelines, and services should authenticate before any credential exists, because distributing secrets first and validating identity later preserves the sprawl problem in a shorter form. This is where NHI governance intersects with IAM design: policy enforcement must sit ahead of issuance, not behind it. The practitioner conclusion is that machine identity should drive access creation, not merely gate access after the fact.

Zero-knowledge is a custody decision, not a marketing label: If a provider can reconstruct encryption keys, then the trust model still depends on provider discretion even when access is ephemeral. That matters because the architectural promise is different from operational convenience: one reduces reliance on vendor-held custody, the other only shortens the visible window of access. The practitioner conclusion is to separate credential expiry from cryptographic custody in every evaluation.

Runtime governance will absorb what JIT cannot express: As autonomous workflows and high-frequency machine execution expand, a one-time issuance decision will not capture enough context to govern behaviour after access is granted. That shifts identity governance toward continuous policy evaluation, where access creation and action authorisation become separate decisions. The practitioner conclusion is that JIT is becoming the floor, not the endpoint, for modern identity control.

Named concept: trust-boundary JIT. The critical design variable is no longer whether access expires, but where the authoritative trust boundary sits while access is created, held, and revoked. That concept applies equally to human admin access and machine credentials, because both fail if the provider or control plane remains too close to the credential lifecycle. The practitioner conclusion is to redesign JIT around custody and issuance boundaries, not just around short TTLs.

From our research library:

• 91% of organisations say at least half of their privileged access is always-on, and only 1% have fully implemented just-in-time privileged access, according to a CyberArk study.
• Read next: Just-in-Time Access and Zero Standing Privilege Guide

What this signals

Trust-boundary JIT: Organisations should stop treating temporary credentials as the end state and instead define where the authoritative trust boundary sits during issuance, use, and revocation. That framing applies to both human privilege and machine access, because expiry alone does not remove the control plane from the equation.

As autonomous workflows and machine identities increase, the governance issue shifts from credential duration to credential custody. Access models that cannot separate issuance authority from protected key material will leave practitioners with shorter exposure windows but the same structural dependency.

NHI teams should expect JIT to merge with broader privileged access governance rather than stand alone as a feature. The next maturity step is proving that temporary access, authorisation policy, and cryptographic custody are aligned under one operational model.

For practitioners

• Define the JIT trust boundary Document who can mint, hold, revoke, and reconstruct the credential path for each privileged workflow, then challenge any design where those powers sit in the same control plane.
• Require identity-first issuance for machines For workloads, pipelines, and APIs, authenticate the actor before generating secrets or temporary accounts, and reject designs that distribute credentials before identity is established.
• Separate cryptographic custody from service delivery Verify whether the provider can reconstruct encryption keys or access the material it protects, and treat any answer short of true custody separation as residual trust in the vendor.
• Classify JIT as part of the broader privileged access model Review whether temporary access is being used as a standalone feature or as part of a governed privileged access programme with clear policy, issuance, and revocation rules.

Key takeaways

• JIT access reduces exposure windows, but it does not automatically remove the trust boundary that governs credential issuance and key custody.
• For machine identities, identity-first issuance matters more than simply generating short-lived secrets after the fact.
• Teams should evaluate whether their JIT design changes custody and authorisation, or merely shortens the lifetime of a standing dependency.

Key terms

• 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.
• Zero-Knowledge Architecture: A design pattern in which the service provider cannot decrypt customer data because it never receives the keys needed to do so. The provider may store encrypted data and coordinate sync or processing, but it remains technically unable to read plaintext unless the architecture is broken.
• Identity-First Issuance: Identity-first issuance means verifying the actor’s identity before generating credentials or access rights. For human, machine, and autonomous contexts, it shifts governance to the moment of access creation and helps prevent secret sprawl, overprovisioning, and uncontrolled reuse of credentials.
• Trust Boundary: A trust boundary is the point where one system’s authority should stop and another system’s authority should begin. For internal automation, weak trust boundaries let monitoring, remediation, and execution share privileges that should have remained separate.

What's in the full article

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

• The specific Distributed Fragments Cryptography model and how the customer fragment is handled in practice
• The platform architecture details behind dynamic secrets, TTL handling, and policy enforcement across environments
• The way Akeyless describes JIT support for databases, Kubernetes, CI/CD systems, and cloud platforms
• The vendor's explanation of Runtime Authority and how continuous evaluation extends beyond initial credential issuance

👉 Akeyless's full article covers the architecture, custody model, and Runtime Authority details behind its JIT approach.

Deepen your knowledge

NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.