Notifications
Clear all
Topic starter
25/06/2026 1:15 am
TL;DR: Shared secrets for machines outnumber human secrets by 20 to 45 times, and the article argues that secret sprawl persists because applications still authenticate with long-lived credentials stored in code, files, and CI/CD systems, according to Defakto Security. The governance shift is from rotating secrets more often to removing shared secrets from the operating model entirely.
NHIMG editorial — based on content published by Defakto Security: Identity Secret Sprawl: Understand It To Reduce Your Risk
By the numbers:
- Today’s companies manage 20-45 times more shared secrets for machines than they do for humans.
- Half of the organizations surveyed by the ESG expect their total number to increase by more than 20% over the next 12 months.
Questions worth separating out
Q: What breaks when shared secrets are copied across development and production systems?
A: Governance breaks first.
Q: Why do shared machine secrets increase breach risk so much?
A: Because the secret itself becomes the proof of identity.
Q: How do security teams know when secret sprawl is becoming unmanageable?
A: When they cannot confidently answer where each secret exists, which workloads depend on it, and how quickly it can be retired without breaking business services.
Practitioner guidance
- Inventory every shared machine secret Scan code repositories, CI/CD pipelines, developer workstations, configuration stores, and monitoring jobs to locate every copy of each credential.
- Rank secrets by blast radius, not by age Prioritise credentials that unlock production data, administrative control, or third-party integrations.
- Replace reusable secrets with workload identity where feasible For new services and high-value integrations, move toward verifiable workload identity so the application proves who it is without relying on a copied shared secret.
What's in the full article
Defakto Security's full article covers the operational detail this post intentionally leaves for the source:
- Examples of where shared secrets typically accumulate across development, staging, production, and CI/CD.
- Step-by-step ways to estimate secret sprawl in an enterprise application estate.
- Operational guidance on choosing between secrets managers and identity-first approaches.
- The Snowflake case discussion and the article's view on why shared responsibility still leaves customers exposed.
👉 Read Defakto Security's analysis of identity secret sprawl and NHI risk →
Identity secret sprawl: what IAM teams need to fix first?
Explore further
25/06/2026 10:32 am
Shared secret sprawl is really identity sprawl without governance. Once a credential is copied into multiple files, environments, and tools, the organisation no longer governs one secret. It is governing an unknown number of live replicas, each with different exposure and owner assumptions. That is why secret sprawl is an identity lifecycle problem, not a storage problem. Practitioners need to treat every duplicate as a separate governance event, because the risk is created by distribution, not only by disclosure.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which shows how quickly hidden NHI dependencies outgrow manual governance.
A question worth separating out:
Q: Should organisations replace shared secrets with workload identity?
A: Yes, where the environment and platform support it. Shared secrets create copy risk and lifecycle uncertainty, while workload identity reduces reliance on reusable credential material. The right goal is to remove standing shared secrets from the most critical systems first, then expand the model as platforms mature.
👉 Read our full editorial: Identity secret sprawl is exposing NHI governance gaps
