GitGuardian’s 2026 State of Secrets Sprawl report found 28.65 million new hardcoded secrets exposed in public GitHub commits during 2025, a 34% year-over-year increase. Credentials for AI services surged 81% as agentic workflows introduced new categories of machine credentials into production stacks. And 64% of secrets confirmed as valid in 2022 remained unrevoked heading into 2026.
Secrets managers do their core job well: they centralize storage, enforce encryption at rest and handle rotation schedules. But storing a secret and controlling who can use it are two different problems. Every workload that retrieves a credential from a vault still needs a bootstrap credential to authenticate to that vault in the first place. If the bootstrap credential is compromised, the attacker gains access to everything the vault protects. Security teams call this the secret zero problem.
The gaps grow in multicloud environments. Each cloud provider runs its own vault service with its own access controls and configuration model. Rotation policies do not propagate across providers, and credentials embedded in SaaS integrations sit outside the vault entirely. With CyberArk’s 2025 research showing machine identities outnumber human identities by roughly 82 to 1 in the average enterprise, the operational burden of managing all those credentials through vaults alone keeps rising.
Secrets managers remain a valuable part of the security stack, but they work best alongside other approaches. Five complementary methods can address the limitations that vaults alone cannot.
1. Cloud-Native IAM
For organizations operating primarily within a single cloud provider, native Identity and Access Management services offer tightly integrated security for non-human identities. AWS IAM Roles, Microsoft Entra ID and GCP IAM provide automatic credential rotation, fine-grained role-based access control and audit logging without requiring external tooling. These services work well when workloads stay inside one provider’s ecosystem because the identity primitives are native to the platform.
The limitation surfaces when you need to authenticate across cloud boundaries. Each provider has its own identity model, configuration syntax and trust semantics. An IAM role in one cloud means nothing in another. A workload that accesses resources in three clouds may need three separate identity configurations, each maintained independently with no guarantee they enforce the same access policies. For single-cloud deployments, native IAM is often the most practical starting point. For hybrid or multicloud environments, it works best when paired with identity federation or a workload IAM platform that provides a shared policy layer across providers.
2. OIDC Federation
OpenID Connect federation addresses the multicloud fragmentation that cloud-native IAM creates. It establishes trust relationships between providers so that a workload in one environment can authenticate securely to resources in another by exchanging tokens rather than sharing static credentials.
The mechanics are straightforward. A workload presents a signed OIDC token that describes who it is and where it runs. The receiving system validates that token against a pre-established trust relationship and issues a short-lived credential scoped to the specific request. No long-lived secret crosses the boundary. This federation model works well for organizations that have already invested in cloud-native identity and need to extend it across environments. Setting up 1:1 federation between two providers is direct. More complex multicloud topologies benefit from a central identity broker that manages trust relationships from a single policy layer, which avoids the configuration sprawl that comes with maintaining separate federation agreements between every pair of providers. The key advantage over secrets managers is that OIDC federation removes the stored secret from the equation entirely. The workload never stores a long-lived secret for the target environment. It proves its identity through a cryptographic token, and the target environment grants scoped, time-limited access on that basis.
3. Service Meshes
Inside a Kubernetes cluster, service meshes provide network-level authentication that can reduce or eliminate the need for application-managed credentials. A service mesh handles mutual Transport Layer Security (mTLS) between workloads automatically, encrypting traffic and verifying identity at the network layer. Workloads within the same cluster authenticate to each other through certificates managed by the mesh, not through secrets stored in a vault.
This approach is effective for securing intra-cluster communication. The mesh automates certificate issuance, rotation and revocation without requiring application code changes. Linkerd and similar tools handle this transparently. Projects like SPIRE provide a vendor-neutral foundation for workload identity using the SPIFFE specification, which assigns cryptographically verifiable identities to every workload regardless of where it runs.
The tradeoff is scope. Service meshes excel at securing workload-to-workload communication within a cluster, but they address the transport layer. They verify that two services can communicate securely. They do not evaluate whether a particular workload should access a particular resource given the current context. A service mesh can confirm that Service A is allowed to talk to Service B over an encrypted channel. It cannot enforce a policy that says Service A should only access the payments database during business hours from a production namespace. For authentication to external services, APIs and SaaS platforms, service meshes typically need to be paired with federation or a workload IAM platform.
4. PKI With Mutual TLS
Public key infrastructure combined with mTLS extends certificate-based authentication beyond the cluster boundary. Modern PKI platforms automate the full certificate lifecycle through protocols like ACME and EST, handling issuance, renewal and revocation without manual intervention.
Short-lived certificates serve as federated credentials: they authenticate the workload’s identity, expire quickly and do not create persistent attack vectors the way static API keys do. This approach is supported by most major cloud providers, which makes it particularly useful for authenticating workloads across hybrid and multicloud environments. Where a service mesh secures traffic inside a cluster, PKI with mTLS can secure connections between clusters, between clouds or between on-premises infrastructure and cloud services.
Some advanced secrets managers now include built-in features for managing certificates and automating mTLS configurations. For organizations that already run a vault with certificate management capabilities, the decision comes down to whether the vault’s PKI features are sufficient for the scale and cross-environment reach they need, or whether a dedicated PKI solution offers better coverage. The distinction matters most in environments where certificate issuance and renewal need to happen automatically across thousands of workloads spanning multiple trust boundaries.
5. Workload IAM
Workload IAM starts from a different premise than the four approaches above. It verifies a workload’s identity at runtime and brokers access based on policy. No stored credentials are needed.
The sequence works like this: a workload needs to access a database, an API or a SaaS service. It presents its identity through cryptographic attestation, typically an OIDC token that describes who the workload is and where it runs. The platform verifies that identity against a trust provider, evaluates an access policy that considers context like environment, time of day and security posture, then issues a short-lived credential scoped to the specific request. That credential expires automatically. No static secret is stored in the application.
This model closes the 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 credentials are scoped and ephemeral rather than persistent and reusable. And a workload IAM platform operates across trust boundaries. It applies consistent access policies whether the workload runs in AWS, Azure, GCP or on-premises infrastructure.
The conditional access capabilities in workload IAM platforms add a dimension that vault-based credential storage cannot replicate. Access policies can evaluate factors like the workload’s environment, geographic origin, time of request and security posture before granting credentials. A CI/CD pipeline that normally accesses a production database during business hours from a known region would be denied if the request came from an unexpected location at an unusual time. This context-aware enforcement is particularly important as organizations deploy AI agents that authenticate to APIs, databases and third-party services autonomously.
Stolen credentials were the leading initial access vector in 22% of breaches, according to the Verizon 2025 DBIR. That statistic reflects the cumulative risk of static credentials scattered across environments. Workload IAM addresses the root cause by replacing those credentials with secretless access tied to verified identity. For teams evaluating this approach, the practical path is to start with workloads you already know are sensitive: connections to production databases, third-party API access and CI/CD pipelines that deploy infrastructure. These are environments where the security benefit is immediate and the deployment impact is contained.
Matching the Tool to the Problem
No single tool eliminates every non-human access challenge. Secrets managers still serve a role for legacy systems that require static credentials. Cloud-native IAM and OIDC federation handle identity within and across clouds. Service meshes and PKI secure transport between workloads. Workload IAM ties these layers together by enforcing policy-based, identity-driven access across all of them.
The most effective approach matches each tool to the problem it was designed for and layers them so that gaps in one are covered by another. Aembit’s workload IAM platform verifies workload identity at runtime, brokers access through policy and issues ephemeral credentials across cloud and on-premises environments. Security teams get a consistent access layer that works alongside existing infrastructure rather than replacing it.
