TL;DR: Secrets vault choice is less about storage and more about onboarding speed, access scope, rotation, versioning, and scale, according to Pangea. The governance issue is that secrets handling often fails at lifecycle control, not at encryption alone, so teams need to evaluate operational fit before migration.
At a glance
What this is: This is a vault comparison focused on app secrets, keys, onboarding, rotation, versioning, integrations, and scaling limits.
Why it matters: It matters because IAM and NHI teams need to evaluate whether a secrets platform governs lifecycle and access boundaries, not just encryption at rest.
Context
Secrets vaults are not just storage systems for credentials, keys, and tokens. The governance problem is whether the platform can support secure onboarding, scoped access, rotation, version history, and operational scale without creating new management burden.
For teams replacing .env files and ad hoc secret handling, the real decision is about lifecycle control for non-human identity material. A vault that cannot manage access boundaries or rotate secrets cleanly may reduce clutter while leaving the underlying exposure problem unresolved.
This comparison is a practical fit for workload identity and secrets governance because the article evaluates how each platform handles migration, access restriction, scaling cost, and key management across application environments.
Key questions
Q: What breaks when a secrets vault gives broad access to every invited team member?
A: Least privilege breaks first, followed by accountability and blast-radius control. If every invited user can see all application secrets, one compromised account or one careless workflow can expose unrelated services, environments, and deployment paths at the same time.
Q: When should teams prioritise rotation over versioning in a secrets vault?
A: Prioritise rotation when exposure reduction is the immediate goal, but do not ignore versioning because rollback support determines whether updates remain operable. In practice, teams need both controls together for production secrets. Rotation reduces dwell time, while versioning preserves recovery options after a bad secret update.
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. If the environment still depends on stored tokens for routine workload access, the programme is managing exposure, not removing it.
Q: Should organisations use a managed vault or self-hosted vault for app secrets?
A: Choose based on governance capacity, scale expectations, and the need for key management as well as secret storage. Managed platforms may reduce infrastructure burden, while self-hosted options may give more control, but neither is automatically secure unless access, rotation, and integration boundaries are clearly enforced.
Technical breakdown
Secrets vault onboarding and migration speed
Vault migration is not only a storage move. Engineers have to move application secrets, update deployment paths, and ensure every runtime still receives the right secret at the right time. A vault with import tooling, CLI support, and broad platform integrations reduces operational friction, while a vault without migration assistance turns adoption into a manual remediation project. The key technical issue is whether the vault becomes the system of record for secret issuance and retrieval, or just another location where credentials sit unused until someone remembers to wire them in.
Practical implication: assess whether migration can happen without manual secret re-entry across every deployment pipeline.
Rotation, versioning and secret lifecycle control
Rotation changes a secret’s value on a schedule or trigger, while versioning preserves prior secret states for rollback and recovery. These are separate controls. Rotation limits exposure after compromise, and versioning supports continuity when an update breaks an application. A vault that offers one without the other may create operational instability or leave stale credentials usable longer than intended. For NHI governance, the important question is whether lifecycle controls are native to the platform or left to surrounding scripts and human discipline.
Practical implication: verify that rotation and rollback are both supported before moving production secrets.
Scale, access scope and runtime integrations
A secrets vault must serve many environments without turning access into a broad, all-or-nothing entitlement. If every invited team member sees every application secret, the vault centralises risk rather than reducing it. Runtime integrations matter because applications, CI pipelines, and deployment tools need machine-readable access paths that do not force manual secret handling. From a governance perspective, the issue is whether the platform can express least privilege at the application or project level while still supporting the places where the secret is actually consumed.
Practical implication: test whether access can be scoped per application or project before adopting a shared vault model.
Threat narrative
Attacker objective: The attacker wants reusable credentials that unlock application and infrastructure access beyond the original intended scope.
- Entry occurs when application secrets are left in .env files, shared vaults, or broadly exposed deployment paths rather than governed secret stores.
- Privilege escalation follows when invited users or integrated platforms inherit access to more secrets than their role requires, widening the blast radius.
- Impact occurs when exposed or stale secrets are reused across environments, allowing unauthorised access to applications, databases, or infrastructure.
Breaches seen in the wild
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Secrets vault choice is a lifecycle decision, not a storage decision: The article shows that the useful comparison is not where secrets sit, but whether the vault can govern access, rotation, versioning, and scale across application environments. That is an NHI lifecycle problem because secrets are only secure if issuance, retrieval, and revocation all remain controlled. Practitioners should treat vault selection as a governance design choice, not a repository purchase.
Access scope is the fault line that separates centralisation from control: The article’s strongest warning is that some vault models expose all secrets to all invited users unless access is restructured by project or plan. That means the platform can reduce sprawl while still leaving overbroad entitlements intact. In NHI terms, central storage without scoped authorization is an organisational convenience, not a security boundary. Practitioners should test entitlement granularity before they migrate production secrets.
Rotation without versioning creates operational debt, while versioning without rotation preserves risk: These controls serve different purposes and should not be treated as substitutes. A vault that cannot rotate effectively extends exposure windows, while a vault that cannot preserve prior versions makes recovery harder after a bad update. The article correctly frames the trade-off as a governance and resilience question, not a feature checklist. Practitioners should evaluate secret lifecycle continuity end to end.
Scale changes the security model because entitlement drift grows with the application estate: The more apps, runtimes, and teams a vault supports, the more important it becomes to automate access boundaries and avoid seat-based or all-secrets access patterns. What looks manageable in a small project can become privilege creep at enterprise scale. The practical conclusion is that vault architecture has to match the rate at which applications, teams, and deployment surfaces expand.
Secret management is now part of the identity perimeter: Modern application security depends on how secrets are provisioned into runtimes, not just on encryption strength. That makes secrets vaults an identity control surface for workloads and developer workflows. Practitioners should align vault evaluation with NHI governance, because the question is who or what can use a secret, for how long, and under which operational constraints.
From our research library:
- Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
- 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Scoped secret access is becoming the real differentiator: When every invited user can see every application secret, the vault solves storage but not governance. Teams should treat access granularity as the first adoption gate because secret centralisation without entitlement boundaries simply moves the sprawl into one place.
Rotation and versioning need to be evaluated as a pair: Vault programmes fail when they optimise for changing the credential value but ignore rollback and operational continuity. The practical shift is toward lifecycle-aware secret governance, where the platform must support both removal of exposure and recovery from failed updates.
A vault strategy should now be assessed alongside workload identity and deployment design, not in isolation. Secrets are part of the runtime trust model, so the question is whether the platform can keep pace with applications, environments, and the rate of change in the estate.
For practitioners
- Define access scope before migration Map which applications, environments, and teams should see each secret set, then validate that the vault can enforce that boundary without exposing everything to every invited user.
- Test rotation and rollback together Confirm that periodic rotation is paired with secret versioning so application failures can be rolled back without leaving old credentials permanently active.
- Model vault scale against operating cost Estimate how onboarding effort, pricing, and administration change as secrets, teams, and integrations grow, especially where the free tier or seat model creates pressure to over-share.
- Check runtime integrations for each deployment path Verify that the vault can inject secrets into application runtimes, CI pipelines, and deployment tooling without forcing manual copy-paste or local files.
- Separate key management from secret storage Confirm whether the platform supports cryptographic key lifecycle needs such as rotation and algorithm support, or whether a separate key management approach is still required.
Key takeaways
- Secrets vaults become useful only when they control access scope, secret lifecycle, and operational scale together.
- The article’s comparison shows that managed and self-hosted options differ less on storage than on governance burden and entitlement granularity.
- Teams should evaluate rotation, versioning, integrations, and growth cost before treating a vault migration as a security fix.
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 addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 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 is about preventing exposed application secrets from becoming reusable access paths. |
| NHI-05 — Overprivileged NHI | The access-scope discussion centers on overly broad secret visibility for users and integrations. | |
| NHI-07 — Long-Lived Secrets | Rotation is a core evaluation criterion because stale secrets extend exposure windows. | |
| Recommendation — Scan vault workflows and deployment paths for secret leakage and revoke exposed credentials immediately. Constrain secret access so each workload or team only sees the credentials it actually needs. Use short-lived secret policies and verify rotation cadence against production usage. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article’s main governance issue is whether the vault can enforce scoped entitlements. |
| Recommendation — Define and enforce least-privilege secret entitlements across applications and deployment environments. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Secret rotation and lifecycle handling map directly to authenticator management. |
| Recommendation — Apply authenticator management controls to rotate and retire application secrets on schedule. | ||
Key terms
- Secrets Vault: A centralised, encrypted store for managing secrets such as API keys, passwords, certificates, and tokens. Examples include HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and Akeyless.
- 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.
- Secret Versioning: Secret versioning is the ability to retain previous credential states after an update or rotation. It is useful for rollback and troubleshooting, but it also creates governance requirements for who can see historical values and when older versions are purged.
- Runtime Secret Injection: A pattern that retrieves credentials only when a process starts, rather than storing them in files or source control. For AI developer tools, it reduces secret persistence, limits accidental disclosure, and keeps the credential tied to a specific execution session.
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 August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org