Vaults protect stored credentials, but they do not by themselves control who can use them, how access is revoked, or how shared credentials are governed. Without centralized policy and lifecycle control, the organisation still lacks enforceable identity governance.
Why a vault is not the same as identity governance
A standalone vault is a storage and retrieval control. It can reduce secret exposure, but it does not decide which identity should receive which credential, whether access is still justified, or whether a shared account should exist at all. That missing control plane is why vaulting alone leaves an IAM gap: the credential may be protected, while the authority to use it remains weakly governed.
In practice, the gap appears when teams treat “the secret is in the vault” as equivalent to “the identity is managed”. A vault can still sit beside unmanaged accounts, orphaned integrations, stale service credentials, or unclear ownership. The result is an access path that is technically protected but not operationally governed.
A better way to think about the vault is as a component in a wider identity lifecycle. It should support issuance, rotation, revocation, and auditability, but those decisions need policy, ownership, and review. Without that surrounding governance, the vault becomes a safer place to keep a problem rather than a system that closes the problem.
What the IAM gap looks like in daily operations
The gap usually shows up in three places. First, access provisioning: teams manually hand out shared credentials instead of tying usage to a named identity and an approval path. Second, revocation: when staff leave, applications change, or vendors are offboarded, the vault entry may remain valid even though the business need has ended. Third, governance: no one can prove who used the credential, why they still need it, or whether it has crossed environments or teams.
That is why identity lifecycle controls matter as much as secret storage. NHIMG’s NHI Lifecycle Management Guide and Lifecycle Processes for Managing NHIs both frame rotation, offboarding, ownership, and recertification as lifecycle problems, not vault-only problems.
The same applies to shared credentials. If multiple systems or operators can retrieve the same secret, the vault has preserved the credential but not the accountability chain. That is where governance must answer who may check it out, under what conditions, and how quickly that access disappears when the need changes.
How vaulting fits into a complete IAM control model
Vaults are most effective when they sit inside an enforced access model with least privilege, approvals, recertification, and rotation policy. In that model, the vault is not the decision-maker. It is the enforcement point for decisions made by IAM, PAM, and lifecycle governance. Privileged Access Management Guide and Identity Security Programme Guide both reflect that the real control is the policy layer around access, not the storage layer alone.
For machine and workload credentials, the issue is even sharper because long-lived secrets are easy to reuse, copy, and forget. NHIMG’s Guide to NHI Rotation Challenges and Cloud Workload Identity Guide show why credential lifecycle and keyless patterns reduce dependence on secrets that a vault merely stores.
The practical standard is simple: a vault should support revocation and short-lived access, not hide the absence of governance. If retrieval is possible without policy checks, approval context, or timed expiry, the organisation still has standing access, only wrapped in a stronger container.
Risk and Threat Considerations
When vaults are deployed as the only control, the main risk is silent privilege persistence. Shared or long-lived credentials can survive role changes, vendor exits, and project shutdowns, which makes later misuse harder to detect and easier to rationalise as legitimate access.
Failure mechanism: The vault protects the secret value, but access to that secret remains decoupled from identity lifecycle, approval, and revocation. A reused or shared credential can therefore continue functioning after the original business need has ended.
Impact: Excess access, delayed offboarding, weak accountability, and a larger blast radius if the credential is copied, leaked, or abused. At scale, this becomes an entitlement problem as much as a secrets problem.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Vault gaps center on credential lifecycle, rotation, and revocation. |
| AC-2 — Account Management | Shared and orphaned vault credentials are fundamentally an account governance issue. | |
| IA-9 — Service Identification and Authentication | Workload and service secrets in vaults are identity-bearing material for non-human access. | |
| Recommendation — Manage credential issuance, rotation, and revocation so stored secrets do not outlive their approved use. Tie vault access to managed accounts and disable access when the account or purpose ends. Use service identity controls and short-lived authentication instead of relying on static vaulted secrets. | ||
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | The question is about vault storage versus governable access and identity lifecycle. |
| Recommendation — Implement IAM policy and lifecycle controls around vault access, not vaulting alone. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Standalone vaults often preserve secrets that remain valid too long without lifecycle control. |
| NHI-01 — Improper Offboarding | Revocation failure is a core reason vaults leave an IAM gap. | |
| NHI-05 — Overprivileged NHI | Vaulted credentials can retain excessive access even when storage is secure. | |
| Recommendation — Shorten secret lifetime and pair vaulting with enforced rotation and expiry. Revoke vault access and downstream credential use immediately when ownership or need ends. Right-size the permissions behind each vaulted credential and remove unnecessary privilege. | ||
Practitioner Guidance
What to prioritise: Treat every vault entry as an access-controlled identity asset, not as a passive secret record. The first question should be whether the credential has a named owner, a defined purpose, and an expiry or review cadence.
What to verify: Confirm that retrieval is bound to policy, that revocation removes the ability to use the secret everywhere it is accepted, and that shared credentials are either eliminated or tightly exception-managed. If those three conditions are not true, the vault is improving storage hygiene but not closing the IAM gap.
Practitioner takeaway: A vault reduces exposure of the secret itself, but IAM closes the risk only when access, ownership, and lifecycle are enforced around that secret.