TL;DR: Secrets management fails when organisations treat vaulting as the finish line: 80% of secrets still slip through the cracks, and automated rotation is needed to shrink exposure windows and support compliance, according to Entro Security. The practical issue is governance, not storage, because centralisation, rotation, monitoring, and least privilege only work when they are operationally coordinated.
At a glance
What this is: This is a secrets management strategy article showing that vaulting alone does not prevent exposure when secrets are spread across tools, code and workflows.
Why it matters: IAM and NHI teams need to treat secrets as governed runtime credentials, because rotation, access scope and monitoring determine exposure more than storage location does.
By the numbers:
- 80% of secrets slip through the cracks and go unnoticed when organisations rely on fragmented vaulting, according to Entro Security.
Context
Secrets management is the control plane for API keys, access tokens and certificates, not just the place where they are stored. When organisations rely on multiple vaults or leave credentials embedded in code, they create visibility gaps that make governance, rotation and auditability much harder than the storage problem suggests.
The article frames the real issue as operational coordination across the secrets lifecycle. That includes centralising inventory, rotating credentials without breaking dependent services, applying context-aware access controls, and monitoring usage so exposed secrets do not remain active long enough to be abused.
Key questions
Q: What breaks when organisations rely on vaults alone for secrets security?
A: Vaults help store secrets, but they do not solve visibility, governance, or exposure detection on their own. If teams assume storage equals security, secrets can still leak into code, chat, tickets, or configuration files. The control gap is operational: you still need discovery, policy enforcement, and response workflows across the full environment.
Q: Why do exposed API keys and tokens create such a high-risk failure mode in software delivery?
A: Exposed secrets matter because they often grant direct access to cloud accounts, source repositories, databases, or release pipelines. Once attackers find them, they can clone code, publish malicious packages, or move into CI/CD systems. The risk is amplified when secrets are long lived, broadly scoped, or reused across environments.
Q: How do security teams know if secret rotation is actually working?
A: Secret rotation is working only when teams can prove that each credential has an owner, an expiry path, and a tested revocation process. If rotation causes outages, leaves unknown dependencies behind, or cannot be completed quickly after exposure, the control is not operationally mature. Effective rotation reduces usable lifetime without breaking legitimate workloads.
Q: Should organisations treat NHI secrets and human credentials under the same governance model?
A: Yes, when the credential can authenticate to production systems or cloud services. The governance logic is the same: know who or what it belongs to, limit privilege, shorten lifetime, and remove it cleanly when the owner changes or the task ends. The controls differ in execution, but the lifecycle risk is shared.
Technical breakdown
Why fragmented vaulting fails as a control model
A vault is only a storage control unless it is tied to inventory, policy, and runtime usage. When secrets are spread across multiple vaults, code, and service dependencies, the organisation loses a complete view of where credentials exist and which workloads still depend on them. That creates blind spots in rotation, revocation, and access review. Centralisation helps because it makes policy enforcement and monitoring consistent, but centralisation alone does not eliminate exposure if secrets are still hard-coded or copied into unmanaged locations.
Practical implication: build a single governed inventory of secrets before you try to optimise rotation or access policy.
How automated rotation changes exposure windows
Automated rotation reduces the time a leaked secret remains valid, but it also exposes dependency problems. If multiple services use the same secret, rotation can break the first consumer that updates while others continue to rely on the old value. That means rotation is not just a timing control, it is a coordination problem across applications, deployment pipelines, and rollback paths. The control only works when secret replacement, service update, and validation happen in a controlled sequence.
Practical implication: map every downstream consumer before rotating shared secrets, or you will create outages instead of reducing risk.
Why context-aware access controls matter for secrets
Static permissions do not reflect how secret use changes across time, location, workload, and behaviour. Context-aware access controls add runtime conditions to access decisions, so unusual access can trigger extra verification or temporary lockdowns. In secrets management, that matters because a valid secret is still dangerous when used from the wrong place or at the wrong time. This is where monitoring and policy intersect: the secret may be legitimate, but the access pattern may not be.
Practical implication: pair secret issuance with behavioural checks so valid credentials are still constrained by context.
Threat narrative
Attacker objective: The attacker objective is to turn one exposed secret into broad authenticated access across connected services before the organisation notices.
- Entry occurs when secrets are hard-coded into codebases, scattered across vaults, or left in unmanaged application paths where they can be copied without detection.
- Credential access follows when exposed API keys, access tokens or certificates are discovered and reused before rotation or revocation changes their validity.
- Escalation happens when over-broad permissions let a stolen secret reach more systems or services than the original use case required.
- Impact comes from prolonged credential validity, failed auditing, and weak access scoping that allow attackers to move from one secret to wider resource access.
Breaches seen in the wild
- iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.
- OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Secret governance debt is the real problem: organisations do not fail because they lack a vault, they fail because secrets exist in too many states at once. Some are centralised, some are embedded in code, and some are still active after their intended use. The practical conclusion is that secrets management is a lifecycle discipline, not a storage decision.
Context turns secrets from static records into governed runtime credentials: a secret’s risk depends on who uses it, from where, and for what dependency chain. That makes context-rich inventory more important than isolated rotation events, because the same credential can be acceptable in one path and dangerous in another. Practitioners should treat usage metadata as part of the control, not an extra report.
Standing secret access expands identity blast radius: when multiple services can keep using the same credential indefinitely, compromise of one path becomes compromise of the entire dependency set. That is the governance flaw this article surfaces. The implication is that access scope must be narrowed at issuance, not only after exposure is discovered.
Secrets management is converging with NHI governance: API keys, tokens and certificates are now part of the same control problem as service accounts and workload identities. Once those credentials are treated as non-human identities with ownership, lifecycle and monitoring requirements, the governance model becomes more coherent. Practitioners should align secrets policy with broader NHI inventory and accountability.
Automated rotation is only useful when service dependence is mapped: the article shows that rotation without dependency awareness can break applications or leave shadow consumers on stale credentials. That is not a tool issue, it is a lifecycle design issue. The implication for teams is to govern replacement paths as carefully as the secret itself.
From our research library:
- Enterprises manage far more machine secrets than human ones: 20 times as many according to Enterprise Strategy Group, and 45 times according to GitGuardian.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Secrets management is becoming an inventory problem before it is a rotation problem: once credentials are scattered across code, vaults and pipelines, teams lose the ability to govern access consistently. That is why lifecycle ownership and dependency mapping now matter as much as vault design.
Secret sprawl debt: the hidden cost of fragmented vaulting is that organisations cannot see which applications still depend on a credential after it should have been retired. That is the control failure to watch, especially where API keys and tokens are reused across services.
Machine and human identity programmes are converging around the same question: who owns the credential, where is it used, and when does it stop being valid? Teams that answer those questions early will find secrets management far easier to govern than teams that wait for leakage.
For practitioners
- Centralise the secrets inventory Consolidate API keys, access tokens, and certificates into one governed inventory so policy, monitoring, and audit can operate on a complete view of exposure.
- Remove hard-coded secrets from code paths Scan repositories, build scripts, and deployment artefacts for embedded credentials and replace them with managed secret references before they propagate further.
- Map secret consumers before rotation Identify every application, service, and pipeline that depends on a shared secret so rotation can be sequenced without breaking runtime authentication.
- Add context-aware access checks Apply policy conditions that consider usage pattern, location, and time so legitimate secrets still face additional scrutiny when access looks abnormal.
- Audit secrets on a fixed cadence Review secret ownership, permissions, and active usage regularly so stale credentials and unnecessary privilege do not remain hidden between incidents.
Key takeaways
- Secrets management fails when vaults are treated as the endpoint rather than one control in a wider lifecycle.
- The article’s core warning is that secrets still slip through fragmented environments, hard-coded code paths and poorly coordinated rotations.
- Practitioners should prioritise central inventory, consumer mapping and context-aware access before they optimise rotation speed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article focuses on secrets leaking from code, pipelines, and fragmented vaults. |
| NHI-05 — Overprivileged NHI | The article stresses granular permissions and reduced secret blast radius. | |
| NHI-07 — Long-Lived Secrets | Automated rotation is central because long-lived credentials extend exposure windows. | |
| Recommendation — Scan and remove leaked NHI secrets from code, pipelines, and logs before they can be reused. Reduce secret scope so each credential can reach only the service it actually supports. Rotate long-lived secrets on a governed schedule and revoke stale values immediately. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential rotation and lifecycle management map directly to authenticator governance. |
| Recommendation — Apply authenticator management to rotate, revoke, and track secret lifecycle events. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Granular permissions and access scoping are core to the article’s governance model. |
| Recommendation — Review entitlements so secrets only grant the minimum access each workload needs. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article’s risk model is credential theft followed by broader service reach. |
| Recommendation — Hunt for exposed credentials and constrain the movement paths they open across services. | ||
Key terms
- Secrets Management: The discipline of securely storing, distributing, rotating, and auditing secrets across an organisation's systems and pipelines, typically implemented via a centralised secrets vault such as HashiCorp Vault, AWS Secrets Manager, or Akeyless.
- Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
- Context-Aware Access Review: A decision process that evaluates access requests using request intent, existing entitlements, resource sensitivity, and operational evidence. In identity programmes, it reduces blind approvals by forcing reviewers or automation to weigh the real circumstances behind the request, not just the ticket itself.
- Secrets Rotation: Secrets rotation is the practice of replacing credentials on a schedule or after an event so exposed values stop working quickly. In NHI programmes, rotation must be tied to ownership and automation, otherwise credentials remain valid long after teams believe the risk has been addressed.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org