Topic starter
06/06/2026 11:12 am
TL;DR: Secrets managers centralize API keys, passwords, and tokens, but they do not remove the bootstrap and post-delivery risks that keep credential abuse in play, according to Aembit’s analysis, which cites GitGuardian’s roughly 29 million secrets detected on public GitHub in 2025 and Verizon’s finding that credential abuse drove 22 percent of breaches. The practical shift is toward workload IAM for systems that can authenticate with identity instead of persistent secrets, while vaults remain necessary for legacy dependencies.
Editorial analysis by NHI Mgmt Group, based on content published by Aembit: “Workload IAM vs. Secrets Management: A Practical Decision Guide”.
By the numbers:
- GitGuardian’s 2026 report found roughly 29 million secrets detected on public GitHub in 2025 alone, a 34 percent year-over-year increase.
- The 2025 Verizon DBIR cited credential abuse as the initial attack vector in 22 percent of breaches.
Key questions
Q: What breaks when teams rely on secrets managers as the whole access model for workloads?
A: Secrets managers still protect stored material, but they do not remove the need for bootstrap trust or prevent post-delivery reuse.
Q: When should organisations prioritise workload IAM over vault expansion?
A: Prioritise workload IAM when the same access pattern must work across clouds, SaaS integrations, and on-premises systems.
Q: How do security teams know whether their secrets programme is actually reducing risk?
A: Look at ownership, scope, rotation speed, revocation speed, and the number of places a secret is accepted.
Practitioner guidance
- Map every workload that still depends on a persistent secret Separate legacy systems that require stored credentials from cloud-native workloads that can authenticate with platform identity.
- Eliminate bootstrap secrets where federation is available Replace static vault access paths with platform identity, OIDC federation or managed workload identity for systems that can authenticate directly.
- Constrain remaining vault-issued credentials to the narrowest scope For systems that still need stored secrets, issue the shortest viable lifespan, bind access to specific workload identities and keep rotation automated so retrieval is tied to a governed lifecycle.
Bottom line: Secrets managers reduce the chaos of scattered credentials, but they do not eliminate bootstrap trust or post-delivery reuse risk.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
06/06/2026 11:52 am
Static credential management is a control layer, not an access model. Secrets managers are still useful where credentials must exist, but they do not answer the governance question of whether the workload should need a persistent credential at all. The important distinction is between storing a secret safely and eliminating the need for the secret in the first place. Practitioners should treat vaulting as containment, not as the endpoint of identity design.
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.
- 88% of security professionals are concerned about secrets sprawl, with 49% of those in larger organisations described as "very concerned", according to the 2024 State of Secrets Management Survey.
A question worth separating out:
Q: What is the difference between secrets management and workload identity?
A: Secrets management protects stored credentials, while workload identity governs how a workload proves who it is before any secret is issued. Both matter, but workload identity addresses the bootstrap problem that secrets managers cannot solve on their own. In practice, identity should lead and secrets storage should support it.
👉 Read our full editorial: Secrets managers vs workload IAM: where static credentials fall short
This post was modified 1 day ago by NHI Mgmt Group