Because a secrets manager stores credentials, but it does not prove the workload’s identity or remove the need for a first trust decision. If the system still depends on a secret to fetch a secret, the organisation has only relocated the risk. The underlying access model remains static and vulnerable to leakage.
Why This Matters for Security Teams
Secrets managers solve storage and distribution problems, but they do not solve the harder question of whether a workload is truly the workload it claims to be. That gap matters because modern breaches often start with exposed API keys, over-permissive service accounts, or automation that can fetch more access after one credential is compromised. NHI Management Group’s Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
A vault can reduce secret sprawl, but if the workload still authenticates with a long-lived secret to retrieve another secret, the trust model remains static. That is a poor fit for cloud-native jobs, CI/CD runners, schedulers, and agents that scale dynamically and change context rapidly. The risk is not just leakage; it is also misuse after retrieval, because the secret usually conveys standing access rather than proof of workload identity. This is why current guidance increasingly points to workload identity, short-lived tokens, and runtime policy rather than vault-only controls. In practice, many security teams discover the weakness only after a pipeline or service account has already been abused, rather than through intentional design.
How It Works in Practice
In a stronger model, the workload proves what it is first, then receives narrowly scoped access for a single task or short time window. The best pattern is evolving toward workload identity backed by cryptographic assertions, such as the SPIFFE workload identity specification, combined with policy decisions made at request time. That is different from a secrets manager acting as the first trust anchor.
Practitioners usually layer controls in this order:
- Establish workload identity with machine-verifiable proof, not just a stored secret.
- Issue just-in-time credentials with tight TTLs and automatic revocation on task completion.
- Use policy-as-code to decide access based on context, workload, destination, and action.
- Rotate or eliminate long-lived secrets wherever a workload can use short-lived tokens instead.
NHI Management Group’s Guide to the Secret Sprawl Challenge and Lifecycle Processes for Managing NHIs both reinforce the point that secrets left in code, config, or CI/CD systems frequently outlive their intended use. A secrets manager can help centralise issuance, but it does not by itself bind the credential to a specific workload identity or prevent lateral reuse if the secret is stolen. This control model tends to break down in highly distributed CI/CD and ephemeral container environments because workloads are short-lived, autoscaled, and difficult to distinguish from one another without first-class identity.
Common Variations and Edge Cases
Tighter credential controls often increase operational overhead, requiring organisations to balance stronger assurance against deployment complexity. That tradeoff is especially visible in legacy estates, where applications expect a static secret and cannot easily move to federated workload identity or short-lived tokens.
There is no universal standard for this yet, but current guidance suggests prioritising replacement of standing secrets in the highest-risk paths first: build systems, secret retrieval chains, and machine-to-machine service calls. Some environments still need a secrets manager for bootstrap, break-glass access, or external SaaS integrations, but that should be treated as an exception with compensating controls, not the default architecture. The 52 NHI Breaches Analysis shows how often weak machine identity handling becomes an incident driver, while the OWASP Non-Human Identity Top 10 frames secret exposure, over-privilege, and poor lifecycle control as recurring failure modes. Secrets managers are still useful, but they are not an identity system, and they do not eliminate the need for runtime authorization, inventory, or revocation.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers secret rotation and lifecycle gaps that vaults alone do not fix. |
| CSA MAESTRO | Addresses agent and workload identity, trust boundaries, and runtime authorization. | |
| NIST AI RMF | GOVERN | Requires governance over AI and autonomous workload access decisions. |
Replace standing secrets with short-lived credentials and enforce automated rotation and revocation.
