Topic starter
23/02/2026 11:27 am
TL;DR: GitGuardian argues that Vault, cloud IAM, Kubernetes, and CI secret stores can still leave organisations without a reliable inventory of service accounts, keys, certificates, and other NHIs because ownership, visibility, and lifecycle control remain fragmented. Secret storage is only one layer of governance; the harder problem is governing where non-human identities live, what they can reach, and when they should be revoked.
Editorial analysis by NHI Mgmt Group, based on content published by GitGuardian: “SRE Playbook: A Guide to Discover and Catalog Non-Human Identities (NHI)”.
Key questions
Q: What breaks when secret managers are treated as the whole NHI programme?
A: The programme loses sight of identities that are created, stored, or consumed outside the vault, including cloud roles, Kubernetes secrets, and CI variables.
Q: Why does fragmented NHI ownership create security risk?
A: Because fragmented ownership breaks accountability.
Q: How can organisations tell whether NHI governance is actually working?
A: NHI governance is working when every machine identity has an owner, a purpose, a minimum-necessary entitlement, and evidence of rotation and review.
Practitioner guidance
- Build a unified NHI inventory Reconcile cloud IAM, Kubernetes, CI systems, and secret managers into one inventory that shows each identity, its owner, and its runtime location.
- Assign ownership to every non-human identity Require a named owner for service accounts, API keys, certificates, and pipeline credentials so orphaned identities can be reviewed and retired.
- Track revocation paths before incidents happen Document how each credential is disabled or rotated in every system that can issue or store it, including pipelines and cloud IAM.
Bottom line: Secret managers reduce exposure, but they do not resolve the broader governance problem created by NHI sprawl across cloud, CI, and Kubernetes.
What's in the full article
GitGuardian's full article covers the operational detail this post intentionally leaves for the source:
- The concrete cross-system inventory approach used to reconcile Vault, cloud IAM, Kubernetes, Jenkins, and GitLab identities
- Examples of the scripting pattern used to collect NHIs from AWS IAM and GitLab variables
- The managed NHI Governance feature set for discovery, policy enforcement, and blast-radius analysis
- The trade-off between a DIY internal portal and a dedicated governance platform for ongoing maintenance
👉 Read GitGuardian's analysis of why secret managers alone fail to govern NHI sprawl →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
07/10/2026 6:12 pm
Secret managers do not solve NHI governance by themselves. The governance gap is not storage but fragmented control over discovery, ownership, and lifecycle across multiple systems. Vault can hold secrets, but it cannot by itself reconcile cloud roles, CI variables, and Kubernetes secrets into one accountable identity model. The practitioner conclusion is simple: if the inventory is fragmented, governance is fragmented too.
A few things that frame the scale:
- Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
- 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What should organisations do when they have secrets in Vault but identities elsewhere?
A: They should treat Vault as one control point and build a governance layer that reconciles every other source of identity and secret creation. The priority is to map ownership, scope, and lifecycle across cloud IAM, Kubernetes, and CI so that revocation and review do not depend on tribal knowledge. That is the difference between storage and governance.
👉 Read our full editorial: Why secret managers alone fail to govern NHI sprawl