Secrets management in 2026: the governance gap behind sprawl

At a glance

What this is: Secrets management is the discipline of controlling digital credentials across applications and systems, with the key finding that hardcoded and mismanaged secrets create fast paths to infrastructure compromise.

Why it matters: It matters because IAM teams must govern machine access, human access, and workflow access together, or they will keep treating secrets as storage objects instead of live identity controls.

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.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• Only 44% of organisations are currently using a dedicated secrets management system.

👉 Read StrongDM's guide to secrets management best practices for 2026

Context

Secrets management is the discipline of storing, accessing, rotating, and auditing credentials such as passwords, API keys, certificates, and tokens. In practice, it exists because modern infrastructure depends on non-human identity access that must keep working without exposing the credential itself.

The governance gap appears when teams treat secrets as static configuration instead of living identity material. Once a secret is hardcoded, copied into CI/CD, or left in a config file, the access path can survive long after the developer, workload, or environment has changed. That is why secrets management is now a core NHI control, not just an operations utility.

Key questions

Q: How should security teams handle secrets sprawl across CI/CD and cloud systems?

A: Start by identifying every place secrets are created, copied, and consumed, then remove ad hoc storage outside approved controls. Centralise retrieval, require policy-based access for machine identities, and make rotation and revocation operationally routine rather than reactive. The goal is to reduce the number of valid credentials that can survive outside their intended workflow.

Q: Why do hardcoded secrets create such a large security risk?

A: Hardcoded secrets turn source code, build output, and configuration files into credential repositories, which makes exposure easy to repeat and difficult to contain. Once a secret is copied into multiple systems, revocation becomes slow and incomplete, and the attack window stays open far longer than most teams expect. That is why hardcoded credentials are a governance failure, not just a code smell.

Q: When does secrets rotation actually reduce risk?

A: Rotation reduces risk when the new credential replaces the old one quickly enough that exposure cannot be operationalised. It is effective only if the old secret is revoked everywhere it was copied, the change is coordinated across dependent systems, and the organisation can prove the previous value is no longer valid.

Q: What is the difference between password management and secrets management?

A: Password management protects human login credentials, while secrets management governs machine-to-machine and application credentials such as API keys, certificates, and tokens. The second problem is broader because non-human identities often need automated retrieval, rotation, and auditing at scale. A password-only model misses the identity behaviour that modern infrastructure actually depends on.

Technical breakdown

Secrets sprawl and hardcoded credential exposure

Secrets sprawl happens when credentials are duplicated across source code, pipelines, chat tools, tickets, and configuration files. The technical problem is not just discovery, but uncontrolled propagation across systems that were never designed to hold long-lived authentication material. Hardcoded secrets are especially risky because they turn code repositories into credential stores, which expands the blast radius from a single application to the wider infrastructure estate. Once copied, a secret is difficult to track, and revocation becomes a coordination problem rather than a simple deletion event.

Practical implication: map where secrets are created, copied, and consumed so you can reduce uncontrolled distribution before rotation becomes a cleanup exercise.

Automated rotation and lifecycle control

Rotation is the process of replacing a credential before its exposure window becomes useful to an attacker. Lifecycle control extends that idea from birth to decommissioning, covering issuance, renewal, expiry, and revocation. In modern environments, static credentials fail because they do not match the tempo of cloud deployments and CI/CD activity. A secret that remains valid for months after exposure is not just a leak, it is persistent access. Lifecycle control is therefore the mechanism that converts a secret from durable privilege into time-bounded access.

Practical implication: set lifecycle rules so every credential has a known expiry, ownership path, and revocation trigger.

Policy-based access and auditability for machine identity

Secrets management becomes governable only when access is policy-driven and fully auditable. Policy-based access means the system decides who or what can retrieve a secret based on identity, context, and conditions, rather than shared vault access or manual handoff. Auditability matters because machine access is often invisible until something breaks. Audit logs, entitlement checks, and access reviews provide evidence that a secret was accessed for a specific purpose and within a defined scope. Without those controls, the organisation cannot tell normal machine use from abuse.

Practical implication: require policy checks and logging for every secret retrieval so machine identity access can be reviewed like any other privileged activity.

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

Secrets sprawl is a governance failure before it is a tooling problem. The article describes a world where credentials live in repositories, pipelines, and cloud services at the same time, which means the organisation has already lost containment at creation. That is the failure mode OWASP NHI work is trying to surface. Practitioners should read this as an identity distribution problem, not a vault selection exercise.

Standing credential exposure window: the control gap that matters most. The strongest breach condition in this topic is not simply that a secret was exposed, but that it remained valid long enough to be used. That is the assumption break secrets programmes still miss: discovery is treated as sufficient, while revocation is delayed or incomplete. Under NIST CSF and OWASP NHI framing, the practical question is whether the organisation can shorten validity faster than attackers can operationalise it.

Machine identity governance must treat secrets as living access rights. Password-era thinking still dominates many programmes, but application credentials behave more like privileged entitlements than user passwords. That means lifecycle, ownership, and audit evidence matter more than storage location. NHI teams that separate secrets management from IAM and PAM are preserving an outdated boundary, and that boundary is where exposure persists.

CI/CD is now a primary secret propagation channel, not just a delivery mechanism. The article makes clear that automation increases both speed and spread, which means the pipeline is part of the identity surface. This aligns with the broader NHI governance view that build systems, runners, and deployment tooling all need identity oversight. Practitioners should treat pipeline access as privileged machine access, not DevOps plumbing.

Secrets management is converging with Zero Trust access patterns for non-human identity. The meaningful shift is away from shared vault trust and toward per-request, policy-governed retrieval with traceable outcomes. That moves secrets governance closer to access governance, where the control objective is not merely storage security but constrained use. Teams that understand this will redesign around access intent, not just credential location.

From our research:

• 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, 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.
• The Guide to the Secret Sprawl Challenge helps teams move from discovery to containment when hardcoded credentials keep reappearing in code and pipelines.

What this signals

Secret sprawl is becoming an access governance problem, not just a leak-detection problem. Once credentials appear in repositories, chat tools, and build systems, the organisation no longer owns a single authoritative secret record. That means the next phase for practitioners is tighter coupling between secrets discovery, entitlement review, and revocation execution across the full identity stack.

64% of valid secrets leaked in 2022 are still valid and exploitable today, which shows why remediation speed is now a core control metric. Teams should measure not just how many secrets they find, but how many remain live after discovery, because live exposure determines actual blast radius. For deeper incident patterns, the 52 NHI Breaches Analysis remains the best internal reference point.

Policy-based retrieval will matter more as automation expands. CI/CD systems, AI services, and service accounts all generate retrieval demand at machine speed, which means static approval models will keep failing under load. Practitioners should expect secrets governance to converge with Zero Trust access decisions and short-lived credential models as standard operating practice.

For practitioners

• Inventory every secret location Build a complete map of where credentials appear in repositories, CI/CD jobs, tickets, chat, build artifacts, and runtime configs. Prioritise the places where secrets are copied outside approved vaults, because those locations create the largest uncontrolled exposure surface.
• Shorten validity windows for all application secrets Assign explicit owners, expiry rules, and revocation triggers to each credential type so exposure does not equal persistent access. Focus first on long-lived API keys, service account passwords, and certificates that can survive beyond the system or workflow that created them.
• Treat CI/CD as a privileged access domain Apply stricter controls to pipeline identities, runners, and deployment jobs than to ordinary operational tooling. Require policy checks before secret retrieval, and review pipeline entitlements as part of privileged access management.
• Centralise retrieval and logging, not just storage Use a single control plane for secret access decisions so retrieval is logged, attributable, and tied to a policy outcome. Storage alone does not solve secret sprawl if teams can still bypass the control path with copied credentials.

Key takeaways

• Secrets management is now a control problem for machine identity, not merely a storage problem for credentials.
• The scale of exposure shows that discovery without revocation leaves valid access in place long after a leak is found.
• Practitioners should govern secrets like live entitlements, with expiry, policy checks, and audit trails built into access flows.

Key terms

• Secrets Sprawl: Secrets sprawl is the uncontrolled spread of credentials across code, pipelines, tickets, chat, and runtime systems. It becomes a governance issue when no single control plane can tell where a secret exists, who can use it, or when it stops being valid.
• Standing Credential Exposure Window: The standing credential exposure window is the period during which a leaked secret remains usable. In practice, the risk is defined by how long the secret survives after discovery and whether revocation reaches every place the credential was copied.
• Policy-Based Secret Retrieval: Policy-based secret retrieval is the practice of allowing a system or user to fetch a credential only when identity, context, and rules permit it. It replaces shared vault access with decisioned access, making secret use auditable and easier to constrain.
• Machine Identity Lifecycle: Machine identity lifecycle is the full governance path for non-human credentials from issuance to expiry and revocation. It covers creation, rotation, validation, retirement, and offboarding, and it matters because non-human access often persists long after the service it supports changes.

Deepen your knowledge

Secrets sprawl, rotation, and machine identity governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a secrets programme that has to work across CI/CD, cloud, and legacy systems, it is worth exploring.

This post draws on content published by StrongDM: What Is Secrets Management? Best Practices for 2026. Read the original.