When should organisations keep vaults versus move to session-time controls?

When a vault is still the right control boundary

A vault remains useful when the organisation still needs password storage as a durable fallback, for example for break-glass access, legacy systems that cannot do modern token exchange, or regulated environments where stored secrets are part of the control design. In those cases, the vault is not just a repository, it is the control plane for secret lifecycle, access policy, rotation, and auditability.

That is why teams should treat vaulting as a bounded exception rather than the default state. A vault is strongest when it is actively governing where secrets live, who can retrieve them, and how quickly they expire or rotate, especially in environments with many credentials to coordinate, as Guide to the Secret Sprawl Challenge shows. The practical test is whether the vault is preserving access that must exist, not preserving standing access that no longer needs to exist.

For teams managing secrets at scale, Guide to NHI Rotation Challenges is a useful reminder that vaulting only helps if rotation and dependency mapping are operationally viable. If rotation is brittle, the vault can become a long-lived secret warehouse instead of a security control.

Why session-time controls are usually the better default

Session-time controls shift enforcement from stored credentials to the moment of use. That reduces the value of a stolen secret, shortens the useful life of compromise, and makes access decisions more contextual because the session can be bounded by device state, user intent, time, risk signals, or approval. In practice, this is a better fit whenever the system can authenticate and authorise on demand without needing reusable passwords.

This is also the better answer when the goal is to reduce secret sprawl. Replacing persistent password storage with short-lived session authority removes one of the largest sources of credential exposure, particularly where applications, pipelines, and platforms are still tempted to cache or duplicate secrets across environments. The operational advantage is that enforcement happens closer to the request, so compromise of a static secret does not automatically become long-term access.

Session-time controls also align better with modern access patterns in distributed systems. If the system can issue bounded access at runtime, there is usually less reason to keep a static password as the primary security boundary. The vault may still exist behind the scenes for exceptions, but it should no longer be the main way the organisation proves or grants access.

How to decide whether the vault is a fallback or a dependency

The cleanest decision rule is to ask whether the organisation would still be secure and operable if the vault disappeared from the steady-state path. If the answer is yes, and the vault would only be used for exceptions, migration gaps, or break-glass recovery, then keep it but do not design around it. If the answer is no, the vault is still carrying primary control responsibility and should be treated as such until a session-based alternative is ready.

A second test is whether the vault contains secrets because the application truly needs them, or because the surrounding control model has not been modernised yet. Where the need is legacy compatibility, compliance retention, or emergency recovery, the vault can be justified. Where the need is simply convenience, the vault is usually hiding an avoidable standing-access problem.

For legacy estates, there is often a transitional period where both models coexist. In that phase, organisations should keep the vault only where it materially preserves business continuity, while moving normal access paths to session-time enforcement. The better design is usually hybrid, not absolute, but the direction of travel should be away from stored standing credentials and toward time-bounded access.

Risk and Threat Considerations

The main risk with keeping vaults too long is that they quietly become the highest-value target in the access chain. If a vault still stores reusable passwords, an attacker who reaches it can turn one compromise into broad downstream access, especially when secrets are long-lived, shared, or reused across systems. Session-time controls reduce that blast radius because the access decision is made at the moment of use rather than preserved as a standing credential.

Failure mechanism: Stored secrets remain valid after exposure, so a vault compromise, overbroad retrieval right, or stale credential can create durable access that is harder to contain than a bounded session.

Impact: The organisation can lose both confidentiality and control plane integrity at once, with attackers using the vaulted secret to move laterally, impersonate trusted systems, or bypass ordinary approval paths.

Practitioner Guidance

What to prioritise: Keep the vault only for secrets that genuinely need to exist outside the session boundary, such as break-glass accounts, legacy integrations, or explicit retention obligations. Everything else should be reviewed for session-time replacement first, because that is where the largest risk reduction usually comes from.

What to verify: Confirm that each remaining vaulted secret has an owner, a reason to exist, a rotation path, and a documented fallback use case. If you cannot name the exception condition, the vault is probably compensating for an outdated access design rather than supporting a real control requirement.

Practitioner takeaway: Treat vaults as exceptions management, not as the default security boundary. The more a system can enforce access at session time, the less reason there is to keep durable passwords as a primary control.

Related resources from NHI Mgmt Group

• How do organisations reduce the dwell time of exposed credentials at scale?
• When should organisations move from vault-centric PAM to real-time privileged access controls?
• When should organisations keep permissions in a relational database versus move to a dedicated authorization system?
• Should organisations keep graymail controls in end-user portals or move them into central email security workflows?