TL;DR: Distributed applications now rely on growing numbers of credentials, API keys, and certificates, and Entro Security argues that embedded secrets and config-file storage are no longer adequate for modern secrets management. The real issue is that secrets governance still assumes centralized control can keep pace with sprawl, ownership gaps, and operational rotation work that most programmes cannot sustain.
At a glance
What this is: This is a comparison of HashiCorp Vault and Akeyless SaaS secrets management that concludes modern secrets governance is really an NHI lifecycle problem, not just a storage choice.
Why it matters: It matters because IAM and NHI teams have to govern where secrets live, who owns them, how they rotate, and how they are discovered across distributed systems.
Context
Distributed applications now rely on a broad set of credentials, API keys, tokens, and certificates, which turns secrets management into an identity governance problem as much as a storage problem. When those secrets are copied into code, config files, and CI/CD tooling, the control boundary moves away from a central vault and into the operational fabric of the application.
The real challenge is not whether a team can store a secret. It is whether that secret can be owned, rotated, audited, and retired across the full NHI lifecycle without breaking delivery pipelines or creating unmanaged access paths. That is the governance gap this comparison is really describing.
The article positions the choice between vault and SaaS architectures as a question of operating model, not just feature set. For identity teams, the central issue is which model can sustain secrets visibility and lifecycle control as environments become more distributed.
Key questions
Q: What breaks when secrets are stored in code or config files instead of a governed manager?
A: Secrets stored in code or config files are hard to inventory, rotate, and revoke consistently. They spread across repos, pipelines, and runtime systems, which creates shadow copies and stale access paths. The result is a governance gap: the secret may be known to the organisation, but it is no longer controlled as a managed identity asset.
Q: Why do distributed applications make secrets governance harder?
A: Distributed applications multiply the number of places a secret can appear and the number of systems that depend on it. That creates coordination risk, because one team’s deployment change can break another team’s access path. Governance has to cover ownership, lifecycle timing, and dependency mapping, not just storage and encryption.
Q: How do organisations know if secrets management is actually working?
A: Secrets management is working only when credentials are absent from endpoints, build logs, environment variables, and source-controlled configuration. If secret scanners still find high-value tokens in routine developer paths, the control is not operating as designed, regardless of policy statements or vault adoption.
Q: What is the difference between centralised vaulting and lifecycle governance?
A: Centralised vaulting is about where secrets are stored. Lifecycle governance is about how they are issued, used, rotated, revoked, and retired across the full identity estate. A team can have a vault and still fail governance if ownership and retirement processes do not cover every copy of the secret.
Technical breakdown
Why embedded secrets fail in distributed application architectures
Embedding secrets in source code or config files creates long-lived exposure because those locations are replicated, cached, and shared across build and deployment systems. In NHI terms, the secret is no longer attached to a governed identity lifecycle. It becomes a portable credential that can outlive its intended use and escape the original owner’s control. Vaulting can centralise storage, but it does not by itself eliminate every copy or reference created by developers, pipelines, or integration tooling. The security problem is therefore not simply storage location. It is the mismatch between how application teams move credentials and how governance teams expect those credentials to be controlled.
Practical implication: treat embedded secrets as lifecycle failures, not just storage mistakes, and inventory where application teams actually place them.
What dynamic secrets do and why they still create governance friction
Dynamic secrets generate credentials on demand and reduce the window in which a reusable secret can be abused. That is useful, but the article also points out a practical problem: simultaneous access and operational coordination can become difficult when multiple NHIs need the same secret pattern at once. This is the classic tension between short-lived credentials and application reliability. The tighter the TTL and issuance logic, the more the environment depends on clean ownership, predictable service behavior, and accurate dependency mapping. Dynamic issuance narrows exposure, but it does not remove the need for clear identity relationships or consistent rotation orchestration.
Practical implication: validate where dynamic issuance may break shared service workflows before expanding it across production systems.
How SaaS secrets platforms change the control model
A SaaS secrets platform shifts operational burden away from infrastructure management and toward policy and integration control. That can simplify deployment, but it also changes the trust boundary because the programme is now depending on an external service to orchestrate issuance, rotation, and access visibility. For NHI governance, the relevant question is not whether the platform is cloud-native. It is whether the organisation still has authoritative inventory, revocation, auditability, and ownership over every credential that the platform touches. In that sense, the architecture changes the place where control lives, not the need for control itself.
Practical implication: reassess trust boundaries, audit ownership, and revocation authority before moving secrets governance into SaaS.
Threat narrative
Attacker objective: The attacker’s objective is to obtain reusable application credentials that can be used for unauthorized access, persistence, or lateral movement across connected systems.
- Entry occurs when secrets are embedded in code, config files, or CI/CD systems outside the secrets manager, creating multiple unintended exposure points.
- Credential abuse follows when those secrets are reused across services or left unrotated, allowing access to persist beyond the original operational need.
- Impact comes from uncontrolled exposure of application data and infrastructure access, especially where no one can trace who owns the secret or when it was last changed.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Secrets management is now a governance problem, not a storage problem. The article’s core point is that distributed applications generate more credential surfaces than legacy vault assumptions were designed to handle. Once secrets are spread across code, pipelines, and cloud services, ownership and lifecycle control matter more than where the secret started. The practitioner conclusion is that secrets programmes must be judged by operational control coverage, not by whether a vault exists.
Long-lived secret sprawl is the real failure mode. Centralisation can reduce fragmentation, but it does not automatically solve duplication, shadow copies, or stale credentials that survive in adjacent tools. The governance assumption that a central manager can see and control every credential is often false in modern delivery environments. The implication is that teams need a precise inventory and retirement model for every secret path, not just a storage policy.
Distributed deployment changes the control boundary. A SaaS model may reduce infrastructure overhead, but it also relocates authority over issuance and orchestration into a vendor-operated plane. That can streamline operations, yet it also makes trust boundaries more explicit and more important. Practitioners should evaluate where accountability sits for issuance, audit trails, and revocation before treating SaaS as a governance shortcut.
Secrets and non-human identities should be governed together. The article repeatedly links secrets to NHI management, which reflects the real operational relationship: credentials are only useful when attached to services, workloads, or integrations. Treating secrets as isolated artefacts misses the identity relationship that gives them meaning. The practitioner implication is to align secrets inventory, ownership, and rotation with the NHI lifecycle rather than with infrastructure silos.
Hybrid estates require a control model that follows the credential, not the platform. The article’s comparison shows that on-premises, IaaS, and SaaS options change the deployment shape, but not the governance requirement. Secrets move across these environments faster than policy does. The right question for teams is which control plane can consistently discover, classify, and retire credentials across the full application estate.
From our research library:
- 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.
- Read next: Secrets Management Guide
What this signals
Secret sprawl is the governance signal, not the storage tier. Teams should expect the operational boundary to remain messy even after adopting a vault or SaaS platform, because the hard part is still discovery, ownership, and retirement across many delivery systems. Guide to the Secret Sprawl Challenge is the right lens for that problem.
Credential control has to follow the NHI lifecycle. If the same application secret appears in source control, CI/CD, and runtime automation, then inventory alone is not enough. The programme has to know where each secret lives, who can touch it, and when it can be safely removed.
96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools. That scale explains why vault choice alone rarely changes exposure on its own.
For practitioners
- Inventory every non-human credential path Map where credentials, API keys, and certificates are stored, copied, and consumed across code, config files, CI/CD, and runtime systems.
- Separate storage control from lifecycle control Define who owns issuance, rotation, revocation, and retirement for each secret so a vault decision does not mask governance gaps.
- Test dynamic secret workflows for shared access pressure Check whether short-lived credentials create conflicts when multiple services or NHIs need the same access pattern at the same time.
- Revalidate trust boundaries before moving to SaaS Confirm where audit logs, revocation authority, and identity ownership sit when a third-party platform orchestrates secrets operations.
Key takeaways
- Secrets management is no longer just about secure storage, because the real control gap is how credentials are governed across distributed application lifecycles.
- Centralised tools can reduce fragmentation, but ownership, rotation, and revocation still fail when secrets appear in code, config files, and CI/CD systems.
- The strongest programmes tie secrets inventory to NHI lifecycle control, so every credential has an owner, a location, and a retirement path.
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 centres on secrets living in code, config files, and CI/CD tools outside governed storage. |
| NHI-07 — Long-Lived Secrets | Rotation and short-lived credential management are central to the comparison between vault and SaaS models. | |
| NHI-05 — Overprivileged NHI | The article ties secrets governance to the access those credentials confer across distributed systems. | |
| Recommendation — Scan and remove secrets from source, config, and pipeline locations, then route them into governed storage. Shorten credential lifetime and enforce rotation where reusable secrets still exist in production paths. Restrict secret scope to the minimum access each NHI actually needs and revoke excess entitlements. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Secret issuance, storage, rotation, and revocation map directly to authenticator lifecycle control. |
| Recommendation — Apply authenticator management controls to rotate, revoke, and retire machine secrets on a defined schedule. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about controlling which identities can use which secrets and for how long. |
| Recommendation — Review entitlements tied to secrets and remove any standing access that is not operationally required. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | Leaked or reused secrets enable credential access and downstream movement across connected systems. |
| Recommendation — Map exposed secret paths to credential access and lateral movement risk in your detection and response plans. | ||
Key terms
- 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.
- Dynamic Secret: A secret generated on-demand for a specific task and automatically revoked after use or expiry. Dynamic secrets dramatically reduce the risk of credential exposure compared to static, long-lived secrets and are considered best practice.
- Lifecycle Governance: Lifecycle governance is the set of controls that cover creation, assignment, review, rotation, and retirement of identities and credentials. For NHIs, it is the difference between a temporary automation asset and a persistent access risk. Strong lifecycle governance keeps ownership and expiry tied to actual business use.
- Vaultless Secrets Management: Vaultless secrets management stores credentials closer to the applications that use them instead of placing everything in a central vault. It can reduce operational friction, but it also pushes more security responsibility into application teams and makes consistent governance harder to sustain.
Deepen your knowledge
NHI governance, secrets management, and workload identity security 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