Why secret managers alone fail to govern NHI sprawl

At a glance

What this is: This is an analysis of why secret managers do not fully solve non-human identity governance in cloud-native environments.

Why it matters: IAM and NHI practitioners need a unified view of credentials, roles, and lifecycle state because fragmented control leaves blind spots, slows revocation, and expands blast radius.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

👉 Read GitGuardian's analysis of NHI sprawl across Vault, AWS, Kubernetes, and CI/CD

Context

Secret management is necessary, but it is not the same as NHI governance. In cloud-native estates, identities live across cloud IAM, Kubernetes, CI/CD systems, and vaults, so a single storage system cannot provide complete control over service accounts, tokens, certificates, and roles. That gap matters because the primary keyword here is NHI governance, and the core failure mode is fragmented visibility rather than a missing vault.

The article’s examples describe a familiar enterprise pattern: humans and automation both need credentials, but the workflows that issue, store, and revoke them are split across teams and tools. That creates operational friction for SREs and security teams, and it also makes least privilege, offboarding, and incident response much harder to execute consistently. The starting position is unfortunately typical in modern DevOps environments.

NHIMG analysis on the topic points to a broader lesson: the real control plane is not where secrets are stored, but where identities are discovered, mapped, and retired. Without that layer, organisations can automate credential delivery while still leaving orphaned access, duplicate secrets, and hidden blast radius behind.

Key questions

Q: How should security teams govern non-human identities across cloud and CI/CD systems?

A: Security teams should govern non-human identities with a single inventory, explicit ownership, and lifecycle controls that cover provisioning, rotation, review, and offboarding. The important test is whether you can trace each credential back to its issuer, its current use, and its retirement path. If you cannot, you do not yet have governance, only storage.

Q: What is the difference between secret management and NHI governance?

A: Secret management stores and distributes credentials, while NHI governance tracks the identity itself, its permissions, its ownership, and its lifecycle across systems. A vault can reduce exposure, but it does not tell you whether a service account is still needed, over-privileged, or orphaned. Governance answers those questions directly.

Q: When does a non-human identity become a higher-risk control problem?

A: An NHI becomes higher risk when it is reused across workloads, granted broad permissions, or left active after the workload changes. Risk rises further when multiple teams manage different parts of the lifecycle without one accountable owner. At that point, compromise of one credential can spread well beyond the original system.

Q: Why do cloud-native environments make NHI offboarding difficult?

A: Cloud-native environments make offboarding difficult because identities are distributed across cloud IAM, Kubernetes, secret stores, and CI/CD tools, and each system can have a different revocation process. If those systems are not connected by policy and ownership, credentials remain active after they should be retired. That creates lingering access and audit gaps.

Technical breakdown

Why secret manager centric control breaks down

A secret manager stores credentials, but NHI governance has to track the identity, its permissions, and the systems that mint or consume it. In cloud-native estates, a database password may be generated by a pipeline, a service account may live in Kubernetes, and a cloud role may be controlled in IAM. Those objects do not always synchronise cleanly, which means the same credential can exist in multiple places with different lifecycles. The result is not just duplication, but inconsistent revocation, access review, and ownership mapping. Practical implication: treat the vault as one source of evidence, not the full source of truth.

Practical implication: map every credential back to its issuing system and owner before you rely on rotation or offboarding.

How non-human identities create hidden blast radius

An NHI is any machine or workload identity that authenticates without human intervention, such as a service account, API key, token, or certificate. The governance challenge is that NHIs are often created by automation, inherited by pipelines, and forgotten once the workload changes. Because they can be over-privileged and reused across applications, a single exposed secret can represent many paths into production systems. This is why blast radius analysis matters: you are not only asking whether a secret is valid, but what it can reach if compromised. Practical implication: inventory permission scope alongside credential age and usage.

Practical implication: score each NHI by privilege, reuse, and reach before deciding what to rotate first.

Why lifecycle control is the missing architecture

Lifecycle control means provisioning, review, rotation, and offboarding are managed as one continuous process rather than separate tasks. That matters because many NHI failures happen after the identity is created, when ownership changes, a pipeline is retired, or a certificate outlives its intended use. If discovery is disconnected from lifecycle, organisations end up with zombie identities, stale keys, and orphaned access paths that remain active long after the workload has changed. In practice, governance needs state transitions, not just storage. Practical implication: build controls that can answer when the identity should exist, who owns it, and how it is removed.

Practical implication: tie every NHI to an explicit expiry or review event, not an open-ended administrative assumption.

Threat narrative

Attacker objective: The attacker aims to turn one exposed machine credential into broad, durable access across cloud and delivery systems.

1. Entry occurs through a leaked or misplaced credential in a CI/CD system, cloud IAM path, or Kubernetes secret store.
2. Escalation follows when the attacker uses reused or over-privileged NHI access to reach additional services and production assets.
3. Impact occurs when the attacker abuses that hidden access to move through systems that operations teams did not map as part of the same identity path.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secret storage is not NHI governance: the field still confuses where credentials are kept with how identities are controlled. That mistake leaves organisations with vault coverage but no reliable lifecycle, ownership, or blast-radius view. The practical conclusion is that inventory and policy enforcement must span the systems that issue, use, and retire NHIs.

Identity blast radius is the real risk metric: once NHIs are reused across pipelines, clusters, and cloud roles, the compromise of one credential can affect multiple services. The useful question is no longer whether a secret is protected in one tool, but how far an exposed identity can travel. Practitioners should make blast radius a first-class governance measure.

Lifecycle gaps create persistent risk debt: stale secrets, forgotten pipeline credentials, and unmanaged service accounts accumulate because no single team owns the full path from creation to removal. That is why offboarding and rotation are governance functions, not housekeeping tasks. The organisation that cannot retire identities cleanly is carrying avoidable exposure.

DIY observability often becomes governance debt: custom portals can improve visibility, but they also create a second system that must be maintained, secured, and integrated. That is a reasonable trade-off only if the organisation can staff it as a product, not a side project. Most teams should measure that cost against a dedicated governance model.

A central NHI control plane is becoming the category norm: the market is moving toward unified discovery, policy, and blast-radius analysis because fragmented tooling does not scale with cloud-native identity sprawl. That shift validates the need for NHI governance as its own discipline rather than a vault add-on. Practitioners should evaluate tooling based on how completely it maps identity state, not how many secret types it stores.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Another finding from the same research shows that 71% of NHIs are not rotated within recommended time frames, which leaves stale access active longer than most teams expect.
• For a lifecycle-focused follow-up, see NHI Lifecycle Management Guide for how provisioning, rotation, and offboarding should work as a connected process.

What this signals

Identity discovery is becoming a programme-level control, not a tool feature. As cloud estates spread across CI/CD, Kubernetes, and cloud IAM, teams need continuous mapping of where NHIs live and what they can reach. The practical implication is that access reviews must expand beyond human accounts and include service accounts, tokens, and certificates as first-class assets.

With 96% of organisations storing secrets outside of secrets managers in vulnerable locations, according to the Ultimate Guide to NHIs, the governance problem is structural rather than accidental. Practitioners should assume hidden secret stores exist and design detection, attestation, and revocation around that reality.

Blast-radius analysis is now a planning input for SRE and IAM teams. When one credential can sit in multiple platforms, the question is not only whether it is valid, but how much production it can touch before detection. Teams should use that lens to prioritise cleanup, reduce duplicated credentials, and shorten incident response paths.

For practitioners

• Inventory every machine identity across all control planes Build a single register that includes cloud roles, Kubernetes secrets, CI variables, tokens, and certificates, with owner, system of record, and expiry data. Use the inventory to find identities that exist in one tool but are consumed in another.
• Separate storage from lifecycle ownership Assign one accountable owner for provisioning, rotation, review, and offboarding for each NHI class. Do not let the vault team, platform team, and application team each assume the others are handling revocation.
• Measure blast radius before you rotate secrets Rank NHIs by privilege scope, reuse across applications, and reach into production systems, then prioritise the ones with the widest potential impact. This prevents rotation effort from being spent on low-risk identities while high-risk access remains active.
• Automate revocation checks in CI/CD and cloud IAM Add controls that verify whether a secret or role is still in use before it remains active. The goal is to catch zombie identities and orphaned access paths as part of normal change management.
• Use a central control plane for audit evidence Expose the identity inventory, policy breaches, and access state in one view so security and SRE teams can answer who has access, where it is used, and how it will be removed. That shortens incident response and reduces manual reconciliation.

Key takeaways

• Secret managers are necessary, but they do not replace NHI governance across cloud IAM, Kubernetes, and CI/CD systems.
• Hidden ownership gaps and duplicated credentials are the real operational risk, because they make revocation, audit, and blast-radius control incomplete.
• Organisations should manage NHIs as lifecycle objects with explicit inventory, ownership, and retirement rules, not as isolated secrets.

Key terms

• Non-Human Identity: A non-human identity is a machine, workload, or automation credential that authenticates without a person operating it directly. It includes service accounts, API keys, tokens, and certificates. In practice, NHIs need the same lifecycle discipline as human identities because they often carry broad, persistent access.
• Identity Blast Radius: Identity blast radius is the amount of systems, data, and privileges that a single credential can reach if it is compromised. It is a practical measure of consequence, not just exposure. For NHI governance, blast radius helps rank which identities require faster rotation, tighter scoping, and stronger monitoring.
• Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials across code, configuration files, pipelines, vaults, and collaboration tools. It usually develops when teams solve access problems locally instead of governing them centrally. The result is duplicated, stale, and hard-to-revoke secrets that weaken visibility and incident response.

What's in the full article

GitGuardian's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step scripts for collecting NHIs from AWS IAM, Vault, Kubernetes, and GitLab CI.
• Example code for identifying service-assumable AWS roles and listing project variables without exposing secret values.
• Implementation detail on building an internal developer portal or dashboard for cross-system NHI visibility.
• Discussion of GitGuardian NHI Governance features such as policy breaches, blast-radius analysis, and integration coverage.

👉 GitGuardian's full post shows the collection scripts, portal approach, and governance workflow details.

Deepen your knowledge

NHI lifecycle control, secret sprawl, and blast-radius reduction are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is dealing with fragmented Vault, cloud IAM, and CI/CD ownership, it is worth exploring.