Secrets managers vs workload IAM: where static credentials fall short

At a glance

What this is: This is an analysis of where secrets managers stop and workload IAM begins, with the core finding that static credential storage does not solve runtime access risk.

Why it matters: It matters because IAM teams need a split model for NHI governance: keep vaults for unavoidable secrets, but move cloud-native workloads, CI/CD jobs, and AI agents toward identity-based access where possible.

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• The 2025 Verizon DBIR cited credential abuse as the initial attack vector in 22 percent of breaches, one of the top two entry points alongside vulnerability exploitation.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.

👉 Read Aembit's analysis of secrets managers versus workload IAM

Context

Most organisations begin non-human identity security with a secrets manager because it solves a real problem: credentials spread across code, tickets, and developer systems. The issue is that storage is not the same as governance. Once access depends on a persistent secret, the programme still has to answer who should get it, how long it should live, and what happens after it is issued.

The primary keyword here is secrets managers versus workload IAM. That distinction matters for NHI programmes because cloud-native workloads increasingly have platform identity primitives already available, while legacy systems still force static credentials. The right model is not universal replacement, but deliberate reduction of stored secrets where identity-based access is technically possible.

Key questions

Q: How should security teams decide between secrets managers and workload IAM?

A: Use workload IAM wherever the target system can authenticate with federated identity, because that removes the reusable secret entirely. Keep a secrets manager only where a stored credential is unavoidable, such as legacy databases or partner APIs. The decision is less about preference and more about whether the application can safely avoid persistent secrets.

Q: Why do secrets managers not fully solve NHI risk?

A: They solve custody, not runtime trust. A vault can centralise storage and log retrieval, but it cannot stop a credential from being copied, cached, reused, or replayed after delivery. That is why organisations need runtime identity controls for workloads that can authenticate without a persistent secret.

Q: What breaks when a workload still depends on secret zero?

A: The programme inherits a hidden bootstrap exception that has to exist somewhere outside the vault. If that bootstrap secret is exposed, the attacker can reach everything protected by the vault path. In practice, secret zero turns centralised storage into a single high-value dependency instead of removing the risk.

Q: Should organisations remove all secrets and replace them with workload identity?

A: Not immediately. Legacy databases, SaaS APIs, and partner integrations may still require stored credentials, so a hybrid model is usually necessary. The practical goal is to eliminate static secrets wherever identity-based authentication is supported, then use vaults only for the remaining exceptions.

Technical breakdown

Secret zero and bootstrap credentials

Secret zero is the initial credential a workload needs in order to fetch other credentials from a vault. That bootstrap can live in an environment variable, config file, deployment script, or other weak control point, which means the vault centralises risk rather than eliminating it. In practice, the architecture still depends on a stored secret somewhere outside the vault boundary. Modern platform-native identity tries to replace that bootstrap with cloud IAM or Kubernetes service accounts, but every additional environment adds integration and policy complexity. Practical implication: treat secret zero as a design defect, not a deployment inconvenience, and map where bootstrap credentials still exist.

Practical implication: Inventory every bootstrap credential and remove it where platform identity can authenticate the workload directly.

Why secrets managers stop at storage

A secrets manager protects the credential at rest and logs retrieval, but it does not govern what happens after the application receives the secret. It cannot see whether the token is cached, copied, logged, reused, or replayed from elsewhere. That is why a stolen credential still works even when the vault itself is intact. The model is useful for centralisation and rotation, but it does not provide runtime identity assurance. Practical implication: separate storage control from access control, and do not treat vault logging as proof of safe use.

Practical implication: Use vaults for custody, then add runtime controls for the workload that consumes the credential.

Workload IAM and federated runtime access

Workload IAM changes the sequence by authenticating the workload itself at runtime and issuing a short-lived credential only after policy evaluation. The workload presents a federated identity, often via OIDC-backed attestation, and the platform checks context such as environment, posture, and policy before granting access. This removes persistent secrets from the application path and gives security teams a central decision point across clouds. The model fits cloud-native workloads, CI/CD jobs, and service-to-service access far better than a static secret model. Practical implication: prefer federated workload identity wherever the target system can accept it, and reserve vaults for true legacy exceptions.

Practical implication: Move cloud-native workloads to federated identity and keep vaults only for systems that still require stored credentials.

Breaches seen in the wild

• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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 secret storage is a custody control, not a governance model. Secrets managers solve the storage problem by centralising credentials, but they do not change the fact that a persistent secret can be copied, replayed, or overused once issued. That is why credential abuse remains a top entry path in breach data. The field should stop describing vault adoption as the endpoint and start treating it as one layer in a broader identity programme.

Secret zero is the trust assumption that never disappears. The vault still needs a bootstrap path, which means every deployment that authenticates to the vault with a stored secret inherits a hidden exception. That exception is manageable in low-scale environments, but it becomes a structural weakness as workloads multiply across clouds and pipelines. Practitioners should recognise that the architecture still assumes one credential can safely unlock others.

Workload identity changes the control boundary from storage to runtime assurance. When a workload authenticates through federated identity, the programme can evaluate context before access is granted and issue a short-lived credential instead of a reusable secret. That matters because the security question becomes who the workload is at execution time, not where its password is kept. For identity governance, this is the cleaner model for cloud-native access.

Ephemeral credential trust debt: The more systems rely on short-lived secrets without runtime identity, the more the programme accumulates hidden trust assumptions about bootstrap, retrieval, and reuse. This concept matters because a vault can shrink exposure windows without eliminating the dependency chain that created them. Practitioners should treat that debt as a migration signal, not a steady state.

AI agents make static secrets harder to defend at the speed they are consumed. When task-specific agents call APIs dynamically, the old assumption that one stored credential can be tightly managed by humans begins to fail in practice. That does not make every agent autonomous, but it does make persistent shared secrets a poor fit for high-frequency, cross-boundary execution. The governance conclusion is to push those workloads toward identity-based access wherever the target system allows it.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• Forward look: 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, a signal that emerging AI workflows need tighter identity control, as explored in Guide to the Secret Sprawl Challenge.

What this signals

Ephemeral credential trust debt: organisations that keep adding vaults without removing bootstrap dependencies will accumulate more hidden exception paths, not fewer. That debt shows up as more retrieval logic, more policy drift, and more places where a static secret can be replayed outside its intended context.

Cloud-native teams should expect identity-based access to become the default for Kubernetes, serverless, and CI/CD before it becomes universal across legacy estates. The practical shift is to design migration around high-value workloads first, then leave vaults in place only where the target system genuinely requires a stored credential.

The control conversation is moving from secret protection to access provenance. That means practitioners need to understand not just whether a credential is encrypted, but whether the workload that used it can be attested, scoped, and revoked in a way that survives cross-cloud operations.

For practitioners

• Map every secret zero dependency Identify which workloads still need a bootstrap credential to reach the vault, then replace those paths with platform identity where the target environment supports it.
• Classify credentials by persistence risk Separate stored credentials that are unavoidable from those that can be replaced by federated identity, and prioritise the long-lived secrets that cross cloud or environment boundaries.
• Move cloud-native workloads to federated identity Use OIDC-backed workload authentication for Kubernetes, serverless, and CI/CD jobs so the application never handles a reusable secret in the first place.
• Keep vaults for true legacy dependencies Retain secrets managers for databases, partner APIs, and other systems that still require stored credentials, but shorten lifespans and scope retrieval to the specific workload identity.

Key takeaways

• Secrets managers centralise credentials, but they do not eliminate the underlying trust problem once a static secret is issued.
• The scale of leaked and abused credentials shows why storage-only controls are no longer enough for modern NHI programmes.
• Workload IAM is the better default wherever systems can authenticate with federated identity, while vaults remain for unavoidable legacy exceptions.

Key terms

• Secret Zero: Secret zero is the first credential a workload uses to reach a vault or secret store. It is the hidden bootstrap dependency that often lives outside the vault itself, which means the system still depends on a protected secret before any stronger control can begin.
• Workload Identity: Workload identity is the runtime identity of a non-human system, such as a service, job, container, or agent. It lets the platform authenticate the workload directly and issue access based on policy, which reduces the need for persistent shared credentials.
• Federated Identity: Federated identity allows a workload to prove who it is through a trusted external identity provider instead of storing a local secret. For NHI governance, it is the cleaner path when a target system can accept identity-based authentication and short-lived access tokens.
• Ephemeral Credential: An ephemeral credential is a short-lived access token issued for a specific request or task. It lowers reuse risk because the credential expires automatically, but it still requires trustworthy identity proof and policy checks at issuance time.

Deepen your knowledge

Secrets managers vs workload IAM and secret zero reduction are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a migration path away from static credentials, it is a practical place to start.

This post draws on content published by Aembit: secrets managers versus workload IAM and where each model fits. Read the original.