TL;DR: Akeyless says traditional vault-based secrets tools struggle to scale across cloud, hybrid and on-prem environments, where enterprises still need secure storage, rotation and auditability for API keys, certificates and passwords. The central issue is governance at scale: secrets controls must support zero-standing privilege, automation and compliance without turning infrastructure into a bottleneck.
At a glance
What this is: This is an analysis of enterprise secrets management and why vault-centric models are running into scaling, operational and compliance limits as environments become more distributed.
Why it matters: It matters because IAM, PAM and NHI teams need a governance model for secrets that works across workloads, pipelines and cloud estates, not just a central repository.
👉 Read Akeyless's analysis of enterprise secrets management beyond traditional vaults
Context
Enterprise secrets management is the discipline of storing, rotating and auditing credentials such as API keys, certificates and passwords across a large environment. The governance problem is not whether a vault exists, but whether the control plane can keep pace with cloud, hybrid and on-prem workloads without creating operational drag.
The article argues that traditional vaults become difficult to scale once secrets are spread across multiple platforms, pipelines and runtime environments. That creates a familiar identity issue: secrets governance breaks when the access model is designed for static infrastructure but the workloads using those secrets are distributed and fast-moving.
The practical question for IAM, PAM and NHI teams is whether secrets controls are supporting the operating model or constraining it. In this article’s framing, enterprise secrets management has to combine access control, automation, compliance and availability rather than treat storage as the whole problem.
Key questions
Q: How should security teams govern privileged access in cloud and hybrid environments?
A: Teams should govern privileged access around runtime authorization, not just connectivity or login. That means scoping elevation to a specific task, setting an expiry, logging approvals, and revoking access automatically when work is complete. The goal is to reduce standing privilege and create evidence that can withstand incident review and audit.
Q: Why do traditional vaults become harder to govern as environments scale?
A: Because the challenge is not just secure storage. As secrets move across multiple clouds, on-prem systems and automation paths, the vault becomes a control dependency for availability, rotation speed and consistent policy enforcement.
Q: What breaks when secrets are not rotated frequently enough?
A: The attacker’s dwell time expands. A stolen API key or SSH credential can remain usable for days or months, giving adversaries time to move laterally, access cloud resources, and avoid detection. Rotation only works if it is frequent enough to outpace realistic attacker use.
Q: What is the difference between dynamic secrets and secretless access?
A: Dynamic secrets are temporary credentials that are created on demand and expire quickly, while secretless access goes further by preventing the workload from handling a usable secret at all. In practice, dynamic secrets are a transition stage, and secretless access is the state where identity-based authentication replaces secret distribution.
Technical breakdown
Why vault-centric secrets management breaks at enterprise scale
Traditional vaults centralise secret storage, but they also centralise operational dependence. In cloud-native and hybrid environments, every integration, rotation flow and runtime lookup can become a point of friction if the vault is self-managed, tightly coupled to infrastructure or hard to extend across environments. The scaling problem is therefore architectural, not just administrative: the more distributed the estate, the more the vault becomes a bottleneck for availability, rotation speed and access consistency. That is why enterprise secrets management now has to be judged on control-plane resilience as much as on storage security.
Practical implication: assess whether your current secrets platform creates a throughput or availability dependency that will slow rotation and access at scale.
How zero-standing privilege changes secrets governance
Zero-standing privilege means access is issued only when needed, then removed or expires when the task ends. In secrets management, that shifts the control point from long-lived stored credentials to ephemeral access and automated issuance. The article ties this to dynamic secrets and just-in-time access, which reduce the value of stolen credentials because the privilege window is shorter and more task-scoped. This is most effective when access policy, rotation and audit logging are connected rather than handled as separate processes.
Practical implication: map where long-lived secrets still exist in pipelines, workloads and administrative workflows, then convert those paths to time-bound access.
Secretless access for workloads and AI agents
Secretless access removes the need to distribute static credentials to systems that act on behalf of the business, including workloads and AI agents. Instead of embedding secrets into code, containers or automation flows, access is mediated through identity, policy and short-lived authorization. That matters because the more systems, bots or agents that handle secrets directly, the larger the leakage and offboarding problem becomes. For organisations adopting automated workflows, the control question is no longer just where a secret is stored, but whether it needs to be stored in the first place.
Practical implication: inventory workflows that still pass credentials directly to machines or agents and prioritise those paths for secretless redesign.
Threat narrative
Attacker objective: Gain access to customer data and reusable credentials that could be used for broader account abuse.
- Entry occurred through a compromised back-end service account that provided access to Dropbox Sign systems.
- The attacker used that account to reach customer data and secrets including API keys, OAuth tokens and MFA information.
- The impact was exposure of credentials and identity data that could support further compromise of downstream systems.
Breaches seen in the wild
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
- 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 and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Enterprise secrets governance is becoming a control-plane problem, not a storage problem. The article’s core message is that vaults can hold secrets but still fail to govern them across cloud, hybrid and on-prem estates. That shift matters because rotation, auditability and access enforcement now depend on how the control plane behaves under distribution, not on whether a vault exists at all. Practitioners should evaluate secrets platforms by lifecycle governance, not repository features.
Long-lived credentials remain the structural weakness that modern secrets programmes are trying to eliminate. Static passwords, API keys and certificates create a persistence window that attackers can exploit and operations teams struggle to police. Dynamic issuance and time-bound access reduce that window, but only if the organisation treats rotation and revocation as policy-driven controls rather than occasional maintenance tasks. The implication is that standing secrets are now a design defect, not a convenience.
Secretless access is the clearest sign that secrets management is converging with workload identity. Once applications, pipelines and AI agents can authenticate without being handed reusable secrets, the governance model changes from secret custody to identity-mediated access. That is a broader identity security shift, because the organisation is no longer trying to protect every secret equally. It is trying to remove the need for many of them in the first place.
Multi-cloud secrets management exposes the limits of fragmented ownership. When an organisation runs separate tools, rotation rules or audit paths across environments, it creates inconsistent control and weakens policy enforcement. The article’s own stat on multiple secrets manager instances reflects a common governance pattern: fragmentation increases manual overhead and reduces confidence in inventory. Practitioners should treat central visibility as a governance requirement, not an optional reporting layer.
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.
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to the State of Secrets in AppSec.
- Read next: Secrets Management Buyer's Guide
What this signals
Secrets governance is shifting from repository management to lifecycle control. When credentials are spread across cloud, hybrid and on-prem systems, the decisive question is whether access can be issued, rotated and revoked without manual drift. Programmes that still treat vaults as the whole answer will keep finding that the control surface is larger than the storage layer.
Fragmented secrets platforms create governance debt that shows up later as audit and operational risk. Multiple manager instances make policy harder to standardise and make it easier for teams to drift into local exceptions. The result is weaker inventory confidence, slower rotation and more inconsistent evidence when auditors or incident responders ask where a credential came from and who can still use it.
For practitioners
- Audit for standing secrets across pipelines Identify API keys, certificates and passwords that remain embedded in CI/CD flows, containers or scripts, then prioritise those paths for replacement with time-bound access.
- Map secrets rotation to workflow ownership Assign clear owners for rotation, revocation and audit logging so that secrets are managed as a lifecycle, not as isolated assets in a vault.
- Reduce secrets manager fragmentation Consolidate duplicated secrets manager instances where possible so policy, visibility and rotation rules are enforced consistently across environments.
- Introduce secretless access for machine workflows Replace reusable credentials in workloads and automation with identity-based access patterns that remove the need to distribute secrets directly.
Key takeaways
- Enterprise secrets management now fails or succeeds on lifecycle governance, not on whether a vault exists.
- Distributed estates and multiple secrets manager instances increase fragmentation, which weakens policy consistency and operational control.
- Time-bound access, secretless patterns and consolidated governance are the main levers that change the risk profile.
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 protecting API keys, certificates and passwords from exposure and misuse. |
| NHI-07 — Long-Lived Secrets | The article criticises static credential models that do not scale across enterprise environments. | |
| Recommendation — Eliminate exposed secret paths and treat leaked credentials as immediate revocation events. Shorten secret lifetime and replace reusable credentials with ephemeral issuance wherever possible. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle, rotation and revocation are central to the article's governance model. |
| Recommendation — Apply IA-5 to enforce rotation, renewal and revocation for enterprise secrets. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about controlling who and what can use secrets across environments. |
| Recommendation — Align entitlement reviews to secret issuance and revocation paths across workloads and teams. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Stolen or reused credentials are the main threat secrets management is designed to reduce. |
| Recommendation — Map secrets exposure risks to credential-access tactics and focus detections on credential theft pathways. | ||
Key terms
- Enterprise Secrets Management: Enterprise secrets management is the governance of credentials such as API keys, passwords, certificates and tokens across large environments. It covers storage, rotation, access control and auditability so secrets can be used safely across cloud, hybrid and on-prem systems.
- Vaultless Architecture: A vaultless architecture delivers secrets through a managed service instead of a customer-operated vault server. The governance challenge does not disappear; it shifts to policy, identity, and runtime control over when secrets can be issued, retrieved, and revoked.
- Zero Standing Privilege: A control model in which an identity does not keep persistent access unless it is actively needed. For NHIs, this means credentials and permissions are issued for a narrow task and then removed. It reduces the time window and reuse value of stolen access.
- Secretless Access: Secretless access is a pattern where workloads authenticate and receive access without relying on long-lived embedded credentials. It typically uses runtime identity verification, federation, and short-lived authorization decisions. The goal is to reduce exposure from hardcoded or reusable secrets while keeping machine-to-machine access functional.
What's in the full article
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- Deployment model differences between SaaS, vaultless and self-managed vault approaches
- Feature-level breakdowns for dynamic secrets, secretless access and multi-tenancy
- Operational claims around high availability, disaster recovery and scalability
- Compliance and certification details such as SOC 2, GDPR and PCI DSS
👉 The full Akeyless article covers vaultless architecture, dynamic secrets and compliance details
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 17, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org