NHI Security vs Secrets Management: Is a Vault Enough?
By Identra · Updated
No, a secrets manager alone is not enough. Secrets management stores, rotates, and controls access to credentials. Non-human identity (NHI) security governs the identities behind those credentials: discovering them, assigning owners, enforcing least privilege, and detecting misuse at runtime. The vault protects the key. NHI security answers who holds that key, what it can reach, and whether it is behaving normally.
| Dimension | Secrets management | NHI security |
|---|---|---|
| Unit of control | The credential: key, token, password, certificate | The identity behind the credential and everything attached to it |
| Discovery of unknowns | Manages only secrets that were put into the vault | Inventories NHIs and credentials across clouds, SaaS, and pipelines, vaulted or not |
| Secret zero problem | Unsolved: something must hold a credential to reach the vault | Mitigated with attested workload identity and federated, short-lived tokens |
| Ownership attribution | A path and a policy, rarely a named human owner | Maps each identity to an accountable owner and business purpose |
| Runtime misuse detection | None: a stolen valid secret authenticates normally | Baselines behavior and flags anomalous use of valid credentials |
| Offboarding and decommissioning | Keeps rotating credentials for dead workloads indefinitely | Flags dormant and orphaned identities for removal as part of lifecycle |
| Compliance evidence | Proves secrets are encrypted, access-controlled, and rotated | Proves who owns each identity, what it can access, and why the privilege is justified |
What secrets management actually does
A secrets manager is a hardened store for credentials: API keys, passwords, certificates, and tokens. It encrypts them at rest, brokers access through policy, injects them into workloads at runtime, rotates them on schedule, and writes an audit log of every read. Done well, it removes hardcoded credentials from source code and configuration, which is the single largest driver of secret sprawl.
That job matters more every year. GitGuardian's State of Secrets Sprawl 2025 report found 23.8 million secrets leaked on public GitHub in 2024 alone, and that 70 percent of secrets leaked in 2022 were still active years later. A vault directly attacks that exposure. But notice the scope: the vault manages the credentials someone put into it. It has no opinion about the identity using the credential, and no visibility into the keys that never reached it.
What NHI security covers
NHI security treats the non-human identity, not the credential, as the unit of control. That means service accounts, workload identities, OAuth apps, CI/CD pipelines, and increasingly AI agents that authenticate and act on their own. The scale problem is real: CyberArk's 2025 Identity Security Landscape found machine identities outnumber human identities 82 to 1, and nearly half of those machine identities hold sensitive or privileged access.
An NHI security program covers four things a vault does not attempt. Discovery: finding every NHI across clouds, SaaS, and pipelines, including credentials that were never vaulted. Governance: attributing each identity to a human owner and a business purpose, then right-sizing its permissions. Lifecycle: provisioning, rotating, and, critically, decommissioning identities when the workload or employee behind them goes away, the full NHI lifecycle. Detection: baselining how each identity normally behaves so that a valid credential used abnormally still raises an alarm, the NHI extension of identity threat detection and response.
Five questions your vault cannot answer
The cleanest way to see the boundary is to ask questions a well-run vault still cannot answer. Most of these map to risks in the OWASP NHI Top 10:
- Who owns this key? Vaults track paths and policies, not the human accountable for an identity when it leaks or breaks.
- Is it still used? A vault will faithfully rotate a credential for a service that was decommissioned two years ago.
- What can it reach? The vault knows what the secret is, not the blast radius of the permissions attached to it.
- Is it behaving normally? A stolen valid secret authenticates exactly like a legitimate one. Rotation does not help if the attacker re-reads the new value.
- Was it copied? Once a workload reads a secret, the vault's visibility ends. Duplicates in environment variables, logs, and tickets are invisible to it.
When to choose which
This is not a rip-and-replace decision. The honest sequencing depends on where you are.
One caution on posture-style tooling in both categories: an inventory with owners and scopes describes how identities are configured, not what they are doing right now. A compromised session or a misbehaving agent can look perfectly compliant in every posture report. That gap between admin-time configuration and runtime behavior is the core argument in why posture tools miss runtime identity risk, and it is why Identra's view is that NHI programs should treat runtime identity security as a first-class requirement rather than a later phase: the incidents that hurt involve valid, vaulted, rotated credentials being used by the wrong actor.
- Start with secrets management if credentials are still hardcoded in repos, config files, or CI variables. Centralized storage and rotation is the prerequisite hygiene layer, and nothing downstream substitutes for it.
- Add NHI security when you can no longer name the owner of every service account and key, which in practice happens well before the audit that proves it.
- Prioritize NHI security if AI agents or automation are minting credentials faster than humans can review them, since agent sprawl compounds the inventory problem daily.
- Move to short-lived, federated credentials and just-in-time access where platforms allow it. The best secret is one that expires before it can sprawl.
- Treat audit findings about dormant accounts, unowned keys, or unrotated credentials as the signal that vault-only coverage has hit its ceiling.
Frequently asked questions
Does NHI security replace my secrets manager?
No. The vault remains the enforcement point for storing, rotating, and brokering credentials. NHI security sits above it, governing which identities exist, who owns them, what they can access, and how they behave. Most NHI platforms integrate with vaults rather than replacing them, and a strong vault practice makes the NHI program's remediation work far easier.
What is the secret zero problem?
Secret zero is the credential a workload needs in order to authenticate to the secrets manager in the first place. The vault protects every secret except the one that unlocks it, so the bootstrap credential becomes the weakest link. Identity-based approaches sidestep it by having the platform attest the workload's identity and issue short-lived tokens, so no long-lived bootstrap secret exists to steal.
Are API keys identities?
An API key is a credential, not an identity, but every key stands in for one: the service, script, or integration that uses it. That distinction is the whole comparison in miniature. Managing the key answers where it is stored and when it rotates. Managing the identity answers who owns it, what it should be allowed to do, and whether its behavior has changed.
Where do AI agents fit?
AI agents are non-human identities with two aggravating traits: they are created and multiplied faster than any prior workload type, and they act autonomously, chaining tools and credentials in ways nobody scripted. A vault can hold an agent's tokens, but only identity-level governance can scope what each agent may do, attribute its actions, and catch it behaving outside its baseline.