Secrets manager evaluation now hinges on lifecycle, audit, and access

At a glance

What this is: This is an evaluation guide for secrets managers, arguing that the decisive criteria are encrypted storage, dynamic credentials, identity-based access, audit logging, and migration compatibility.

Why it matters: It matters because IAM, PAM, and NHI teams need controls that reduce credential exposure windows and prove who can access what across cloud, container, and hybrid environments.

By the numbers:

• In 2024 alone, more than 39 million leaked secrets were detected on GitHub.
• 70 percent of secrets leaked in 2022 remain active today, expanding the exploitable credential surface.
• Over 60% of companies experienced secrets-related security incidents in 2024, with hard-coded secrets as the primary cause.

👉 Read AccuKnox's full article on what to look for in a secrets manager

Context

Secrets management is really about controlling access credentials, not just storing them safely. In practice, the governance problem is that API keys, service account tokens, database passwords, and certificates often outlive the systems and people that use them, which turns every leak into a durable access path rather than a one-time exposure.

For IAM and NHI programmes, the critical question is whether the secrets layer shortens credential lifetime, constrains retrieval by identity, and leaves an audit trail that can support investigation and compliance. Without those controls, encrypted storage alone only protects secrets at rest while leaving operational exposure untouched.

Key questions

Q: How should security teams replace shared secrets for workloads that span multiple clouds?

A: Use federated workload identity so the workload proves who it is with a signed token or attestation instead of a shared static secret. Then scope the resulting credential tightly to the request and make the trust relationship revocable when the workload, supplier, or environment changes.

Q: Why do encrypted vaults still leave organisations exposed to secrets theft?

A: Encryption protects secrets at rest, but it does not stop valid credentials from being copied and reused once exposed. If a secret remains usable for weeks or months, the attacker can authenticate normally. Exposure shrinks only when the credential is short-lived, tightly scoped, and revoked automatically after use.

Q: What do security teams get wrong about secrets manager migration?

A: They often focus on storage migration and ignore policy translation, endpoint cutover, and workload compatibility. A safe migration preserves identity bindings, namespace boundaries, and audit continuity while changing as little application logic as possible. The right test is whether access governance survives the move, not whether the vault connects successfully.

Q: How do organisations know whether their secrets governance is actually working?

A: Look for fewer identities with decrypt rights, fewer hardcoded credentials in code and state, and clear evidence that retired workloads can no longer access secret paths. If secret use still depends on manual exceptions or shared automation roles, governance is present in theory but not in practice.

Technical breakdown

Why dynamic secrets matter more than encrypted storage

Encrypted vaults protect secrets at rest, but they do not change the fact that a long-lived credential remains usable after theft. Dynamic secrets reduce that problem by issuing time-bound credentials on demand, then revoking them automatically when the lease expires. That changes the attacker model from durable reuse to a narrow, time-limited window. In cloud, database, and Kubernetes workflows, this is the control that determines whether compromise becomes persistent access or a short-lived event.

Practical implication: prioritise short-lived credential issuance for high-value workloads before expanding vault centralisation.

Identity-based access control for human and machine identities

A secrets manager should not treat every requester the same. Identity-based access control ties retrieval rights to a human user, service account, workload, or application role, then limits access to only the required secret paths. This matters because secrets systems often become the back door to broad infrastructure access when policies are too coarse. OIDC, LDAP, Kubernetes auth, JWT, and AppRole all matter only if the policy layer maps identities to specific paths, environments, and duties.

Practical implication: review whether secret retrieval is bound to least privilege at the path level, not just authenticated at login.

Audit logs and namespace isolation as governance controls

Auditability is the difference between operational control and blind trust. Immutable logs should show who requested a secret, which auth method was used, which path was accessed, and whether the request succeeded or failed. Namespace isolation adds a second boundary by separating teams, environments, and audit trails so one compromise does not blur into the entire estate. For compliance, that separation is often the only way to prove accountability across shared infrastructure.

Practical implication: validate that secret access events are exportable to your SIEM and segmented by tenant or environment.

NHI Mgmt Group analysis

Secrets manager evaluation is now an NHI governance problem, not a storage problem. The market language often starts with encryption, but the real failure mode is credential lifetime and retrieval governance. If a secret can be reused after theft, the vault has not solved the access problem, it has only relocated it. Practitioners should judge tools by how they reduce exposure windows and constrain who can retrieve which secret, not by how many secret types they store.

Dynamic credentials create the right security shape because they collapse exploitability. A leaked static secret can remain valuable for months, while a lease-bound credential can become useless in hours. That difference matters more than storage format because attackers exploit reuse, not encryption strength. The implication is that lifecycle design, rotation semantics, and revocation speed are the control plane that matters for machine identities.

Identity-based policy is the minimum viable control for secrets governance. Secrets systems that rely on broad role buckets or shared admin access reproduce the same privilege creep seen in IAM failures. Fine-grained policy must map human, workload, and service identities to specific paths, environments, and duties. Access path drift: once secret retrieval stops being tied to the identity that genuinely needs it, the secrets manager becomes an unintended privilege broker.

Auditability and tenant separation are the controls that make secrets governable at scale. Without immutable logging and namespace boundaries, security teams cannot answer basic questions about who touched a credential or whether one team’s access pattern contaminated another’s audit trail. That is a governance failure, not a reporting inconvenience. Practitioners should treat audit completeness and isolation as core design requirements, not compliance add-ons.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• That trend reinforces the Guide to the Secret Sprawl Challenge as the next step for teams dealing with exposed credentials and remediation.

What this signals

Secret sprawl is now a lifecycle problem as much as a discovery problem. When leaked credentials remain valid, the operational question shifts from finding secrets to proving they are no longer usable. That is why lifecycle controls, revocation speed, and namespace discipline matter more than storage centralisation alone, especially in multi-cloud estates.

With 64% of leaked secrets from 2022 still valid today, the governance gap is not visibility but persistence. Teams that cannot shorten credential lifetime should expect exposure to outlast detection, which turns every leak into an access management issue rather than a clean-up task.

For practitioners

• Map every secret type to an owning identity Inventory API keys, database passwords, cloud credentials, service account tokens, and certificates, then bind each to a named human, workload, or service identity with a documented owner.
• Replace long-lived secrets with lease-bound credentials Use dynamic issuance for cloud, database, and Kubernetes access so retrieved credentials expire quickly and cannot be reused after the task completes.
• Tighten retrieval policy to secret paths Review whether policies limit access by environment, application, and duty, and remove any broad role that can read more secret paths than required.
• Test audit export before a real incident Confirm that every secret access event includes identity, auth method, path, action, and result, then send those logs into your SIEM for correlation and retention.
• Stage migration without broadening exposure Pilot the new secrets platform on one workload or namespace first, then validate endpoint changes, policy translation, and rollback before expanding to production.

Key takeaways

• Secrets manager selection should be judged by how much it reduces credential reuse, not by how neatly it stores credentials.
• Long-lived secrets remain the main reason exposures become incidents, because valid credentials can still be used long after discovery.
• Least privilege, immutable audit logs, and fast revocation are the controls that turn secrets from a durable liability into a governable asset.

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.
• 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.
• Identity-Driven Access Control: A governance approach that makes identity the basis for who can reach systems, data and industrial assets. It matters in converged environments because consistent identity policy is one of the few controls that can span enterprise applications, OT systems and third-party support paths.
• Namespace Isolation: Namespace isolation is the expectation that users or policies restricted to one Kubernetes namespace cannot affect resources or data outside that namespace. It fails when a shared controller executes delegated logic with broader runtime privileges than the author of the request.

What's in the full article

AccuKnox's full article covers the operational detail this post intentionally leaves for the source:

• How AccuKnox maps its Vault-compatible API to existing endpoint changes during migration.
• The specific combinations of AWS, Kubernetes, database, and PKI workflows supported by dynamic credential engines.
• Namespace, policy, and audit configuration details for teams planning a pilot rollout.
• How the platform aligns secrets management with runtime security and CSPM in one deployment.

👉 The full AccuKnox article covers migration detail, dynamic credential support, and audit configuration examples.

Deepen your knowledge

NHI governance, agentic AI identity, machine identity security, and workload identity 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.