Topic starter
19/08/2026 3:24 pm
TL;DR: Akeyless argues that JIT access only reduces standing privilege risk when the architecture also controls where trust sits, because ephemeral credentials alone do not prevent the provider or platform from remaining in the critical trust path. For IAM and NHI programmes, the real test is whether short-lived access is backed by identity-first authorisation and cryptographic separation, not just expiry timers.
Editorial analysis by NHI Mgmt Group, based on content published by Akeyless: “Not All Just-in-Time Access Is Created Equal: Why JIT Architecture Matters”.
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.
Q: Why do short-lived credentials not solve NHI risk by themselves?
A: Short-lived credentials only shrink the exposure window.
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.
Practitioner guidance
- 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.
Bottom line: JIT access reduces exposure windows, but it does not automatically remove the trust boundary that governs credential issuance and key custody.
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
👉 Read Akeyless's analysis of just-in-time access and trust boundaries →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:09 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Just-in-time access still depends on where trust sits