Should organisations prioritise JIT access over vault expansion?

Why This Matters for Security Teams

Prioritising JIT access over vault expansion is fundamentally a decision about reducing standing privilege, not just improving credential storage. A larger vault can improve custody, but it still leaves reusable secrets available somewhere, which means the blast radius remains if an identity is overused or a token is exposed. NHIMG research on the Guide to the Secret Sprawl Challenge shows why centralisation alone does not solve exposure when secrets keep accumulating across systems.

That distinction matters because most real-world compromise paths are operational, not theoretical. Once an NHI credential is reused across applications, stored in multiple places, or left active after the need has passed, the organisation is relying on perfect discipline across every team and pipeline. Current guidance suggests that reducing credential lifetime is usually more effective than simply moving credentials into a larger vault, especially when the access request can be evaluated at runtime. The OWASP Non-Human Identity Top 10 treats overprivileged and poorly governed NHI access as a primary risk, not a storage problem. In practice, many security teams encounter secret exposure only after reuse, leakage, or offboarding failure has already occurred, rather than through intentional design.

How It Works in Practice

JIT access works best when the workload can prove what it is, request only what it needs, and receive access for a narrow task window. The practical model is not “no vault,” but “minimal reliance on reusable secrets.” A workload identity can authenticate with cryptographic proof, then request a short-lived credential or token that expires automatically after the task completes. That makes the control point the request itself, not a long-lived secret stored for future reuse.

Security teams usually combine four mechanisms:

• Workload identity for the agent or service, rather than shared static credentials.
• Runtime authorisation that evaluates context, purpose, and target resource at the moment of access.
• Ephemeral secrets or tokens with tight TTLs and automatic revocation.
• Policy-based approval paths for exceptional access, so standing privilege is not the default.

This is where 52 NHI Breaches Analysis is useful: it reinforces that identity misuse often follows lifecycle failures, not just weak storage. For implementation guidance, the SPIFFE model is widely used to represent workload identity, while OAuth 2.0 Token Exchange is commonly used when one workload needs a narrowly scoped downstream credential. A vault still has a role, but it becomes a broker for short-lived issuance rather than a place to park long-lived secrets indefinitely. These controls tend to break down when legacy applications require reusable passwords, static API keys, or manual human approvals for every request because the organisation cannot issue and revoke credentials at machine speed.

Common Variations and Edge Cases

Tighter JIT controls often increase operational complexity, requiring organisations to balance blast-radius reduction against application compatibility and change management. That tradeoff is real, especially in environments with vendor systems, batch jobs, or legacy integrations that were built around static secrets. Best practice is evolving here: there is no universal standard for every workload class, so the decision should be based on whether the access pattern can be made ephemeral without breaking the service.

In some cases, vault expansion is still useful as a transitional control. It can improve inventory, owner visibility, and rotation coverage while teams migrate away from standing credentials. But it should not be treated as the end state if the environment still relies on reusable tokens. NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets is a good reference point for separating custody from exposure, and the 2025 State of NHIs and Secrets in Cybersecurity shows how often secrets remain active or duplicated in practice.

The strongest exception is a system that cannot yet support runtime issuance or workload identity. In those environments, expansion may reduce disorder, but it should be paired with a migration plan toward JIT, not mistaken for a lasting risk reduction strategy.

Related resources from NHI Mgmt Group

• When should organisations prioritise workload IAM over vault expansion?
• When should organisations prioritise Zero Standing Privilege for non-human identities?
• How should security teams decide whether JIT access is safe for non-human identities?
• What is the difference between JIT access and Zero Trust for NHIs?