Secrets Management in 2026: Sprawl, Non-Human Identities, and the Vault vs Workload Identity Decision

Every engineering org has a secrets management policy on paper. Most of them are losing ground anyway. GitGuardian's fifth annual scan of public GitHub found 28.6 million new secrets exposed in 2025, up 34% year over year - and that count only covers what leaked publicly, not what sits misconfigured in private repos, CI logs, and container layers (GitGuardian, State of Secrets Sprawl 2026). For engineering directors at regulated Benelux organisations, the question is no longer "do we have a secrets scanner" - it's whether the architecture still depends on long-lived static secrets at all, or whether it has moved to something that can't leak the same way.

A data center server rack with cabling and network switches, the kind of infrastructure where API keys, tokens and credentials live and, if leaked, are exploited. — Photo: Tony Webster, CC BY 2.0, via Wikimedia Commons

Why is secrets sprawl still getting worse?

The intuitive answer is "more repos, more code" - but the sharper driver is AI-assisted development changing how fast credentials get written down. GitGuardian's 2026 report tracked AI-service secrets - API keys for Copilot, Claude, and similar tools - growing 81% year over year to 1.27 million exposed keys, and found that commits co-authored by AI coding assistants leak secrets at roughly twice the baseline rate of ordinary commits (GitGuardian, 2026). The mechanism is not mysterious: an assistant scaffolds a working integration fast, a developer pastes a real key to test it, and the commit ships before anyone remembers to move it into a vault. Volume of change has always been the enemy of credential hygiene; AI just raised the volume without raising the discipline to match.

How long do leaked secrets actually stay dangerous?

Longer than most incident response plans assume. Of the secrets GitGuardian first detected in 2022, 64% were still valid and exploitable four years later (GitGuardian, 2026). That statistic is the real argument against static, long-lived credentials: a leak is not a point-in-time incident with a bounded blast radius, it's an open door that stays open until someone actively finds and closes it - which for most organisations never fully happens, because nobody owns the inventory of what's already out there. This is also why "we scan for secrets in CI" is necessary but not sufficient. Scanning catches new leaks going forward; it does nothing for the years of history already sitting in git logs, Slack exports, and old container images.

What role do stolen credentials actually play in breaches?

A large one, and a fairly stable one. Verizon's 2025 Data Breach Investigations Report found compromised credentials were the initial access vector in 22% of breaches analysed - one of the top entry points, alongside vulnerability exploitation and phishing (Verizon, 2025 DBIR research). That figure covers human logins and stolen API/service credentials alike, which matters for a simple reason: most organisations invest heavily in protecting human passwords (MFA, SSO, conditional access) while treating machine credentials - the API keys, database connection strings, and service tokens that outnumber human accounts by a wide margin in any modern cloud estate - as an afterthought. OWASP's Non-Human Identities project makes the same point structurally: in its 2025 top-10 list, secret leakage is rated a severe-impact risk precisely because leaked secrets "tend to hold credentials for high-impact NHI," with 31% of NHI-related incidents traced to poor secrets management and 37% of organisations still storing secrets in environment variables or hardcoded in application code (OWASP NHI Top 10, 2025).

Where do credentials actually leak in the pipeline?

OWASP's CI/CD Top 10 names this specifically as CICD-SEC-6, Insufficient Credential Hygiene, and lists the failure modes in an order that will be familiar to anyone who has run an incident retro: credentials committed to source control that persist in history even after deletion; pipeline credentials scoped far wider than the job that uses them; build-time secrets left behind in container image layers; secrets printed to console output "deliberately or inadvertently"; and credentials that go unrotated for years, quietly expanding who and what can use them (OWASP Top 10 CI/CD Security Risks, CICD-SEC-6). Every one of these is a process gap, not a tooling gap - which is exactly why buying a secret scanner without changing the underlying architecture only catches the symptom.

Vaulted rotation or workload identity: which is the 2026 answer?

Two credible architectures compete for "how should services authenticate to each other," and the honest answer is that most regulated organisations need both, applied in the right place.

Vaulted rotation - HashiCorp Vault or a cloud-native equivalent (AWS Secrets Manager, Azure Key Vault, Google Secret Manager) centralises secret storage, encrypts at rest, and can issue dynamic, short-lived credentials instead of static ones - a database password minted per session rather than shared forever. Kubernetes-native tooling like External Secrets Operator syncs those values into cluster secrets on a schedule, so the credential in etcd is never the long-lived source of truth. This is the right model wherever a genuine secret has to exist - a third-party API key, a legacy system that only accepts a password.
Workload identity federation - increasingly the preferred answer wherever it's available. Instead of distributing a static credential at all, a workload proves who it is via a short-lived, cryptographically verifiable identity (OIDC token, SPIFFE/SPIRE identity, cloud-native workload identity) and exchanges that for temporary access on demand. There is no standing secret to leak in the first place, because the credential that would normally sit in a config file or environment variable never exists as a static artifact. CI/CD pipelines authenticating to cloud providers via OIDC instead of long-lived access keys are the clearest, now-mainstream example.

The decision test that holds up under audit: for every credential in the estate, ask whether it can be replaced with a federated identity exchange. Where the answer is yes - CI/CD to cloud, service to service within a mesh, workload to cloud secret store - move to workload identity and eliminate the standing secret entirely. Where the answer is no - a SaaS vendor that only supports API keys, a database that only does password auth - put it in a vault, issue it dynamically, rotate it aggressively, and scope it to least privilege. What should never survive into 2026 is the default the OWASP and GitGuardian data describes: a static, broadly-scoped, rarely-rotated secret sitting in an environment variable because nobody revisited the decision after it shipped.

What this means for regulated Benelux teams

Under DORA, NIS2, and internal audit regimes that increasingly ask for evidence rather than policy statements, "we have a secrets policy" is not an answer an auditor accepts if the estate still runs on unrotated static keys. The practical checklist: inventory every static secret and its age; push CI/CD to OIDC-based workload identity wherever the provider supports it; put everything that must remain a static secret behind a vault with automatic rotation and least-privilege scoping; and treat "we found a leaked secret in a scan" as a revocation event, not a ticket - because the GitGuardian data says the credential you don't rotate today has a real chance of still being valid, and exploitable, four years from now.