Secrets managers vs workload IAM: where static credentials fall short

At a glance

What this is: This is an analysis of where secrets managers help and where workload IAM is needed, with the key finding that static credentials create unresolved bootstrap and reuse risk.

Why it matters: IAM and NHI teams need this distinction because many programmes still treat vaulting as the end state, when the real decision is whether a workload should authenticate with a persistent secret at all.

By the numbers:

• GitGuardian’s 2026 report found roughly 29 million secrets detected on public GitHub in 2025 alone, a 34 percent year-over-year increase.
• The 2025 Verizon DBIR cited credential abuse as the initial attack vector in 22 percent of breaches.

Context

Secrets managers centralise API keys, passwords and tokens, but they do not remove the underlying requirement for a workload to prove who it is before it can get access. That makes the topic a governance question as much as a storage question: if an application can authenticate with identity, a persistent secret may be an unnecessary liability.

The practical boundary is simple. Vaults are still needed for legacy systems, partner integrations and other targets that require stored credentials, but they do not solve secret zero, post-delivery abuse or fragmented policy across clouds. Workload IAM changes the model by making runtime identity the access primitive instead of the secret itself.

For NHI programmes, that distinction matters because workload identity is not a replacement for every vault use case. It is the mechanism that lets teams reduce the number of long-lived credentials they have to issue, monitor and rotate across modern cloud and platform-native environments.

Key questions

Q: What breaks when teams rely on secrets managers as the whole access model for workloads?

A: Secrets managers still protect stored material, but they do not remove the need for bootstrap trust or prevent post-delivery reuse. The result is a control that secures storage while leaving runtime abuse, replay and cross-cloud fragmentation unresolved. Teams should treat vaulting as one layer in the access model, not the model itself.

Q: When should organisations prioritise workload IAM over vault expansion?

A: Prioritise workload IAM when the same access pattern must work across clouds, SaaS integrations, and on-premises systems. Vault expansion helps with storage, but workload IAM matters more when the real problem is runtime authorisation and short-lived access tied to verified identity.

Q: How do security teams know whether their secrets programme is actually reducing risk?

A: Look at ownership, scope, rotation speed, revocation speed, and the number of places a secret is accepted. If the programme cannot answer those questions for every credential, it is managing storage rather than reducing exposure. The most useful metric is the time a secret remains viable after compromise.

Q: What is the difference between secrets management and workload identity?

A: Secrets management protects stored credentials, while workload identity governs how a workload proves who it is before any secret is issued. Both matter, but workload identity addresses the bootstrap problem that secrets managers cannot solve on their own. In practice, identity should lead and secrets storage should support it.

Technical breakdown

Why secrets managers still leave secret zero in place

A secrets manager centralises storage, not trust establishment. A workload still needs some initial credential, token or platform identity to ask the vault for a secret, which is the classic secret zero problem. That bootstrap dependency often ends up in an environment variable, deployment script or platform-specific identity binding. Once introduced, it becomes part of the attack surface rather than a control boundary. The deeper issue is that vaults are excellent at protecting stored material but do not prove the caller’s runtime legitimacy. They retrieve and log; they do not continuously authenticate the workload that later uses the credential.

Practical implication: Treat bootstrap credentials as a separate risk domain, not as a solved vault problem.

How workload IAM changes runtime access for non-human identities

Workload IAM replaces stored-secret retrieval with identity verification at the moment of access. A workload presents a platform-backed identity, often through OIDC or similar federation, and the system evaluates policy before issuing a short-lived credential scoped to the request. That architecture matters because the credential is ephemeral, context-aware and bound to the verified workload rather than copied from a shared vault. The result is not just shorter lifespan but a different control plane: access is brokered at runtime, not distributed in advance. This is why workload IAM fits cloud-native services, serverless functions and other workloads that already have strong platform identity primitives.

Practical implication: Use identity federation where the target system can authenticate the workload directly.

Why cross-cloud credential sprawl outgrows vault-only governance

Vaults tend to operate inside their own trust domains, so a policy or rotation model in one cloud does not automatically govern another. As environments expand across AWS, Azure, GCP and on-premises systems, that fragmentation produces multiple inventories, access models and audit trails. The operational burden is not only rotation but consistency: the team must keep policy aligned across all places where secrets live. Workload IAM narrows that sprawl by separating identity from storage and making the decision layer portable across platforms. That shifts governance from “where is the secret stored?” to “is this workload authorised to receive access at all?”

Practical implication: Map where policy fragments today, then decide which workloads can move to federated identity first.

Threat narrative

Attacker objective: The objective is to turn one stored credential into broad, reusable access to systems and data that the vault was meant to protect.

1. Entry begins when a workload or attacker obtains a bootstrap credential, shared secret or cached token that can reach a secrets manager or downstream service.
2. Escalation follows when the retrieved credential is reused outside its original context, because the vault has no visibility into how the secret is later handled or replayed.
3. Impact occurs when the static credential is used to access databases, APIs or production systems with trust that outlives the original retrieval event.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static credential management is a control layer, not an access model. Secrets managers are still useful where credentials must exist, but they do not answer the governance question of whether the workload should need a persistent credential at all. The important distinction is between storing a secret safely and eliminating the need for the secret in the first place. Practitioners should treat vaulting as containment, not as the endpoint of identity design.

Secret zero is the first governance gap, not a corner case. Every vault-based model depends on some upstream trust anchor, and that anchor is itself a credential path that can be stolen, logged or misconfigured. Once a workload relies on a bootstrap secret, the programme has created a dependency that sits outside the vault’s protective logic. The implication is that access architecture has to be reviewed from issuance onward, not just at storage time.

Post-delivery risk is where static secrets lose the argument. A vault can log retrieval, but it cannot govern how a credential is cached, replayed or abused after delivery. That is why the control failure is not merely exposure, but reuse without runtime verification. In NHI terms, the decisive question is whether access is still bound to the workload that received it. Practitioners should assume the risk window starts after issuance, not after storage.

Workload IAM becomes the right model when identity can be proven at runtime. If a cloud-native workload already has a trustworthy platform identity, issuing a stored secret adds a second, weaker trust layer. That duplication creates rotation burden without improving assurance. The cleaner model is to let the workload prove itself and receive a short-lived credential only when policy allows it. Teams should reserve secrets managers for the systems that genuinely cannot do this.

Static secret sprawl is a lifecycle problem disguised as a storage problem. The same credential patterns that drive vault growth also drive offboarding, rotation and audit fatigue across NHI programmes. Workload identity reduces that lifecycle burden by shrinking the population of long-lived secrets that must be governed over time. The practical conclusion is to reduce the residual secrets estate where possible and govern the remainder as exceptions, not defaults.

From our research library:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• 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.
• Read next: Secrets Management Guide

What this signals

Ephemeral access is the design direction, not a niche optimisation. As environments move toward cloud-native and agent-adjacent execution, teams need to decide which workloads still deserve a stored credential and which can authenticate as identities. That decision changes how you govern issuance, revocation and audit because the control point moves from the vault to the runtime policy layer.

Vaults remain necessary, but only for the residual exception set. The strongest programmes will reduce the number of systems that require long-lived secrets and then manage those remaining credentials as tightly bounded outliers. That means reviewing workload classes, not just secret counts, and aligning your secrets programme with workload identity adoption rather than measuring success by vault adoption alone.

For practitioners

• Map every workload that still depends on a persistent secret Separate legacy systems that require stored credentials from cloud-native workloads that can authenticate with platform identity. The goal is to identify where vaulting is unavoidable and where it is only a habit.
• Eliminate bootstrap secrets where federation is available Replace static vault access paths with platform identity, OIDC federation or managed workload identity for systems that can authenticate directly. That removes secret zero from the design rather than merely hiding it better.
• Constrain remaining vault-issued credentials to the narrowest scope For systems that still need stored secrets, issue the shortest viable lifespan, bind access to specific workload identities and keep rotation automated so retrieval is tied to a governed lifecycle.
• Audit post-delivery usage, not only secret storage Look for caching, logging, replay and broad reuse after a secret leaves the vault. A retrieval log is not enough if the credential can be used elsewhere without the original workload context.

Key takeaways

• Secrets managers reduce the chaos of scattered credentials, but they do not eliminate bootstrap trust or post-delivery reuse risk.
• The scale of the problem remains high, with millions of secrets still exposed in public code and credential abuse remaining a common breach entry point.
• Workload IAM is the better fit wherever a system can authenticate itself at runtime, while vaults should be reserved for the systems that still require stored credentials.

Key terms

• Secret Manager: A secret manager is a control that stores and sometimes rotates credentials such as tokens, keys, and certificates. It reduces exposure of sensitive material, but it does not by itself establish ownership, entitlement context, or revocation accountability, which means governance can still fail even when storage is secure.
• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
• Secret Zero: Secret zero is the first credential needed to reach a secrets store, identity broker, or protected system. It is the root trust dependency that often survives even when everything else is rotated. If that initial credential is exposed, the rest of the secret model can collapse very quickly.
• Identity Federation: Identity federation is the practice of trusting one identity system to authenticate a user or workload for another system. It reduces login friction, but it also creates a dependency on assertion trust, policy consistency, and strong control over downstream authorization.

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.