Why do organisations outgrow basic secrets vaults when they start managing application identities across CI/CD and production environments?

Basic vaults often cover storage and retrieval, but they do not always address the operational realities of modern delivery pipelines. As teams expand into CI/CD and production, they need rotation, access workflows, scanning, certificate management, and consistent governance. Without those controls, secrets sprawl grows faster than the platform can contain it, and developers work around the intended process.

Why This Matters for Security Teams

Basic secrets vaults solve storage, but application identities in CI/CD and production introduce a lifecycle problem. Teams need to know which workload is asking for a secret, when it should exist, who approved access, how it is rotated, and what happens when the pipeline, runner, or service is compromised. That is why secrets management quickly becomes an operational governance issue, not just a secure storage issue.

The risk is not limited to repository leaks. NHIMG research in the State of Secrets Sprawl 2026 found that 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, and 64% of valid secrets leaked in 2022 are still valid and exploitable today. Those patterns show why vaults alone do not stop exposure once delivery systems start acting like production identities. Industry guidance in the NIST SP 800-53 Rev 5 Security and Privacy Controls and the OWASP Non-Human Identity Top 10 both point toward stronger control over machine credentials, but the real challenge is operationalising those controls across fast-moving pipelines.

In practice, many security teams discover the gap only after a runner token, deployment credential, or certificate has already been copied into an environment they never intended to trust.

How It Works in Practice

As organisations mature, the secrets vault becomes only one part of a broader identity system for software. The vault may still hold the secret material, but CI/CD jobs, build agents, deployment services, and production workloads need policy, rotation, and revocation around that material. The practical shift is to treat each application path as a non-human identity with a defined purpose, time limit, and scope of access.

A stronger model usually includes short-lived credentials, workload-bound authentication, and automated renewal or revocation. Instead of giving a pipeline a long-lived token, the platform issues a time-limited credential for a specific task, then removes it when the task ends. This aligns with the intent of modern guidance such as NIST Cybersecurity Framework 2.0 and helps security teams enforce least privilege without asking developers to manage credentials manually.

• Bind CI/CD identity to the runner or workload, not to a shared team account.
• Use short TTLs and automated rotation for secrets that must exist at runtime.
• Separate build-time, deploy-time, and production access so one compromise does not cross all stages.
• Scan for hardcoded secrets, but pair detection with automated revocation and replacement.
• Apply approval workflows for high-risk credentials, especially where production changes are involved.

NHIMG’s Guide to the Secret Sprawl Challenge is useful here because it frames sprawl as an operational outcome, not a tooling failure. That distinction matters: a vault can store a secret securely and still fail if every pipeline stage can mint, reuse, or copy that secret without context-aware controls. These controls tend to break down in highly parallel CI/CD environments because ephemeral runners, auto-scaling jobs, and multi-account deployment paths make ownership and revocation difficult to track.

Common Variations and Edge Cases

Tighter secrets controls often increase delivery friction, requiring organisations to balance speed against governance. That tradeoff is real, especially in environments with frequent releases, hybrid cloud estates, or legacy applications that cannot easily adopt workload identity.

Current guidance suggests that not every secret should be handled the same way. Some systems can move to dynamic secrets and just-in-time issuance quickly, while others still require transitional patterns such as centrally managed static credentials with aggressive rotation. There is no universal standard for this yet, and teams should avoid claiming that one vault pattern fits every application class.

Edge cases usually appear where identity boundaries are unclear. Shared runners, third-party deployment tools, and long-lived service accounts often create hidden coupling between environments. In those cases, the question is not only whether a secret is stored securely, but whether the application identity has been designed with a clear trust boundary from the start. NHIMG’s Top 10 NHI Issues helps teams think about those identity boundaries before they become incident response problems. The same applies when reviewing vendor and platform features through the lens of CI/CD pipeline exploitation case study. Teams usually outgrow basic vaults when they need governance over how credentials are requested, used, and destroyed, not just where they are stored.

Related resources from NHI Mgmt Group

• What happens when secrets are not centrally managed in CI/CD environments?
• Why do large Kubernetes environments often outgrow Sealed Secrets for secrets management?
• Why do machine identities with standing privilege create governance risk in production environments?
• Why do long-lived secrets create risk in GitOps and CI/CD pipelines?