Topic starter
13/10/2026 1:21 pm
TL;DR: Akeyless says secrets scattered across cloud platforms, CI/CD tools, scripts, and configuration files keep creating attacker paths, and more than one in three breaches over the last 10 years can be linked to stolen credentials. The practical lesson is that storage alone is not governance; the control boundary has to shift to centralised policy, access windows, and rotation.
Editorial analysis by NHI Mgmt Group, based on content published by Akeyless: “Best Practices For Managing Secrets Across Multiple Environments”.
By the numbers:
- More than one in three breaches over the last 10 years can be linked to stolen credentials.
Key questions
Q: What breaks when secrets are stored in code and CI/CD tools?
A: Access becomes invisible, reusable, and hard to revoke, which means the organisation loses control of where authentication material exists.
Q: Why do stolen credentials remain such an effective attack path?
A: Stolen credentials work because many systems still treat a successful login as enough evidence of legitimacy.
Q: How do security teams know whether secret management is actually reducing risk?
A: Look for fewer reusable credentials, shorter credential lifetimes, and a lower number of systems that still depend on manually rotated secrets.
Practitioner guidance
- Centralise secrets discovery Map where secrets actually live across code repositories, CI/CD systems, configuration stores, cloud vaults, and runtime variables before changing tooling.
- Replace standing credentials with time-bound issuance Use short-lived secrets and just-in-time access for workloads and administrative tasks so a credential cannot be replayed for long after issuance.
- Enforce rotation and expiry policies Automate rotation for static passwords, API keys, and certificates, and set clear expiry thresholds for any credential that cannot be made dynamic.
Bottom line: Secrets management fails when credentials are allowed to sprawl across code, CI/CD, and multiple cloud environments without a single governance view.
What's in the full article
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- Specific comparisons between cloud-native managers, traditional vaulting, and SaaS-native managers for multi-environment deployments
- Tactical guidance on how to centralise policy while preserving developer usability in CI/CD-heavy workflows
- Operational considerations for automated rotation, dynamic secrets, and just-in-time access across multiple clouds
- Evaluation questions for deciding whether a secrets platform requires agents, custom scripts, or managed infrastructure
👉 Read Akeyless's analysis of secrets sprawl and cloud secrets management →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
13/10/2026 1:22 pm
Secrets sprawl is a governance failure, not just a storage problem: once credentials exist in code, CI/CD variables, config files, and per-cloud vaults, the organisation no longer has one control plane for non-human identity. Central policy can only govern what it can find, so discovery becomes the prerequisite for any meaningful lifecycle control. The practitioner conclusion is that inventory and governance must precede vault selection.
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 the Ultimate Guide to NHIs.
A question worth separating out:
Q: Should teams prioritise rotation or centralisation first?
A: Centralisation usually comes first because teams cannot govern what they cannot inventory. But rotation becomes the risk-reduction lever once secrets are visible, because long-lived credentials remain useful to attackers even inside a well-managed vault. The right sequence is discover, centralise, then shorten lifetime.
👉 Read our full editorial: Secrets sprawl in multi-cloud environments widens credential risk