When do secrets managers fall short for NHI governance?

Why Secrets Managers Are Necessary but Not Sufficient

Secrets managers still matter because they reduce hardcoded credentials, centralise storage, and support rotation. The problem is that storage is only one part of nhi governance. If access is not tied to workload identity, intent, and runtime context, the secret can still reach the wrong caller. That gap shows up in the same patterns NHIMG tracks in secret sprawl and lifecycle failure research, including the Guide to the Secret Sprawl Challenge and the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.

Security teams often assume a vault automatically means control, but the real decision point is delivery: which identity gets the secret, for what action, and for how long. That is why current guidance from the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 points beyond simple storage toward identity, access, and continuous verification. In practice, many security teams encounter secret misuse only after an exposed token is reused, not through deliberate monitoring.

How It Works in Practice

A secrets manager falls short when it is used as a static credential warehouse instead of a policy enforcement point. For NHI governance, the stronger pattern is to pair vaulting with workload identity, short-lived issuance, and runtime authorisation. That means the system proves what the workload is, evaluates whether the requested action is allowed, and then issues a secret or token only for that task.

In practical terms, this usually includes:

• Workload identity for cryptographic proof of the calling service or agent, rather than shared service accounts.
• Just-in-time credential provisioning so the secret expires after the task completes.
• Conditional or intent-based authorisation so access depends on what the workload is trying to do.
• Continuous rotation and revocation, not just secure storage and periodic review.

This is where NHI failures often show up in the wild. NHIMG’s 52 NHI Breaches Analysis and Shai Hulud npm malware campaign illustrate how quickly a token becomes an attack path once it is copied, cached, or reused outside its intended context. The standards view is consistent: NIST SP 800-63 Digital Identity Guidelines emphasise identity proofing and authentication, while NIST ZTA thinking shifts decisions to the request boundary instead of trusting the vault alone.

Where secrets managers do help is in generating, storing, and rotating the credential once policy has already decided the request is legitimate. They should be the delivery mechanism, not the governance model. These controls tend to break down in highly automated CI/CD pipelines or agentic workflows because the caller changes too fast for static roles and manual reviews to keep pace.

Common Variations and Edge Cases

Tighter credential controls often increase operational overhead, requiring organisations to balance lower exposure against higher integration and policy complexity. That tradeoff is especially visible in legacy systems, shared platforms, and vendor-connected workflows where every application cannot yet support workload identity or ephemeral issuance.

There is no universal standard for this yet, but current guidance suggests a layered approach. Use secrets managers for vaulting and rotation, then add PAM, RBAC, and ZTA controls where the workload can support them, and move toward JIT credentials as systems mature. For agentic systems, the bar is higher because autonomous behaviour can chain tools, escalate privilege, or reuse access in ways a human operator would not predict. That is why the relevant control question becomes whether the workload can be bounded at runtime, not whether a secret is stored safely.

Some environments will still need static credentials temporarily, especially where third-party integrations or embedded devices cannot consume short-lived tokens. In those cases, best practice is evolving toward the smallest possible blast radius: narrower scopes, aggressive rotation, stronger monitoring, and explicit revocation paths. NHIMG’s Top 10 NHI Issues and the Reviewdog GitHub Action supply chain attack are useful reminders that the exposure path often matters more than the storage location. The most common failure is assuming rotation alone solves governance when the real weakness is uncontrolled secret delivery to over-privileged or unverified workloads.

Related resources from NHI Mgmt Group

• What is the difference between secrets detection and NHI governance?
• What makes agentic AI an NHI governance issue?
• Why do leaked secrets remain such a persistent NHI risk?
• What makes idle secrets such a serious NHI risk?