By NHI Mgmt Group Editorial TeamBased on AccuKnox: “Top 5 Things to Look For in a Secrets Manager” (December 4, 2025)

TL;DR: Secrets managers are no longer just encrypted vaults, according to AccuKnox, because the real evaluation criteria are dynamic short-lived credentials, identity-based access control, immutable auditability, and migration without workflow disruption. Static secrets and weak lifecycle governance still create the blast radius that attackers exploit.


At a glance

What this is: This is a practical evaluation of what matters in a secrets manager, with lifecycle, access control, auditability, and migration compatibility emerging as the real decision points.

Why it matters: It matters because IAM, PAM, and NHI teams have to treat secrets as governed identities and not just encrypted values, especially when multiple clouds, CI/CD, and Kubernetes are involved.

By the numbers:

  • In 2024 alone, more than 39 million leaked secrets were detected on GitHub.

Context

Secrets managers are often evaluated as encrypted storage, but that lens is too narrow for modern environments. The core governance problem is lifecycle control over non-human credentials, including issuance, expiry, access scope, auditability, and offboarding across cloud, Kubernetes, and CI/CD workflows.

AccuKnox frames the buying decision around five criteria: versioned encrypted storage, dynamic short-lived credentials, identity-based access control, comprehensive audit logging, and migration compatibility. That combination reflects a broader shift in NHI governance, where a vault is only one part of the control plane and not the whole control model.

The article also highlights why this matters operationally. Secrets sprawl, hard-coded credentials, and long-lived access continue to create the conditions for breach, which means practitioners need to compare how a secrets manager handles lifecycle and traceability, not just where it stores values.


Key questions

Q: What breaks when secrets are static instead of dynamic?

A: Static secrets break the assumption that access is temporary, contextual, and easy to revoke. They increase the blast radius of compromise, make change-based offboarding unreliable, and keep credentials valid long after the original task is complete. Dynamic secrets reduce that exposure by tying access more closely to time, purpose, and policy.

Q: Why do long-lived service account secrets increase breach risk?

A: They extend the window in which a leaked or reused credential remains valid, so a single exposure can become persistent access. Without expiry, rotation discipline, and dependency mapping, the secret itself becomes the control point the attacker needs.

Q: How can security teams tell whether secret management is actually working?

A: Look for fewer plaintext secrets, narrower reuse, faster rotation, and a shrinking set of credentials that remain valid across multiple systems. If the same password or API key can still unlock several services, secret management is not yet reducing blast radius in practice.

Q: What should teams prioritise first in secrets governance: rotation, auditability, or access scope?

A: Access scope and lifecycle enforcement usually come first, because rotating a secret that is broadly exposed does not fix overreach. Auditability then proves whether the scope and lifecycle controls are being followed. Rotation is essential, but it is strongest when it operates inside a well-scoped identity model.


Technical breakdown

Dynamic secrets versus static credentials

Dynamic secrets are time-bound credentials generated on demand and designed to expire automatically after a short TTL. That changes the attack model because the credential itself is no longer reusable in the same way a static password, key, or token is. In practice, the value is not only in short duration, but in the ability to issue workload-specific access that can be revoked by policy rather than by manual cleanup. For NHI governance, this is the difference between storing secrets and governing credential exposure windows.

Practical implication: Treat TTL, renewal, and revocation as first-class control requirements when evaluating any secrets platform.

Identity-based access control for NHI credentials

Identity-based access control means a human user, service account, application, or workload only receives the secrets and operations it actually needs. The article points to OIDC, LDAP, Kubernetes service accounts, JWT, AppRole, and token-based access as the mechanisms that bind secret retrieval to identity and policy. This is where least privilege becomes practical for NHI, because access is evaluated at retrieval time, not assumed from network location or environment ownership. Without this, a secrets manager becomes a passive store rather than an access control layer.

Practical implication: Validate that policy granularity is strong enough to limit each identity to the exact secret paths and secret types it should use.

Audit logs and secret lifecycle traceability

Auditability is the control that proves who accessed a secret, when, how, and whether the access was authorised. The article emphasises immutable logs, SIEM export, and namespace isolation, which matter because secrets governance fails when teams cannot reconstruct access history or separate one environment's evidence from another. From a compliance perspective, audit logs are not a reporting add-on. They are the evidence layer that makes secret issuance, use, and exposure reviewable across tenants and teams.

Practical implication: Require immutable, identity-aware audit trails that can be correlated with SIEM and separated by namespace or environment.


Threat narrative

Attacker objective: The attacker aims to turn a leaked or reusable secret into durable access that can be used for lateral movement, data access, or service abuse.

  1. Entry happens when hard-coded secrets, leaked tokens, or long-lived credentials are exposed in code, CI/CD systems, or cloud workflows.
  2. Credential abuse follows when the leaked secret remains active long enough to be reused outside its intended context, giving attackers authorised-looking access.
  3. Impact occurs when that access reaches cloud resources, databases, or service accounts with broader permissions than the original workload required.
  • ArtiPACKED 2024: Unit 42 found public GitHub Actions artifacts in major open source projects leaking live GITHUB_TOKENs, runtime tokens and cloud tokens.
  • 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.

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 manager evaluation has moved from storage quality to credential governance. A vault that encrypts values but cannot enforce short-lived issuance, precise identity binding, and traceable access is only solving part of the problem. The modern evaluation lens is whether the platform governs the full lifecycle of a machine credential, from creation through expiry and audit.

Long-lived secrets create the real identity blast radius. Once a secret is reusable across environments or stays active for months, compromise becomes durable rather than momentary. That is why the article's emphasis on dynamic secrets matters: the risk is not just disclosure, but the persistence of authority after disclosure.

Secret visibility without lifecycle evidence is incomplete governance. Audit logs that show access events are useful, but they do not by themselves prove that privilege was scoped correctly or that expired credentials were actually retired. Practitioners need governance models that connect access logs to expiry, namespace isolation, and identity ownership.

Migration compatibility has become a control requirement, not a convenience feature. If moving to a new secrets platform requires disruptive rewrites, organisations will preserve shadow paths and leave legacy secret sprawl in place. The operational implication is that lifecycle governance must be adoptable without forcing insecure parallel estates to persist.

Identity-based secret access should be treated as part of NHI architecture, not just secrets management. The best signals in the article are the ones that tie policies, workloads, and audit trails together. That means practitioners should evaluate secrets platforms as part of IAM, PAM, and workload identity design rather than as isolated vault tooling.

From our research library:

What this signals

Secret lifecycle is now the decisive governance variable. The practical question is no longer whether secrets are encrypted, but whether they are issued, scoped, and retired in ways that match real workload use. If a secret can outlive the task that needed it, then the control model has already failed at design time.

Shadow access paths tend to persist when migration is treated as a one-time project. Secrets platforms that cannot absorb existing authentication patterns and policy structures without disruption often leave legacy credentials in place longer than planned. That is why compatibility is part of governance, not just implementation convenience.

Immutable audit trails matter because they expose whether NHI controls are actually enforceable. A central log of identity, auth method, path, and result gives security teams a way to verify that secret access maps to policy rather than convenience. Without that evidence, least privilege is only an assumption.


For practitioners

  • Assess credential TTL discipline Inventory where secrets remain static, where they rotate manually, and where expiration is enforced automatically. Prioritise the credentials that can be reused outside a single job or deployment cycle.
  • Bind secret retrieval to identity policy Verify that each human, service account, or workload can only read the specific paths and secret types it needs. Test policy scope against Kubernetes auth, OIDC, JWT, and AppRole flows.
  • Require immutable audit evidence Confirm that every secret access event records identity, auth method, secret path, action, and outcome, and that logs can be exported into SIEM without breaking namespace boundaries.
  • Plan migration without parallel sprawl Use API compatibility, namespace mapping, and policy translation to avoid running two secrets estates longer than necessary. Every extra month of dual running tends to preserve hidden access paths.
  • Reduce standing secret reuse Replace shared passwords, reusable tokens, and hard-coded credentials with workload-scoped secrets that expire automatically, especially in CI/CD and cloud automation paths.

Key takeaways

  • Secrets managers are being judged as governance systems for non-human credentials, not just encrypted storage for sensitive values.
  • Long-lived and hard-coded secrets remain a major exposure path, which is why short-lived issuance and traceable access matter more than vault centralisation alone.
  • The strongest evaluation criteria are lifecycle control, auditability, and migration compatibility, because those determine whether secret sprawl is actually reduced.

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 SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-02 — Secret LeakageThe article centres on leaked and hard-coded secrets as the exposure path.
NHI-05 — Overprivileged NHIIt stresses least privilege and identity-based access for secret retrieval.
NHI-07 — Long-Lived SecretsDynamic short-lived credentials are a central evaluation criterion in the article.
Recommendation — Scan for secret leakage in code, CI/CD, and logs, then revoke exposed credentials immediately. Constrain NHI secret access to the minimum paths and actions each identity actually needs. Replace long-lived secrets with short-lived credentials and enforce expiry by policy.
NIST SP 800-53 Rev 5IA-5 — Authenticator ManagementCredential lifecycle management and rotation are central to the article's evaluation criteria.
Recommendation — Apply authenticator management to control issuance, rotation, and retirement of secrets.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe article focuses on identity-based access control and least privilege for secrets.
Recommendation — Review entitlements so secret access is tied to identity and authorised business need.
CIS Controls v8CIS-5 — Account ManagementThe article concerns identity scoping and lifecycle controls for secret-bearing accounts.
Recommendation — Govern accounts that can retrieve secrets and remove unused access paths promptly.

Key terms

  • 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.
  • Identity-Based Access Management: Identity-Based Access Management is the practice of granting and controlling access according to who or what is requesting it. It uses verified identities, attributes, roles, and context to decide access to systems, data, and services, and it ties authentication, authorization, lifecycle management, and auditability into one control model.
  • Immutable Audit: Immutable audit is a logging approach that preserves a trustworthy record of what an agent did and when it did it. In AI governance, it supports investigation, accountability, and compliance by ensuring actions cannot be quietly altered after the fact.
  • 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.

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.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 21, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org