TL;DR: Akeyless argues that Doppler is a developer-first secrets tool, but it does not cover certificate lifecycle management, privileged access management, self-hosting, or machine and AI agent identity governance, while machine identities now outnumber human ones roughly 144 to 1. The real decision is whether teams need secrets storage or enterprise identity security.
At a glance
What this is: This is an analysis of why Doppler and enterprise identity security solve different problems, with Akeyless positioning secrets management as only one layer of a broader governance stack.
Why it matters: IAM, PAM, and NHI teams need to separate secret storage from identity governance because machine and AI agent access now sits outside the scope of developer-first vault-only tools.
By the numbers:
- Machine identities now outnumber human ones roughly 144 to 1, according to Akeyless.
Context
Secrets management is about storing and rotating credentials. Identity governance is about deciding who and what can use those credentials, for how long, and under what policy. That distinction matters here because the article argues that Doppler covers the first problem but not the second, especially once machines and AI agents enter the access model.
The governance gap is not theoretical. Enterprises now have to manage certificates, privileged access, and non-human identities alongside application secrets, which means a secrets-only tool can leave access decisions fragmented across separate systems. In that environment, the question is no longer whether secrets are protected, but whether the identities using them are governed at all.
Key questions
Q: How should security teams decide between secrets management and identity governance?
A: They should start by asking whether the problem is storing credentials or governing the identities that use them. If the environment includes certificates, service accounts, workloads, or AI agents, a secrets vault alone is insufficient. The decision should be based on lifecycle, runtime policy, and audit needs, not just developer convenience.
Q: When does a secrets tool stop being enough for enterprise access control?
A: It stops being enough when the organisation must govern certificates, privileged access, service identities, or AI agents alongside application secrets. At that point, the real problem is not just storage or rotation. It is policy enforcement, lifecycle control, and accountability across a broader identity estate.
Q: What breaks when machine identities rely on bearer secrets?
A: Bearer secrets can be replayed once exposed, so possession of the token becomes enough to act. That breaks the assumption that machine access remains tied to the intended holder, which is why sender-constrained proof-of-possession controls matter for service accounts and automated workflows.
Q: How should teams evaluate whether they need PAM, certificate lifecycle, or only secrets storage?
A: Teams should ask whether access is limited to storing credentials or extends to governing how credentials are issued, approved, expired, and used in high-risk sessions. If the answer includes privileged access, certificate renewals, or non-human actors, the requirement has moved beyond secrets storage into identity security governance.
Technical breakdown
Why secrets management is not identity governance
Secrets management protects confidential material such as API keys, tokens, and certificates. Identity governance controls entitlement, authentication scope, approval, and lifecycle for the actor using that material. A vault can tell you a secret exists and whether it was rotated, but it cannot by itself determine whether the right workload, service account, or AI agent should be allowed to use it. That separation is why developer-first tooling can be useful without being sufficient for enterprise identity security.
Practical implication: teams should evaluate whether a tool governs credentials only, or also governs the actors and policies around those credentials.
Why certificate lifecycle and privileged access change the category
Certificate lifecycle management introduces issuance, renewal, revocation, and expiry control across systems that often outlive the application team that requested them. Privileged access management adds approval, scope control, and session governance for high-risk use. Once an organisation needs both, it is no longer solving a simple secret storage problem. It is operating an identity control plane that spans human admins, service identities, and machine-to-machine trust.
Practical implication: assess whether certificate and privileged access workflows are still fragmented across separate tools.
Machine and AI agent identities need runtime policy, not only storage
Machine identities and AI agents use secrets, but their real risk comes from the actions those secrets enable. Runtime policy enforcement matters because a secret vault can verify possession, while an identity control layer can evaluate whether a command or access request should proceed. That distinction becomes sharper as agents act across hybrid and multi-cloud environments, where the control point must sit closer to the moment of action than to the moment of secret retrieval.
Practical implication: look for policy enforcement at access time, not only secret storage and retrieval.
Breaches seen in the wild
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
- BeyondTrust breach 2024: A stolen BeyondTrust Remote Support API key let a China state-sponsored actor reset accounts and reach US Treasury workstations in 2024.
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
Secrets management and identity security are adjacent, not interchangeable. The article is correct to separate the two because secret protection answers a narrower question than identity governance. A vault can reduce leakage and improve rotation, but it does not decide whether an actor should be allowed to use the credential in the first place. Practitioners should treat that boundary as structural, not semantic.
144:1 is a governance signal, not just a scale statistic. When machine identities outnumber human ones by that margin, the operational problem shifts from protecting a small set of developer secrets to governing a large, dynamic identity estate. That changes the centre of gravity from convenience to lifecycle, policy, and accountability. Teams that still frame the problem as secrets storage alone are already behind the real control surface.
Certificate lifecycle management and PAM mark the point where secrets tooling stops being enough. The article shows that once an organisation must govern expiry, revocation, privileged sessions, and hybrid access paths, the purchasing decision becomes about identity control, not just vault features. That is the line practitioners should use to separate point tools from platforms. The implication is simpler tooling may serve developers, but it cannot replace identity governance.
Runtime authority is the right concept for machine and AI agent access. Static secrets answer who knows the credential, not whether the actor using it should proceed at that moment. The article’s AI agent examples show why action-time policy matters more than inventory alone. That is the governance shift programmes need to recognise as autonomous and semi-autonomous systems become part of the access plane.
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: Ultimate Guide to NHIs — Key Challenges and Risks
What this signals
Secrets-only tools will keep losing ground as identity estates expand. Once organisations must govern service accounts, certificates, workloads, and AI agents together, a vault-centric model cannot represent the whole access picture. The programme implication is that teams need one policy view across issuance, privilege, and revocation rather than separate controls stitched together after the fact.
The useful signal for practitioners is not whether a secret can be stored, but whether the actor using it is governed at the moment of action. That is where identity programmes will keep converging with PAM, certificate lifecycle management, and non-human identity governance.
For practitioners
- Map the boundary between secrets and identity governance Inventory where your current tooling only stores or rotates credentials, and where separate controls are still making approval, privilege, and lifecycle decisions.
- Assess non-human identity coverage Identify which service accounts, workloads, API keys, certificates, and AI agent credentials sit outside your current governance model and remain unmanaged by policy.
- Review privileged access and certificate lifecycle together Check whether certificate issuance, renewal, revocation, and high-risk access approvals are split across tools that cannot enforce one policy model.
- Test runtime policy for machine and AI agent actions Confirm that access decisions can be enforced at the moment of use, not only when a secret is retrieved or an account is provisioned.
Key takeaways
- The article’s central point is that secrets management and identity governance address different layers of access control.
- Machine identities create scale pressure that makes vault-only thinking incomplete for enterprise programmes.
- Teams should judge tools by whether they govern use, privilege, and lifecycle, not only credential storage.
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 CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article contrasts secrets storage with broader control over who and what may use credentials. |
| NHI-07 — Long-Lived Secrets | The article’s comparison depends on whether credentials are merely stored or governed over time. | |
| NHI-04 — Insecure Authentication | Machine and AI agent access depends on how credentials are used, not only where they are kept. | |
| Recommendation — Apply NHI-05 to reduce standing privilege around service accounts, workloads, and other machine identities. Use NHI-07 to shorten secret lifetime and align rotation with actual identity ownership. Map machine authentication flows to NHI-04 and verify that credential use is bounded by policy. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article’s core distinction is whether the identity using a secret is authorised to act. |
| Recommendation — Apply PR.AA-05 to unify entitlement decisions across secrets, services, and privileged identities. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | Secrets-only governance leaves credential misuse and movement paths insufficiently controlled. |
| Recommendation — Track exposed or overused machine credentials through TA0006 and TA0008 to find abuse paths. | ||
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.
- Identity Governance: Identity governance is the set of controls that defines who approves access, who owns it, how it is reviewed, and when it is removed. In practice, it turns identity management from a deployment task into a durable control system that can withstand audits, organisational change, and operational growth.
- Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
- Certificate Lifecycle Management: The governance of digital certificates from issuance through renewal and revocation, ensuring certificates are valid, monitored, and rotated before expiry. Expired certificates are a leading cause of outages and unplanned security gaps.
Deepen your knowledge
NHI governance, machine identity security, and secrets management 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 or NHI governance programme, it is worth exploring.
Published by the NHIMG editorial team on July 22, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org