Should organisations compare exposure velocity with remediation speed or with total vulnerability counts?

Why This Matters for Security Teams

Counting vulnerabilities without measuring how fast exposure is changing creates a false sense of control. A queue of low-risk findings that is shrinking can be less urgent than a smaller set of exploitable issues that is spreading across hosts, images, identities, or agent workflows. For NHI-heavy environments, that distinction matters because secrets, service accounts, and API keys can be reused, cloned, or inherited faster than conventional review cycles can catch up.

NHIMG’s research shows why speed matters: Ultimate Guide to NHIs notes that 91.6% of secrets remain valid five days after notification, which means exposure can outlast the team’s first response window. That gap is also visible in breach analysis and secret-sprawl research, where standing access and lingering credentials create a larger attack surface than the raw count suggests. Current guidance from CISA cyber threat advisories and NIST control thinking favors time-to-remediate and exposure reduction over simple inventory totals.

In practice, many security teams discover the real risk only after exposure has already propagated across environments, rather than through intentional trend monitoring.

How It Works in Practice

The most useful operating model compares exposure velocity to remediation speed over the same asset set, severity band, and time window. That means tracking how quickly new exploitable findings appear, how long they remain reachable, and whether the team is reducing the exposed population faster than attackers can exploit it. For NHI governance, this should include secrets, tokens, service accounts, certificates, and any automation identity that can be reused by pipelines or agents.

A practical approach is to measure three things together: first, the rate at which externally reachable or privilege-bearing issues are introduced; second, the mean time to revoke, rotate, patch, or isolate them; and third, the percentage of exposures that reappear after remediation. This is where Guide to the Secret Sprawl Challenge is useful, because secret proliferation usually shows up as repeated exposure across repos, build systems, and runtime configs. Pair that with platform evidence from The State of Secrets in AppSec, which highlights a 27-day average time to remediate leaked secrets. That lag is far more informative than a static vulnerability count.

Operationally, teams should align the metric to decision-making:

• Use counts for backlog sizing, not for risk prioritisation.
• Use exposure velocity to spot when new weaknesses outpace containment.
• Use remediation speed to test whether response capacity is keeping up.
• Track recurrence to detect weak fixes, hidden duplicates, or failed revocation.

Best practice is to slice these metrics by asset type and blast radius, because a small number of high-reach exposures can dominate actual risk. These controls tend to break down in highly ephemeral cloud and agentic environments because assets, secrets, and permissions change faster than scanning and ticketing workflows can reconcile them.

Common Variations and Edge Cases

Tighter exposure tracking often increases operational overhead, requiring organisations to balance richer telemetry against analyst fatigue and tooling complexity. That tradeoff becomes especially visible when leaders want a single KPI to rank all risk, but different environments behave differently. A product team shipping daily may need velocity-based thresholds, while a legacy estate with slow release cycles may benefit more from exposure-age thresholds and exception handling.

There is no universal standard for this yet, but current guidance suggests treating total vulnerability count as a volume indicator and exposure velocity as the real risk signal. In environments with strong compensating controls, such as strict network isolation or short-lived credentials, raw counts may overstate urgency. In contrast, in systems with reused secrets or broad service-account permissions, a low count can still represent high impact if the same exposure is reachable in many places.

This is particularly important for agentic or automated systems, where a single exposed token can be chained across tools and workflows. NHIMG’s 52 NHI Breaches Analysis and the OWASP NHI Top 10 both reinforce that identity exposure, not just defect count, is what drives real-world compromise. That is why the better question is not “how many issues exist,” but “are we reducing exposure faster than it is spreading?”

Related resources from NHI Mgmt Group

• Should organisations track remediation speed or exposure reduction first?
• Should organisations use exposure metrics instead of traditional vulnerability counts?
• How should organisations prioritise remediation when data exposure findings are broad?
• What should organisations measure before trusting machine-speed remediation?