Vulnerability management is failing because the metric is wrong

At a glance

What this is: This analysis argues that vulnerability management has become an activity-driven industry that measures tickets and scores findings instead of reducing real exposure paths.

Why it matters: That matters to IAM, PAM, and identity teams because exploitability is often shaped by identity paths, permissions, and reachability, not by scanner output alone.

By the numbers:

• In 2020, the average time to remediate a software vulnerability was 171 days.
• In 2025 it was 252 days, a 47% increase in five years.

👉 Read JupiterOne's analysis of why vulnerability management metrics are failing

Context

Vulnerability management is supposed to reduce exploitable weakness, but in many environments it has become a process for closing findings rather than closing risk. That shift matters because real exposure is shaped by reachability, privilege, compensating controls, and identity paths, not by the size of the scanner queue.

The identity connection is direct: service accounts, over-privileged access, stale credentials, and weak entitlement boundaries often determine whether a vulnerability is actually reachable. For IAM, PAM, and NHI teams, the problem is not only patch cadence but whether access pathways let an attacker turn a software flaw into a usable foothold.

Key questions

Q: How should security teams measure whether vulnerability management is actually reducing risk?

A: Security teams should measure exposure reduction, not just remediation activity. The most useful signals are the number of attacker-reachable paths eliminated, the count of crown jewels with zero viable paths, and whether closure was validated in the asset graph. If dashboards mainly show scan coverage and tickets closed, the programme is reporting work, not resilience.

Q: Why do identity and privilege controls matter in vulnerability management?

A: Identity and privilege controls determine whether a vulnerability is reachable and exploitable. A flaw on an isolated system is very different from the same flaw on an asset that a privileged service account, workload, or admin path can reach. IAM and PAM shape blast radius, so exposure management must include entitlement design and access paths.

Q: What do teams get wrong when they prioritise vulnerabilities only by score?

A: They assume a high score equals the right work. In practice, score-only prioritisation ignores reachability, compensating controls, and business context, so teams may spend heavily on findings that are unlikely to be exploited while missing exposed assets that connect directly to critical systems. Prioritisation should rank paths, not isolated CVEs.

Q: Who is accountable when a vulnerability creates a real exposure path?

A: Accountability should sit with the owner of the asset, platform, or identity path that makes the weakness reachable. Security can detect and coordinate, but remediation must land with the team that can remove the path and validate the fix. Governance should require evidence of closure, not just evidence that a ticket was opened or updated.

Technical breakdown

Why finding lists do not equal exposure paths

A vulnerability list describes software, versions, and known weaknesses. It does not describe whether the asset is reachable, whether a compensating control blocks exploitation, or whether the asset sits on a path to something valuable. That is why a list-based model can look busy while the business risk remains unchanged. Exposure is a graph problem, because attackers move through relationships: network reachability, trust links, permissions, and identity inheritance. When those relationships are missing from prioritisation, teams optimise on noise instead of exposure.

Practical implication: Model assets as paths and relationships, not isolated findings.

Why prioritisation models still miss the real unit of risk

RBVM, EPSS, and similar approaches improve ranking, but they still rank findings rather than redesigning exposure. The article’s central critique is that a highly prioritised ticket is still a ticket, not a closed attack path. If the work ends when a finding is acknowledged, the programme has measured activity, not reduction in exploitable conditions. That is especially weak in environments where identity and privilege decisions determine reachability more than the CVE itself.

Practical implication: Prioritise remediation by reachability and business context, not score alone.

How exposure engineering changes remediation

Exposure engineering treats non-exploitability as the goal. The work starts with an asset graph, adds business context, and routes remediation to the real owner who can close the path. It also validates that closure by re-checking the graph after the fix, rather than assuming a closed ticket equals reduced risk. This is where security, infrastructure, and application teams converge on one outcome metric: no viable path from an attacker-reachable position to a crown jewel.

Practical implication: Validate path closure in the graph, not just ticket closure in ITSM.

Threat narrative

Attacker objective: The attacker objective is to convert an exposed weakness into a reachable path toward high-value systems and then use that path for compromise, theft, or disruption.

1. Entry occurs when an attacker reaches an internet-exposed asset or other attacker-reachable system with a known weakness.
2. Escalation follows when the asset’s permissions, trust relationships, or compensating control gaps let the attacker turn that weakness into meaningful access.
3. Impact occurs when the path leads to a high-value system, data store, or privileged control plane that expands blast radius.

NHI Mgmt Group analysis

Activity metrics have become a proxy for security, and that proxy is now failing. The article’s central argument is that vulnerability management has drifted into measuring scanner coverage, ticket throughput, and SLA compliance instead of exposure reduction. That is a governance failure, not just an operational one, because the programme optimises the wrong unit of work. For identity leaders, the parallel is obvious: access reviews that count completions but miss standing privilege are just as hollow.

Exposure is an identity problem as much as a software problem. A vulnerability becomes dangerous when identity, permission, and reachability lines up with the flaw. That means IAM, PAM, and NHI governance are not adjacent controls in the VM story, they are part of the exposure surface. If a service account or over-privileged workload can reach a vulnerable asset, the weakness is materially different from the same CVE on an isolated host. Practitioners should treat entitlement design as exposure engineering.

Path closure is the right security outcome, not ticket closure. The article is strongest when it reframes success as removing viable attack paths to crown jewels. That aligns with broader Zero Trust and least-privilege thinking, but it goes further by demanding graph-based validation after remediation. For identity programmes, the implication is that privilege reduction and reachability control must be measured against exploit paths, not against audit artifacts.

Vulnerability management has an identity blind spot that boards rarely see. The text makes clear that external attestations still reward activity language such as scan cadence and patch-within-N-days. That creates a structural gap between compliance evidence and actual resilience. The named concept here is exposure-path closure, the discipline of proving that no attacker-reachable path remains to a high-value asset. Practitioners should push for outcome language in both security reporting and governance reviews.

AI is not creating the problem, it is collapsing the defender’s buffer. The article’s AI discussion shows that machine-speed discovery removes the time cushion that made list-based vulnerability management survivable. For identity teams, this matters because attacker speed now amplifies any standing access or stale entitlement that exposes an exploit path. The programme response has to shift from queue management to continuously verified path suppression.

What this signals

Exposure-path closure is the governance shift that vulnerability teams are being forced to make. The next phase of programme maturity will be measured less by scan coverage and more by whether teams can prove that no attacker-reachable path remains to critical assets. That aligns naturally with NIST Cybersecurity Framework 2.0 thinking, but the operational test is whether the graph changes after remediation.

For identity-led programmes, the vulnerability discussion should now include the state of service accounts, workload permissions, and privileged trust relationships. Where those identities can reach a vulnerable system, the issue is not just patching speed but blast-radius control. That is why identity governance and exposure engineering are converging in the same board-level conversation.

The scale of the NHI problem is already large enough to make this convergence unavoidable. Only 1.5 out of 10 organisations are highly confident in securing NHIs, which is a warning that identity paths can still outlive the controls meant to govern them. Teams that can model and continuously validate identity-linked exposure will have a clearer risk picture than teams that only report on remediation throughput.

For practitioners

• Shift the primary metric from tickets closed to paths closed Replace SLA-heavy dashboards with measures such as internet-exposed assets removed, crown jewels with zero reachable paths, and validated closure in the asset graph. Keep ticket data for workflow, but do not confuse workflow completion with reduced exposure.
• Map identity and privilege into every exposure review Add service accounts, workload permissions, and privileged trust relationships to remediation analysis so a vulnerable asset is judged by who or what can reach it. This is where IAM and NHI teams need to sit in the exposure workflow, not after it.
• Route remediation to the true asset owner Send cases to the platform team, SaaS admin, developer, or IAM owner who can actually remove the path, rather than dropping everything on a generic patch queue. Ownership should follow the graph, not the vulnerability category.
• Validate closure after every fix Re-test the asset graph after remediation to confirm the exploit path no longer exists. A closed ticket without a validated graph change is only paperwork, not risk reduction.
• Push audit language toward outcome-based evidence Start translating internal reporting away from scan cadence and patch timing toward demonstrated reduction in reachable exposure. That gives you a cleaner story for compliance reviews while also aligning security reporting to real attack conditions.

Key takeaways

• Vulnerability management is failing when it measures remediation activity instead of proving that attack paths have been removed.
• Identity and privilege relationships are part of the exposure surface, because they determine whether a flaw is actually reachable.
• The practical shift is from closed tickets to validated path closure, with remediation owned by the team that can remove the exposure.

Key terms

• Exposure Path: An exposure path is the chain of reachability, trust, identity, and permission relationships that lets an attacker turn a weakness into a usable compromise route. It is more useful than a raw finding list because it describes whether the vulnerability can actually be reached from an attacker position.
• Blast Radius: Blast radius is the amount of damage a compromised asset can cause once an attacker gains access. In identity-heavy environments, it is shaped by privilege, service account scope, trust links, and downstream system access, not just by the vulnerability itself.
• Exposure Engineering: Exposure engineering is the discipline of designing systems so that exploitable paths are removed, not merely tracked. It combines asset modelling, identity controls, remediation routing, and post-fix validation to prove that a weakness is no longer reachable or useful to an attacker.
• Validated Closure: Validated closure means confirming that a remediation action actually removed the exploitable condition, usually by re-checking the asset graph or control state after the fix. It is stronger than closing a ticket because it proves the risk path no longer exists.

What's in the full article

JupiterOne's full analysis covers the operational detail this post intentionally leaves for the source:

• How the JupiterOne graph model groups findings into remediation cases by ownership rather than category
• How Blast Radius Risk Factor identifies when a vulnerable asset sits on a path to a customer-defined crown jewel
• How bidirectional ITSM closure re-checks the path after remediation instead of relying on ticket status alone
• How application-level coverage extends the model into transitive dependencies and software CPE resolution

👉 JupiterOne's full post covers the path-based remediation model, blast radius logic, and operational shifts in detail

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in a practitioner-focused format. It helps identity and security teams connect access controls to real exposure reduction across modern environments.