Secrets Management vs. NHI Governance: Where Vaults Stop and Identity Begins
A vault secures the secret - it doesn't govern the identity holding it. Here's the gap between secrets management and NHI governance, and why you need both layers in 2026.
9 min read · Last updated September 2026
Your HashiCorp Vault is configured correctly. Rotation policies are in place. Dynamic secrets are flowing. And somewhere in your environment, a service account nobody owns is sitting on admin-level database credentials - perfectly vaulted, completely ungoverned.
That's the gap this post is about.
Secrets management and NHI governance are adjacent disciplines that the market often conflates, especially as vendors race to claim both. Getting them confused leads to a false sense of security: you've locked the safe, but you haven't asked who has the combination, why they need it, or whether they still work here.
What Secrets Management Actually Does
A secrets manager is a secure store for credentials. It answers one question: how do we protect this secret at rest and in transit?
The major players each have a distinct angle:
- HashiCorp Vault - the cross-cloud, infrastructure-first choice. Vault offers dynamic credential generation, pluggable auth backends including Kubernetes, AWS IAM, and AppRole, and fine-grained ACL policies. The tradeoff is operational weight: setting up Vault in a secure, highly available configuration requires significant time and infrastructure knowledge.
- CyberArk Conjur - purpose-built for enterprises already running CyberArk for human PAM. Conjur's graph-based data model organizes secrets and access control around hosts, groups, and layers, scaling well for large Kubernetes environments.
- AWS Secrets Manager / Azure Key Vault / GCP Secret Manager - cloud-native secrets managers optimize for tighter coupling with their respective clouds, providing the lowest latency and most features within a single cloud.
All of these tools do the same core job: store, rotate, and distribute secrets. They answer how is this credential protected? They do not answer who is this credential attached to, who owns that identity, what can it reach, and should it still exist?
That's a different question entirely.
What NHI Governance Actually Does
NHI governance is the discipline of managing the identities that consume secrets - not the secrets themselves. It answers: who are all our non-human identities, what do they have access to, who is accountable for them, and what happens when they're no longer needed?
The scope is wide. Non-human identities include service accounts, API keys, OAuth tokens, SSH keys, RPA bots, cloud workload credentials, and AI agents. Non-human identities now outnumber human identities by more than 80 to 1 in the average enterprise, and machine identities in the average enterprise jumped from roughly 50,000 in 2021 to 250,000 in 2025.
NHI governance covers five things a vault does not:
- Discovery and inventory - knowing every NHI that exists, not just the ones that were registered with your vault
- Ownership assignment - a named human accountable for each identity
- Entitlement right-sizing - verifying that the identity's permissions match its actual function
- Lifecycle management - provisioning, change tracking, and decommissioning tied to the application or project lifecycle
- Review and certification evidence - periodic attestation that access is still appropriate, with audit-ready records
Only 5.7% of organizations have full visibility into their service accounts. That's not a vault problem. Vault knows about the secrets it manages. It doesn't know about the service account in your legacy ERP that was provisioned three years ago by an engineer who left the company, never registered with any secrets manager, and still holds read/write access to your production database.
The Four Gaps Vaults Leave Open
1. Ownership
Vaults store secrets. They don't track who is responsible for the identity that uses them. A 2025 WEF analysis found that 51% of organizations report no clear ownership of AI identities. For older service accounts, the problem is even more acute: 8% of enterprise identities lack any HR system ownership linkage after the departure of their creator - orphaned identities that persist indefinitely with no human accountable for their continued existence.
A secret can be rotated on a perfect 30-day schedule while the identity holding it has no owner, no review date, and no decommission plan.
2. Entitlement Right-Sizing
Vaults enforce access to the secret. They don't evaluate whether the identity should have that level of access in the first place. 97% of NHIs carry excessive privileges, increasing unauthorized access and broadening the attack surface.
The pattern is familiar: a service account is provisioned with broad permissions "to avoid friction," the application ships, and nobody ever revisits the entitlements. The vault rotates the credential faithfully. The over-privilege persists indefinitely.
3. Lifecycle and Decommissioning
Nearly half (47%) of NHIs are over a year old and have never undergone a credential rotation, making them prime targets for long-term exploitation. But the deeper problem isn't rotation - it's that the identity itself outlives its purpose.
Orphaned NHIs maintain access to sensitive systems, use outdated security configurations, and exist outside monitoring systems. Attackers specifically target these forgotten identities. A vault that rotates a secret every 30 days is still rotating credentials for an identity that should have been deprovisioned when the project ended six months ago.
4. Review Evidence
Compliance frameworks - SOC 2, ISO 27001, NIS2, PCI DSS - require periodic access reviews with documented evidence. Vaults produce audit logs of secret access. They don't produce certification records showing that a named owner reviewed a service account's entitlements and confirmed they're still appropriate.
Compliance exposure from orphaned accounts violates least-privilege and deprovisioning requirements across ISO 27001, NIS2, PCI DSS, and FedRAMP. When an auditor asks "who reviewed this service account's access last quarter?", a vault access log is not the answer they're looking for.
The Concrete Failure Mode
Here's what the gap looks like in practice. A developer creates a CI/CD service account with admin-level cloud permissions. The secret is stored in Vault. The developer leaves the company. The project is deprecated. Nobody deprovisions the service account because nobody owns it - it was never registered in any governance system. Vault continues rotating the credential on schedule.
Eighteen months later, an attacker compromises a stale OAuth token from the same deprecated project, pivots to the service account, and uses its admin permissions to exfiltrate data.
The vault worked perfectly. The governance layer didn't exist.
The vaulted-but-ungoverned trap: A secret that rotates every 30 days attached to an orphaned, over-privileged service account is not secure — it's just a well-maintained attack surface. Rotation reduces the window of exposure for a compromised credential. It does nothing to reduce the blast radius of an identity that should no longer exist.
2026 Market Context: Consolidation Is Blurring the Lines
The vendor landscape is moving fast, and the marketing language is getting muddier as a result.
Palo Alto Networks completed its $25 billion acquisition of CyberArk on February 11, 2026, establishing identity security as a core pillar of its platformization strategy. The deal folds CyberArk's PAM and secrets management capabilities - including Conjur and the Venafi machine identity platform (acquired by CyberArk in 2024) - into a broader security platform that also covers network and cloud security.
On the PAM side, Delinea completed its acquisition of StrongDM in March 2026, unifying enterprise PAM with just-in-time runtime authorization to eliminate standing privilege in AI-driven environments. The combined platform aims to govern privileged actions at the moment they're taken, not just at session initiation.
Both deals signal the same market thesis: secrets management alone is insufficient. The credential layer needs a governance and authorization layer above it. But "platform" claims don't automatically close the governance gaps described above. A unified vendor doesn't mean unified coverage - especially for the long tail of SaaS apps, legacy service accounts, and non-SCIM systems that most enterprises actually run.
The categories are converging: PAM vendors are extending into machine identity, secrets management vendors are adding governance, and NHI specialists are integrating with both. For security architects, this means evaluating what each platform actually covers today, not what the roadmap promises.
The Architecture: Two Layers, Not One
The right mental model is a stack, not a choice.
Layer 1 - Secrets Management: Stores, rotates, and distributes credentials. Answers: how is this secret protected? Tools: HashiCorp Vault, CyberArk Conjur, AWS/Azure/GCP secrets managers.
Layer 2 - NHI Governance: Manages the identities that consume secrets. Answers: who is this identity, who owns it, what can it reach, is that appropriate, and what happens when it's decommissioned? Tools: IGA platforms with NHI coverage, dedicated NHI governance platforms.
The governance layer needs to sit above the vault - not replace it. It should pull inventory from your secrets managers, your cloud IAM, your SaaS apps, and your CI/CD pipelines to build a complete picture of every non-human identity in your environment. Then it applies the same governance controls you use for human identities: ownership, entitlement review, lifecycle automation, and audit evidence.
This is exactly where Iden operates. As an IGA platform built for both human and non-human identities, Iden provides the governance layer above your existing vaults - unifying service accounts, API keys, and bot credentials alongside your human workforce in a single access governance fabric. You keep your vault. You add the ownership, review, and lifecycle controls that the vault was never designed to provide.
For more on the scale of the NHI problem, see The NHI Explosion: Why Non-Human Identities Are the Identity Blind Spot of 2026 and Service Accounts and API Keys: The Non-Human Attack Surface Your SIEM Doesn't See.
Do You Need Both? Where to Start
The honest answer: most organizations need both layers, but they're at different stages of maturity in each. Use the tool below to assess where your gaps are.
If you're starting from zero on the governance layer, the sequence that works in practice:
- Inventory first. You can't govern what you can't see. Pull NHI inventory from your cloud IAM, secrets managers, SaaS connectors, and CI/CD pipelines into a single register.
- Assign ownership. Every service account needs a named human owner. No owner = immediate remediation candidate.
- Right-size entitlements. Compare what each NHI can do against what it actually does. Flag and remediate the gap.
- Automate lifecycle. Tie NHI deprovisioning to application decommission events, not to manual tickets that get forgotten.
- Generate review evidence. Run periodic certifications with documented outcomes - not just access logs, but attestation records.
The Takeaway
A vault is a credential safe. It does its job well. But a safe doesn't know who has the combination, whether they still need it, or whether the person who originally requested it left the company two years ago.
NHI governance is the layer that answers those questions - for every service account, API key, OAuth token, and AI agent in your environment. In 2026, with non-human identities outnumbering humans by 80:1 and market consolidation blurring vendor categories, the architectural distinction matters more than ever.
Secure the secret. Govern the identity. You need both.
Related reading
Honest Guide to Okta Alternatives for Identity Governance
Okta is best-in-class SSO. But when governance depth, non-SCIM coverage, or cost at scale become the problem, here's an honest look at what to consider instead.
The Honest IAM Buyer's Guide: Best Tools by Category in 2026
A trade-off-first guide to IAM tools in 2026 - SSO, IGA, PAM, CIAM, and directories explained, with honest best-fit profiles for Okta, Entra ID, SailPoint, CyberArk, Lumos, Iden, and more.
The Identity Fabric Explained: What It Actually Is, What It Isn't, and Why Coverage Is the Whole Game
Identity fabric is a design approach, not a product you buy. Here's an honest breakdown of what it means, what analysts actually say, and why coverage gaps make the whole concept aspirational.