Most organizations start their nonhuman identity security program with a secrets manager. It’s a sensible first step: centralize your API keys, database passwords and tokens in an encrypted vault instead of scattering them across config files and environment variables.

But as workloads multiply across clouds and the credential sprawl grows, the question shifts from “where do we store secrets?” to “do we need secrets at all?” The scale of the problem keeps climbing. 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, one of the top two entry points alongside vulnerability exploitation.

These numbers point to a gap that secrets managers alone can’t close. This guide walks through what each approach does well, where the boundaries are and how to decide what your environment actually needs.

What Secrets Managers Do Well

Secrets managers solve a real problem that existed before they came along: credentials stored in plaintext across codebases, wikis, Slack messages and developer laptops. By centralizing storage in an encrypted vault, they give your team a single source of truth for sensitive material.

In practice, a vault gives your team one place to store credentials instead of dozens. Your applications retrieve secrets through API calls rather than reading them from config files. Rotation happens on a schedule rather than when someone remembers to do it. And every retrieval is logged, so when an auditor asks who accessed the production database password last quarter, you have an answer. Tools like AWS Secrets Manager, Azure Key Vault and Google Cloud Secret Manager integrate natively with their respective platforms. Cross-platform tools extend that coverage to hybrid and multicloud environments.

For credentials that must exist as stored secrets, because the target system requires a password or API key and doesn’t support federated authentication, a vault is the right answer. Legacy databases, third-party SaaS APIs with key-based auth and partner integrations that require shared credentials all fall into this category. Secrets managers are also essential for encryption keys, TLS certificates and other cryptographic material that needs secure lifecycle management. If your security team needs to prove to an auditor that database credentials are rotated every 90 days, a vault with automated rotation gives you both the mechanism and the evidence trail.

The challenge starts when teams treat the vault as the complete solution rather than one layer in a broader access strategy. PCI DSS 4.0’s Requirement 8.6.3, which became mandatory after March 2025, requires that passwords for application and system accounts be changed periodically. A vault makes rotation possible, but it doesn’t answer the harder question: why does this workload need a persistent credential in the first place?

Where Secrets Management Hits Its Limits

Secrets managers store and protect credentials, but they manage secrets rather than access. That distinction matters more as your environment scales.

The first gap is the secret zero problem. Your vault centralizes storage, but the workload still needs an initial credential to authenticate to the vault itself. That bootstrap secret has to live somewhere, whether in an environment variable, a config file or a deployment script. If that bootstrap credential is compromised, the attacker gets access to everything in the vault. You’ve moved the problem rather than solved it. Modern vaults have started addressing this through platform-native identity (Kubernetes service accounts, cloud IAM roles), but configuring those integrations for every workload and environment adds operational complexity that many teams defer indefinitely.

A second gap opens after delivery. Once a secrets manager hands a credential to your application, its job is done. It has no visibility into how that credential is used, whether the application implements authentication correctly, whether the credential gets cached or logged, or whether the workload’s security posture has changed since the credential was issued. A leaked credential works for anyone who has it, regardless of context. The 2023 CircleCI breach illustrated this: malware on an engineer’s laptop stole a 2FA-backed SSO session token, and the attacker used it to access production systems and exfiltrate customer secrets. The credentials were encrypted at rest, but nothing in the pipeline verified whether the caller was the legitimate employee or an attacker replaying a stolen session from a different location.

The third gap is scope. Secrets managers operate within their own trust domain. Each cloud has its own vault service with its own access controls and configuration model. If you’re running workloads across AWS, Azure, GCP and on-premises environments, you’re managing multiple credential stores with no shared policy layer. A rotation policy in AWS Secrets Manager doesn’t propagate to Azure Key Vault, and neither coordinates with the credentials embedded in your SaaS integrations. CISA’s SCuBA Hybrid Identity Guidance prohibits hardcoded credentials in code or configuration files, but enforcing that consistently across fragmented vault infrastructure requires tooling that sits above the individual vaults.

What Workload IAM Adds

Workload IAM starts from a different premise. Instead of storing and distributing credentials, it verifies the workload’s identity at runtime and brokers access based on policy.

The sequence works like this: a workload needs to access a database or API. Instead of retrieving a stored secret, it presents its identity through cryptographic attestation, typically an OIDC token that describes who the workload is and where it’s running. The platform verifies that identity against a trust provider, evaluates an access policy that considers context like environment, time and security posture, and issues a short-lived credential scoped to the specific request. That credential expires automatically. No static secret is stored anywhere in the application.

This model addresses all three gaps that secrets managers leave open. The secret zero problem disappears because the workload authenticates through its platform identity rather than a stored bootstrap credential. Post-delivery risk drops because the credential is scoped and ephemeral rather than persistent and reusable. And a workload IAM platform operates across trust boundaries. It federates identity across clouds and enforces policy from a single control plane. Every access decision is logged with the workload’s verified identity, the policy the platform evaluated and the credential it issued. Your audit trail gets the context that vault access logs alone can’t provide.

For your developers, this means authentication is handled by the platform rather than implemented in application code. No custom credential-fetching logic, no rotation plumbing, no risk that a developer caches a token in a log file. For your security team, it means access decisions are centralized, context-aware and auditable. Conditional access can incorporate real-time posture checks from tools like CrowdStrike or Wiz, so a workload that fails a vulnerability scan loses access even if its identity is valid. NIST SP 800-207 specifies that policy engines must evaluate device characteristics, behavioral context and network location before granting access, and workload IAM implements that model for machine identities.

When You Need Both

Choosing between secrets management and workload IAM is rarely an all-or-nothing decision. Most environments have workloads at different levels of maturity, and the practical answer is usually a combination. The key is to start with what you already know is sensitive rather than waiting for a complete inventory of every credential in your environment. You already know where your most critical data sources are. Protect those first, then expand outward.

Cloud-native workloads, the ones running in Kubernetes, serverless functions and managed compute, are the best candidates for workload identity federation. These environments already have platform identity primitives that support cryptographic attestation. Moving them to identity-based access eliminates static credentials entirely for those workloads and removes the rotation burden that comes with them.

Legacy systems tell a different story. The on-premises databases, third-party APIs and partner integrations that require stored credentials still need a vault. The credentials have to exist, so the question is how tightly you can manage their lifecycle: automated rotation, scoped access, short expiration windows and centralized audit. Even here, you can reduce risk by ensuring that vaults issue credentials with the shortest viable lifespan and that retrieval is scoped to specific workload identities rather than broad service accounts.

CI/CD pipelines sit in between. Many CI/CD platforms now support OIDC-based federation natively, so pipeline jobs can authenticate to cloud resources without stored secrets. For downstream services that require keys, the pipeline can retrieve credentials from a vault at runtime and scope them to the specific job.

AI agents add a new dimension to this decision. Gartner predicts that 40 percent of enterprise apps will feature task-specific AI agents by end of 2026. These agents call APIs across organizational boundaries, chain operations dynamically and may operate on behalf of human users. Storing static credentials for an agent that reasons autonomously creates the same risks that led to the Salesloft/Drift and Snowflake breaches, but at a pace that manual vault administration can’t keep up with. Identity-based access is the only model that scales with autonomous workloads.

The decision framework comes down to two questions. First, does the target system support identity-based authentication? If yes, use workload IAM and skip the static credential entirely. Second, if a stored credential is required, can you minimize its lifespan and scope? If yes, a vault with automated rotation and just-in-time retrieval is the right fit.

Over time, the goal is to push more of your environment toward identity-based access and shrink the residual secrets footprint. Each workload you move from static credentials to federated identity is one fewer credential to store, rotate, monitor and respond to when compromised. The organizations that make steady progress on this transition, rather than waiting for a complete platform migration, are the ones building durable security posture.

Aembit’s workload IAM platform coexists with the secrets managers you already use. It federates identity across clouds, enforces policy-based access and brokers short-lived credentials for workloads that support it, while your vaults continue to manage the credentials that still need to exist.

Related Reading

• Secrets Management vs. Secrets Elimination: Where Should You Invest?
• Secrets Management Best Practices for Cloud Environments
• Securing CI/CD Pipelines: The Role of Workload Identity Federation