Cloud-native secrets management and the limits of legacy vault models

At a glance

What this is: This is an analysis of cloud-native secrets management, with the central finding that legacy vault models often fail to match the speed, scale, and integration demands of modern cloud environments.

Why it matters: It matters because IAM, PAM, and NHI teams need controls that keep pace with machine-speed provisioning, rotation, and revocation across infrastructure, applications, and AI-enabled workflows.

By the numbers:

• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.

👉 Read Akeyless' analysis of cloud-native secrets management for multi-cloud environments

Context

Cloud-native secrets management is the discipline of controlling API keys, tokens, certificates, passwords, and other credentials across modern application and infrastructure stacks. The governance problem is no longer just where secrets are stored, but whether they can be provisioned, rotated, revoked, and audited fast enough for distributed systems.

In multi-cloud and Kubernetes-heavy environments, secrets are consumed by workloads rather than people, which changes the access model completely. The article argues that cloud-native delivery needs centralized policy, dynamic secrets, and tighter integration with CI/CD and identity systems because legacy vault patterns often assume slower, more manual administration.

That tension is typical of mature cloud programmes: teams need scale and automation, but they also need clearer ownership of non-human credentials across build pipelines, runtime services, and regulated environments.

Key questions

Q: How should security teams govern cloud secrets across DevOps and runtime systems?

A: Treat secrets as lifecycle-managed NHI credentials, not static configuration values. Assign ownership, scope every credential to a purpose, rotate it on exposure or expiry, and remove standing access wherever possible. The governance goal is to shrink the time and scope of usable access, especially in pipelines and cloud workloads.

Q: Why do static credentials create more risk in CI/CD and Kubernetes environments?

A: Static credentials are copied into many places, reused by many systems, and difficult to revoke cleanly once they spread. In CI/CD and Kubernetes, that persistence increases blast radius because one exposed secret can unlock multiple workloads, environments, or cloud resources.

Q: What do security teams get wrong about secret rotation?

A: They often treat rotation as a substitute for removing the underlying credential model. Rotation lowers exposure time, but it still leaves a secret to steal, bootstrap, and govern. If a workload can avoid holding the secret at all, that is a stronger control than simply changing it more often.

Q: How do organisations know whether secrets management is actually working?

A: Look for fewer exposed duplicates, faster revocation after discovery, and clear ownership for every credential. If secrets still appear in multiple locations or remain active after offboarding, the programme is producing alerts without reducing attack surface. The goal is measurable reduction in standing exposure, not just more findings.

Technical breakdown

Why static secrets fail in cloud-native pipelines

Static secrets become fragile when they are copied into pipelines, containers, and runtime configurations that move faster than human review cycles. In cloud-native systems, the same credential may be exposed in code, build logs, orchestration metadata, or shared documentation. The technical failure is not just exposure, but persistence. Once a secret exists in multiple places, revocation becomes a coordination problem across every system that cached or copied it. That is why rotation alone is insufficient unless the surrounding consumption model supports short-lived access and centralized revocation.

Practical implication: treat every persistent secret as a lifecycle risk, not just a storage object.

How dynamic secrets change non-human identity control

Dynamic secrets replace reusable credentials with time-bound credentials generated for a specific workload or request context. This changes the trust model from durable possession to ephemeral authorisation, which is better suited to service accounts, workloads, and API-driven systems. The important distinction is that dynamic credentials still need policy, identity binding, and auditability. Without those controls, temporary access can still become uncontrolled access if the issuance rules are too broad or the workload identity is poorly governed.

Practical implication: bind dynamic secrets to verified workload identity and narrow scopes before issuing them.

What secretless access changes in multi-cloud environments

Secretless access reduces the number of places a credential can be embedded, copied, or stolen by allowing applications to reach sensitive data or services without hardcoding reusable secrets. In practice, this shifts security effort from secret storage toward identity-mediated access, federation, and runtime policy enforcement. It does not remove secrets management requirements. Instead, it raises the bar for orchestration between identity providers, cloud services, and application platforms so that access can be granted without creating another long-lived credential layer.

Practical implication: evaluate whether secretless design reduces credential sprawl or simply relocates it into another control plane.

Threat narrative

Attacker objective: The attacker’s objective is to turn a leaked reusable credential into durable access that outlives the workload it was meant to protect.

1. Entry occurs when a secret is exposed in a CI/CD pipeline, documentation system, or application code path that multiple teams can reach. Escalation follows when that reusable credential grants access beyond the original workload, environment, or purpose. Impact arrives when the exposed secret is used to move laterally, extract data, or alter cloud resources without immediate revocation.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

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

NHI Mgmt Group analysis

Cloud-native secrets management has become an identity problem, not a storage problem. The article correctly frames secrets as credentials that power services, but the deeper issue is who or what is authorised to use them across CI/CD, Kubernetes, and multi-cloud runtime paths. Once a secret is embedded in an application workflow, the control challenge shifts from safekeeping to lifecycle governance, revocation, and access scope. Practitioners should treat secrets inventory as part of identity governance, not as a standalone vault exercise.

Dynamic secrets are the right default only when the consuming identity is equally dynamic. Time-bounded credentials reduce reusable exposure, but they still depend on trustworthy workload identity, policy accuracy, and predictable revocation. If the workload identity is weak, duplicated, or shared, dynamic issuance can simply accelerate over-privilege. The implication is that secrets strategy and workload identity strategy must be designed together, not sequenced as separate programmes.

Secretless access narrows attack surface, but it does not eliminate governance debt. Moving away from embedded credentials reduces one class of exposure, yet it increases reliance on federation, runtime policy, and control plane assurance. That matters because cloud-native environments often multiply those control planes faster than teams can operationalise them. The practical conclusion is that secretless architecture should be measured by how much credential sprawl it removes, not by how modern it sounds.

Secret sprawl is the governance gap that cloud-native teams keep rediscovering. The article’s emphasis on CI/CD integration and multi-cloud scale maps directly to the reality that credentials now live in many more places than vaults. That is why the relevant control question is not whether secrets are encrypted, but whether every issuance, copy, and revocation path is governed with the same discipline. Teams that cannot answer that question still have a secrets lifecycle problem, even if their vault is healthy.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• 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.
• That is why the Guide to the Secret Sprawl Challenge is the right next step for teams trying to reduce credential persistence and exposure paths.

What this signals

Secret sprawl is now a lifecycle problem that spans code, collaboration tools, and runtime systems. With 28% of secrets incidents originating outside repositories, teams need discovery that reaches beyond source control and into the operational places where credentials are actually shared and copied. The practical shift is toward inventory, revocation, and owner assignment across the full credential path, not just the repository boundary.

A useful way to think about this is credential persistence debt: every reusable secret that survives after its original purpose has passed adds hidden blast radius. The more cloud-native and distributed the environment becomes, the more that debt accumulates across pipelines, workspaces, and service dependencies. Practitioners should measure how much of the secret estate is still valid, still reachable, and still unaccounted for.

For teams building a broader NHI programme, this is also where policy, detection, and workload identity converge. The same governance discipline that controls service accounts and certificates needs to extend to dynamic issuance, collaboration tooling, and CI/CD artefacts, because the exposure path is now cross-domain rather than isolated to one vault or one repository.

For practitioners

• Map every secret to a consuming identity Create an inventory that ties each API key, token, certificate, and password to the workload, pipeline, or service account that actually uses it. Eliminate orphaned secrets that no longer have a clear owner or runtime consumer.
• Replace reusable credentials with short-lived issuance Prioritise dynamic credentials for databases, cloud resources, and APIs where the access pattern supports ephemeral use. Make revocation immediate and automate the checks that confirm old credentials are no longer accepted.
• Bind secrets to workload identity Require verified workload identity before issuing credentials so that a stolen secret cannot be replayed outside its intended context. Use policy conditions that constrain environment, purpose, and session scope.
• Audit non-code secret storage locations Search collaboration tools, ticketing systems, build artefacts, and documentation repositories for secrets because exposure increasingly starts outside source code. Treat those channels as first-class sources in your secrets governance programme.
• Measure revocation, not just detection Track how quickly exposed secrets are invalidated after discovery and whether downstream systems continue to accept them. A fast alert without effective revocation still leaves exploitable access in place.

Key takeaways

• Cloud-native secrets management fails when teams treat credentials as static objects instead of governed identity assets.
• The scale of secret exposure shows that detection alone is insufficient unless revocation and ownership are automated end to end.
• Practitioners should align secrets governance with workload identity, dynamic issuance, and cross-environment lifecycle control.

Key terms

• Cloud-Native Secrets Management: Cloud-native secrets management is the governance and automation of credentials used by applications, services, and pipelines in distributed environments. It focuses on secure issuance, rotation, revocation, and audit across cloud, container, and API-based systems rather than on manual vault operations alone.
• Dynamic Secret: A secret generated on-demand for a specific task and automatically revoked after use or expiry. Dynamic secrets dramatically reduce the risk of credential exposure compared to static, long-lived secrets and are considered best practice.
• 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.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.

What's in the full article

Akeyless' full article covers the operational detail this post intentionally leaves for the source:

• Implementation-oriented walkthroughs for cloud-native secrets workflows across AWS, Azure, GCP, Kubernetes, and on-premises systems
• Feature-level comparison details for multi-cloud deployment, secretless access, and dynamic secrets patterns in production environments
• Compliance and architecture specifics for regulated sectors that need to map secrets controls to their own control frameworks
• Practical examples of how the platform integrates with CI/CD and infrastructure-as-code pipelines

👉 The full Akeyless article covers deployment patterns, feature details, and compliance-oriented secrets workflows.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.