TL;DR: Akeyless cites Gartner research showing secrets management is moving toward workload access management, secretless access, short-lived credentials, and governance across the multi-vault reality many enterprises already operate. The core shift is that vaulting alone no longer matches how modern workloads prove identity, so access control now matters as much as secret storage.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Akeyless's blog post: Secrets management is evolving into workload identity governance because modern applications, pipelines, containers, and AI agents authenticate through multiple identities and vaults, not a single storage model.
Why it matters: IAM and PAM teams need to treat secrets as part of workload identity lifecycle control, or they will keep managing storage while the actual access path fragments across clouds, tools, and runtime systems.
👉 Read Akeyless's analysis of workload identity governance in secrets management
Context
Secrets management is no longer just a vaulting problem. Modern workloads, including applications, containers, pipelines, automation scripts, and AI agents, need to authenticate continuously, and that pushes the control plane toward identity rather than static storage.
The governance gap is that many enterprises already run multiple vaults, multiple identity sources, and multiple ad hoc credential workflows at the same time. In that environment, centralising one vault does not remove the need to govern how workloads prove identity, receive access, and lose access again.
For IAM and NHI programmes, the practical question is whether secrets management is still being run as a repository project or as workload identity governance. That distinction determines whether teams reduce exposure or simply relocate it.
Key questions
Q: How should security teams govern workload access when static secrets are still in use?
A: Start by treating static secrets as transitional, not acceptable end-state controls. Map where service accounts, CI/CD jobs and workloads still depend on stored credentials, then move those paths to runtime identity and scoped issuance. The key decision is whether the credential can be verified and revoked per request rather than protected only by rotation.
Q: Why do multi-vault environments create governance problems for IAM teams?
A: Because control becomes fragmented across clouds, platforms, and development teams, each with different policy, audit, and rotation practices. The problem is not only tool sprawl, but process sprawl. IAM teams need one governance model that spans the estate so access decisions, lifecycle events, and audit evidence remain consistent.
Q: What breaks when teams treat secrets management as vault consolidation?
A: The programme usually succeeds at migration but fails at behaviour change. Teams keep bypassing central tools, credentials stay embedded in code or scripts, and the organisation still depends on reusable secrets. That leaves the underlying trust model untouched even after the move to a new vault.
Q: What is the difference between secretless access and secrets rotation?
A: Secretless access prevents the secret from becoming a durable artefact in the first place, while rotation only replaces an already existing credential. Rotation is still useful, but it does not solve credential distribution across code, pipelines, and runtime components that should never have held the secret.
Technical breakdown
Why static credentials keep failing in workload environments
Static credentials create a reusable trust object that must be stored, rotated, distributed, and eventually revoked. In workload settings, that model breaks down because the workload already has a runtime identity of some kind, such as a cloud identity, Kubernetes identity, certificate, or OIDC token. The article’s central technical point is that rotation changes the expiry date, but not the underlying pattern of reusable secret dependency. Secretless or secret-reduced access changes the authentication model so the workload proves who it is first, then receives a short-lived credential only when needed.
Practical implication: Treat long-lived API keys and tokens as a design smell, not a lifecycle problem to patch later.
Why every secrets manager depends on identity underneath it
A vault never operates in isolation. Before a workload can retrieve a secret, it must authenticate to the vault, and that authentication itself relies on some other identity mechanism. That might be managed cloud identity, local attestation, directory credentials, or certificates. The article highlights the hidden control plane problem: secrets management always rests on a trust decision about the workload itself. If that workload identity is weak, protected poorly, or shared too broadly, the vault becomes another access gate rather than a true control point.
Practical implication: Govern workload authentication to the vault as a first-class access control, not as an implementation detail.
Why multi-vault environments need governance, not consolidation theatre
Enterprises rarely operate one secrets manager anymore. They run AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, HashiCorp Vault, Kubernetes secrets, and platform-embedded credential stores at the same time. The article’s architecture argument is that forcing all teams onto one vault rarely survives operational reality. The real security challenge is consistency across decentralised stores, so policy, audit, rotation, and lifecycle control must follow the secret wherever teams already manage it.
Practical implication: Design for governance across vaults, not migration into a single vault as the only success metric.
Threat narrative
Attacker objective: Use a reusable workload credential to obtain repeated access across systems without needing to re-establish trust each time.
- Entry begins when a workload or attacker obtains a reusable static credential, such as an API key, token, or certificate that is stored in code, configuration, or a vault-backed workflow.
- Credential access expands because the same secret can be copied, reused, and rotated without changing the underlying trust model, so the credential remains exploitable if exposed.
- Impact follows when fragmented vault usage and bypassed control paths let credentials persist across clouds, teams, and pipelines beyond the point where central policy can reliably govern them.
Breaches seen in the wild
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
- Toyota T-Connect key exposure 2022: A subcontractor left a T-Connect server key on public GitHub from 2017 to 2022; 296,019 customers' emails were exposed, misuse unknown.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Workload identity governance is now the real subject of secrets management. Vaults still matter, but they are no longer the boundary of the problem. The boundary is how a workload proves identity, obtains access, and sheds that access again across clouds, pipelines, and runtime systems. Practitioners should stop treating secrets platforms as storage appliances and start treating them as identity control planes.
Static credential dependence is the governance failure, not merely a hygiene issue. Rotation helps after the fact, but it does not change the fact that the workload is carrying a reusable secret. That means the trust model still depends on something that can be copied, leaked, or overexposed. The implication is that identity-based issuance has become the control objective, not secret preservation.
Multi-vault sprawl creates policy drift unless governance is centralised above the vault layer. Different clouds and teams will keep different vaults, whether central security likes it or not. What matters is whether policy, audit, and lifecycle controls can travel across those stores without forcing a migration project that teams route around. Practitioners should measure control consistency across vaults, not count consolidation milestones.
Secretless access changes the timing of trust decisions. Instead of storing access and reviewing it later, organisations issue access at runtime from a trusted workload identity. That shifts governance from delayed review toward immediate authorisation. The practical conclusion is that access governance must happen at issuance time if the workload may only exist for the duration of a task.
Workload access management is the naming convention that finally matches the operating reality. The article’s strongest contribution is conceptual: it separates secret storage from workload authorisation. That distinction matters because many programmes still conflate vaulting with governance. The right model is to govern access, credential lifetime, and identity provenance together, or the same leakage patterns will reappear in new tooling.
From our research library:
- 88% of security professionals are concerned about secrets sprawl, with 49% of those in larger organisations described as "very concerned", according to the 2024 State of Secrets Management Survey.
- Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Multi-vault governance is now a control design problem, not a tool-selection problem. Enterprises should expect to keep multiple secrets stores across clouds and platforms, so the question is whether policy, audit, and lifecycle controls can operate consistently above them. The governance model has to be broad enough to follow the workload, not just the vault.
Secretless access will force teams to redesign how trust is issued. When workloads authenticate through cloud identities, Kubernetes identities, certificates, or OIDC tokens, the real decision moves to issuance time instead of storage time. That changes how IAM, PAM, and NHI teams define ownership, review, and exception handling.
For practitioners
- Map workload authentication paths Inventory how applications, containers, pipelines, scripts, and AI agents authenticate to vaults and secret stores today. Identify where they rely on reusable credentials rather than native workload identity, because those paths define the real control plane.
- Reduce dependency on static credentials Prioritise systems that can move to secretless or secret-reduced authentication using cloud identity, Kubernetes identity, certificates, or OIDC-based trust. Reserve long-lived secrets for exceptions that cannot yet support runtime issuance.
- Govern all active vaults as one policy surface Apply consistent access policy, lifecycle control, and audit expectations across AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, HashiCorp Vault, Kubernetes secrets, and any embedded vaults already in use.
- Measure secret sprawl as a control failure Track how many vaults, credential stores, and team-owned bypass workflows exist outside central oversight. Fragmentation is not just architecture debt, it is evidence that the governance model does not match operating reality.
Key takeaways
- Secrets management is shifting from vault administration toward workload identity governance because modern systems authenticate through multiple runtime identities and stores.
- Multi-vault sprawl is a governance signal, not just an architecture fact, because fragmentation weakens consistency in policy, audit, and lifecycle control.
- The practical response is to reduce static credentials where possible and enforce unified control across every vault that remains in use.
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 NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article focuses on reducing exposure from stored API keys, tokens, and certificates. |
| NHI-07 — Long-Lived Secrets | Static credentials and rotation limits are central to the article's critique of current practice. | |
| NHI-05 — Overprivileged NHI | Multi-vault sprawl and bypassed workflows increase the chance that workload access is broader than intended. | |
| Recommendation — Eliminate exposed secrets by moving workloads toward secretless authentication and tightly controlled issuance. Replace long-lived workload secrets with short-lived credentials issued at runtime wherever possible. Review workload entitlements across all vaults and remove standing access that is wider than task need. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article is about managing authenticators across workload access paths and reducing dependency on reusable secrets. |
| Recommendation — Apply authenticator lifecycle controls to rotate, replace, and retire workload secrets consistently. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Workload identity governance depends on consistent authorisation and entitlement control across multiple vaults. |
| Recommendation — Align workload authorisations with central policy so access decisions remain consistent across vaults and clouds. | ||
Key terms
- Workload Access Management: Workload access management controls what a non-human identity can reach while it is running. It turns identity and policy into runtime credentials, often through federation, brokering, or token exchange. For autonomous or agentic workloads, the main challenge is ensuring access stays bounded to the task that triggered it.
- Secretless Access: Secretless access is a pattern where workloads authenticate and receive access without relying on long-lived embedded credentials. It typically uses runtime identity verification, federation, and short-lived authorization decisions. The goal is to reduce exposure from hardcoded or reusable secrets while keeping machine-to-machine access functional.
- Multi-vault governance gap: The multi-vault governance gap is the mismatch between a single-vault PAM model and a real enterprise where secrets live in many stores with different rules. It appears when teams can see storage locations but cannot demonstrate control over the full identity path.
- Static Credential: A static credential is a long-lived secret such as an API key, password, token, or certificate that exists outside the moment of use. It creates persistent attack surface because it can be copied, stored, reused, and exposed across code, pipelines, configuration files, and third-party environments.
What's in the full article
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- The report's breakdown of workload access management patterns across applications, containers, pipelines, and AI agents
- The mapping of static credentials to short-lived issuance models, including where secretless access is operationally realistic
- The multi-vault governance capabilities described for AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, HashiCorp Vault, and Kubernetes
- The report's discussion of how teams can centralise policy and audit without forcing a single-vault migration
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 20, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org