Why do scanners and vaults still leave NHI risk unresolved?

Why This Matters for Security Teams

Scanners and vaults are necessary controls, but they are not a complete operating model for NHI risk. Scanners tell teams where secrets appear; vaults centralise storage and rotation. Neither one, by itself, answers the harder question of which identities can still authenticate, what they can reach, and whether those credentials remain valid in production. That gap is why exposure often persists after the “find and store” phase is complete.

NHI risk becomes operational when secrets are duplicated, overused, or left active after the application that depends on them has changed. NHIMG research highlights that 62% of all secrets are duplicated and stored in multiple locations, which makes discovery and revocation uneven in practice; see the Guide to the Secret Sprawl Challenge and the broader Top 10 NHI Issues. From a governance perspective, that means visibility without authoritative control. Current guidance from the NIST Cybersecurity Framework 2.0 still requires organizations to manage identity, access, and recovery as an integrated control set, not as separate inventory and storage tasks.

In practice, many security teams discover the remaining NHI exposure only after a token is reused, a service account is overprivileged, or a stale credential is exploited in production rather than through intentional lifecycle governance.

How It Works in Practice

The practical failure is that scanners and vaults operate on different layers of the problem. Scanners are strongest at detection: they identify leaked API keys, embedded tokens, certificates, and credentials in source code, tickets, chat systems, and logs. Vaults are strongest at containment: they store secrets centrally, issue them to applications, and support rotation. But NHI governance also needs runtime knowledge of whether a credential is still live, what workload is using it, and whether that workload should continue to have access.

That is why mature programs add an identity and authorization layer around the secret itself. Instead of treating a secret as the identity, teams increasingly use workload identity, short-lived tokens, and policy checks at request time. In standards terms, this aligns with NIST CSF 2.0 and with guidance emerging across NHI research such as Ultimate Guide to NHIs. The point is not just to store secrets more safely, but to reduce standing exposure.

• Issue credentials just in time, with short TTLs and automatic revocation after task completion.
• Bind access to workload identity, not to a reusable static secret alone.
• Evaluate policy at runtime so the same workload can be allowed for one action and denied for another.
• Continuously reconcile what the vault believes exists with what is actually active in production.

When teams do this well, scanners become detection inputs and vaults become delivery infrastructure, while authorization and lifecycle governance provide the actual control plane. These controls tend to break down when legacy services cannot handle short-lived credentials because their authentication model still depends on static, long-lived secrets.

Common Variations and Edge Cases

Tighter secret rotation often increases operational overhead, requiring organisations to balance reduced exposure against application compatibility and engineering effort. Best practice is evolving here: there is no universal standard for how much rotation is enough, because the right answer depends on workload criticality, credential type, and deployment maturity.

One common edge case is the legacy application that cannot accept ephemeral credentials. In that environment, a vault can still improve storage and rotation discipline, but it does not remove the standing risk created by long-lived authentication material. Another case is multi-tenant or multi-service reuse, where one NHI supports several applications. That pattern makes vault coverage look strong while blast radius remains large. NHIMG’s 52 NHI Breaches Analysis and the Static vs Dynamic Secrets discussion both reinforce the same practical lesson: control quality depends on whether the secret is treated as a durable asset or a temporary proof of workload identity.

For teams operating mature zero trust programs, scanners and vaults should be considered enabling controls, not endpoint controls. The unresolved risk is not missing inventory. It is the absence of continuous, runtime authority over who or what can still use the credential.

Related resources from NHI Mgmt Group

• Why do leaked secrets remain such a persistent NHI risk?
• What makes idle secrets such a serious NHI risk?
• What is the main NHI risk in ServiceNow integrations?
• Why do Salesforce integrations increase NHI risk?