Why do secret managers not solve non-human identity governance on their own?

Why This Matters for Security Teams

Secret managers are necessary, but they are not an NHI governance model. They reduce exposure of stored credentials, yet they do not answer the harder questions: who owns the service account, what systems it can reach, whether it is still required, and how its access changes over time. That gap is why vaulting alone leaves standing privilege, orphaned identities, and unclear accountability in place. NHI governance has to cover lifecycle and policy, not only storage, as covered in the Ultimate Guide to NHIs and the Guide to the Secret Sprawl Challenge.

Research shows how common the fallout is: 97% of NHIs carry excessive privileges, and 71% are not rotated within recommended time frames according to Ultimate Guide to NHIs. That means many teams are protecting the secret while leaving the identity itself overpowered. This is also aligned with the direction of NIST Cybersecurity Framework 2.0, which treats governance, access control, and lifecycle discipline as separate control outcomes rather than a single vaulting task. In practice, many security teams discover the identity problem only after an access review, incident, or audit exposes what the vault never controlled.

How It Works in Practice

Effective NHI governance starts by separating three layers: the secret, the identity, and the entitlement. A secret manager can store and rotate the first layer, but it cannot by itself enforce ownership, approve use cases, or prove that access is still justified. For that, practitioners need identity inventory, workload ownership, scoped authorisation, and lifecycle enforcement across creation, use, rotation, and revocation. The 52 NHI Breaches Analysis and OWASP Non-Human Identity Top 10 both point to the same pattern: compromise often happens when identity sprawl and standing privilege outlive the secret itself.

In operational terms, a stronger model usually includes:

• Named ownership for every NHI, including business and technical accountability.
• Policy-based access tied to workload purpose, not just a stored token.
• Just-in-time credential issuance with short TTLs, especially for automation and CI/CD.
• Automated revocation when a workload, pipeline, or integration is retired.
• Continuous review of over-privilege, cross-environment access, and dormant identities.

This is where secret managers fit best: as one control in a wider governance stack, not the governance system itself. They support ephemeral secrets, but they do not decide whether a service account should still exist or whether an agent should be allowed to chain actions across tools. Current guidance suggests pairing vaulting with Zero Trust and lifecycle controls, as reflected in NHI Lifecycle Management Guide and NIST Cybersecurity Framework 2.0. These controls tend to break down in CI/CD-heavy environments with many ephemeral workloads because ownership, context, and revocation are often spread across separate teams and tools.

Common Variations and Edge Cases

Tighter secret controls often increase operational overhead, requiring organisations to balance rotation speed and access friction against reliability and deployment velocity. That tradeoff becomes especially visible in pipelines, Kubernetes clusters, third-party integrations, and machine-to-machine APIs where a short TTL can break brittle systems if identity design is weak. Best practice is evolving here: there is no universal standard for the right credential lifetime, but longer-lived secrets should require stronger justification and compensating controls.

One common edge case is the assumption that a vaulted secret equals a governed workload. It does not. A dormant API key inside a manager can still represent an orphaned identity with broad access. Another is third-party access, where a vendor token may be rotated but the underlying entitlement remains too broad or unreviewed. NHIMG research shows 92% of organisations expose NHIs to third parties and 91.6% of secrets remain valid five days after notification, which underscores how slow remediation can be when governance stops at the vault. For deeper context on incident patterns, see the Emerald Whale breach and the Shai Hulud npm malware campaign. In mature environments, the real control question is not whether a secret is encrypted, but whether the identity behind it still deserves any standing access at all.

Related resources from NHI Mgmt Group

• Who should own non-human identity lifecycle governance in practice?
• Why do non-human identities complicate identity governance programmes?
• Who should own non-human identity lifecycle decisions?
• Who should own non-human identity governance in a distributed environment?