TL;DR: Backlogs swell when vulnerability tools score everything by presence rather than exploitability, according to Plerion, so teams end up spending time on criticals that cannot be used in their actual environment. Exploitability context, not raw CVE volume, becomes the only defensible way to triage risk and prove why one finding matters more than another.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Plerion's blog post: Vulnerability backlogs keep growing when teams treat every critical CVE as equally exploitable instead of testing whether it can actually be used in their environment.
Why it matters: IAM and security teams need exploitability-aware prioritisation because remediation capacity is finite, and the wrong ranking model burns engineering time on findings that never create real exposure.
Context
Vulnerability management breaks down when discovery is treated as the end state. A scanner can identify exposures, but it cannot on its own tell a practitioner whether the weakness is reachable, enabled, or even relevant to the live workload. That is why teams end up with large queues of critical findings that do not reflect operational risk.
Exploitability testing is the missing governance layer here. It asks whether the asset, configuration, runtime, and exposed service conditions actually let an attacker use the flaw, which is the difference between a paper vulnerability and an actionable one. In environments with many workloads and frequent change, that distinction is usually the difference between a manageable queue and a permanent backlog.
Key questions
Q: How do teams know if a vulnerability is truly exploitable?
A: They validate it in the live environment using safe testing that shows whether an attacker can reach the condition, trigger it, and move beyond it. Scanner data alone cannot answer that question reliably. Validation gives defenders evidence they can use to separate theoretical issues from immediate response priorities.
Q: Why do vulnerability backlogs keep growing even when teams work harder?
A: Backlogs grow because modern applications generate far more findings than humans can triage well, especially when multiple tools report the same issue. Severity-based queues also misdirect effort toward theoretical risk. Teams fall behind when they optimise for volume of findings processed instead of risk removed from exposed assets.
A: CVSS estimates how severe a vulnerability could be if exploited, while exploitability-based prioritisation focuses on whether exploitation is likely in practice. The first is a standardised severity metric. The second is a decision model that blends severity with threat intelligence, reachability, and environmental factors to guide which fixes should happen first.
Q: What should security teams do first when every vulnerability is marked critical?
A: Start with exploitability and exposure, not score bands. Cross-reference the backlog against known exploited vulnerabilities, public proof-of-concept availability, and internet exposure, then attach asset ownership and business criticality. That quickly isolates the small subset most likely to become incidents and prevents remediation capacity from being spent on theoretical risk.
Technical breakdown
Why severity scores overstate operational risk
Generic severity scoring ranks vulnerabilities as if every affected system shares the same operating conditions. In practice, exploitability depends on preconditions: operating system, service state, network reachability, hardware presence, library use, and feature flags. If those conditions are absent, the CVE may remain technically real but operationally irrelevant in that environment. This is why a critical score alone cannot decide priority. The useful unit of analysis is not the vulnerability in isolation, but the vulnerability plus the runtime context that can satisfy its preconditions. See the Vulnerability Management Guide.
Practical implication: Use runtime context to decide whether a finding belongs in the active remediation queue or the exception queue.
How context-aware evaluation changes triage
Context-aware vulnerability evaluation compares exploit requirements against the actual asset state. The control question is not whether a CVE exists somewhere in the catalogue, but whether the target host, service, or workload exposes the exact conditions an attacker needs. That shifts triage from volume management to evidence-based prioritisation. It also creates a cleaner split between non-exploitable, uncertain, and likely exploitable findings, which makes queues easier to defend to engineering and audit stakeholders. See the Vulnerability Management Buyer's Guide.
Practical implication: Rank findings by exploitability evidence, not by raw scanner output.
Why remediation workflows need closed-loop verification
A vulnerability programme only improves when the verdict becomes an action and the action is verified. Once exploitability is established, teams still need ownership, ticket creation, fix guidance, and post-remediation confirmation. Without that loop, even accurate prioritisation becomes another spreadsheet. Closed-loop handling also reduces duplicate work because one confirmed fix can eliminate multiple findings across assets and environments. See the AppSec Programme Metrics Guide.
Practical implication: Tie prioritised findings to tracked remediation and verify closure before removing them from exposure reporting.
NHI Mgmt Group analysis
Exploitability is the governance boundary that vulnerability management has ignored. Presence-based scoring treats every CVE as if it were equally reachable, but operational risk only exists when the environment satisfies the exploit preconditions. That means backlog size is often a poor proxy for exposure, and triage has to shift from counting findings to proving reachability. The practitioner conclusion is simple: prioritise the flaws that can actually be used, not the ones that merely exist in a database.
Vulnerability backlogs become decision debt when context is missing. Teams are not failing because they lack scanner output. They are failing because the output does not answer the question that matters to engineering, audit, or operations: can this be exploited here? The article's central pattern is a backlog full of false urgency, which forces security teams into manual interpretation instead of governed risk decisions. The practitioner conclusion is to make exploitability evidence part of the triage record, not an afterthought.
Operational severity is a more useful control concept than abstract severity. Severity without environment context is too blunt to guide scarce remediation capacity. The point is not to minimise vulnerabilities, but to separate the small subset that can move from theoretical weakness to live exposure. That is why this problem matters across cloud, code, and platform teams alike: the control failure is not detection, but prioritisation logic. The practitioner conclusion is to anchor remediation queues to evidence-backed operational severity.
Exploitable risk is a runtime property, not a catalogue property. A CVE can be critical in the abstract and harmless in a specific workload if the required service, architecture, or component is absent. That distinction becomes especially important in heterogeneous environments where asset state changes faster than manual review cycles. The practitioner conclusion is to treat runtime state as part of the vulnerability record, not as a separate operational concern.
Exploitability-aware triage creates a better identity and access governance pattern for infrastructure remediation. When security teams can prove that a finding is not reachable, they reduce unnecessary change requests and preserve attention for the assets that truly need privileged intervention. That matters because over-triage creates its own governance cost, including noisy approvals, rushed fixes, and poor ownership. The practitioner conclusion is to align vulnerability decisions with the evidence required to justify privileged remediation work.
What this signals
Exploitability-first triage: vulnerability programmes are moving toward runtime evidence as the deciding factor for queue placement. That shift matters because the old model rewards volume, while the new model rewards defensible decisions about what can actually be used against the environment.
Security leaders should expect more pressure to justify remediation prioritisation with asset state, service exposure, and runtime context rather than scanner severity alone. That changes reporting, because the board question becomes whether the team is reducing actual exposure, not whether the backlog is shrinking.
Exploitability evidence also changes the ownership model for engineering. When a finding is shown to be unreachable, the team can stop burning cycles on low-value fixes and redirect effort toward the systems that are both vulnerable and exposed.
For practitioners
- Gate remediation on exploitability evidence Require each high-priority finding to show the runtime conditions that make exploitation possible before it enters the urgent queue. See the Vulnerability Management Guide.
- Separate non-exploitable, uncertain, and exploitable findings Use distinct states for findings that are disproven, unresolved, or likely exploitable so engineers know what needs action now versus investigation later.
- Record the preconditions behind every deferral Store the OS, service state, network reachability, hardware, or feature requirement that makes a finding safe to deprioritise.
- Close the loop on fixes and revalidation Tie accepted findings to tracked remediation work and confirm the vulnerability is no longer exploitable after the change is applied.
Key takeaways
- Vulnerability backlogs grow when teams measure abundance of findings instead of actual exploitable exposure.
- A critical CVE is only urgent when the target environment satisfies the preconditions needed to use it.
- Exploitability-aware triage gives security and engineering teams a defensible way to focus remediation on real risk.
Related NHI Mgmt Group resources: Vulnerability Management Guide · AppSec Programme Metrics Guide · Vulnerability Management Buyer's Guide · Vulnerability Remediation Report Template for Executives
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | Exploitability testing is about whether an attacker can turn a weakness into usable access or movement. |
| Recommendation — Map likely exploit paths to ATT&CK and prioritise findings only when the environment enables those tactics. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Continuous vulnerability management is the control family this prioritisation problem sits inside. |
| Recommendation — Use CIS-7 to pair discovery with validation, prioritisation, and verified remediation. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset vulnerabilities are identified and recorded | Exploitability-aware triage depends on recording vulnerabilities with enough context to assess real risk. |
| Recommendation — Record vulnerability context alongside asset state so risk decisions are based on operational exposure. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | RA-5 is the baseline control for vulnerability discovery and prioritisation workflows. |
| Recommendation — Extend RA-5 so scan results are validated against runtime conditions before they are treated as urgent. | ||
Key terms
- Exploitability: Exploitability is the likelihood that a weakness can be turned into actual harm. In cybersecurity, it measures how readily an attacker can abuse a vulnerability, misconfiguration, exposed secret, or weak control, considering access required, available tools, and the value of the target asset or identity.
- Operational Severity: Operational severity is the level of impact or criticality assigned to an incident, alert, vulnerability, or service issue in operational security and IT workflows. It is usually set by factors such as business impact, affected systems, blast radius, and time sensitivity, and it drives prioritisation, escalation, and response handling.
- Continuous Vulnerability Management: Continuous Vulnerability Management is an ongoing process for finding, assessing, prioritising, and fixing security weaknesses across systems, applications, and identities. It combines frequent scanning, risk-based triage, remediation tracking, and verification so exposure is reduced before attackers can exploit known flaws, misconfigurations, or outdated components.
- Runtime Context: Runtime context is the set of signals used to judge whether an AI agent's behaviour is appropriate while it is acting. It includes identity, data access, model behaviour, posture, and environment. In practice, it is the difference between checking permission and evaluating purpose.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore the course when you need a structured baseline for governing access, secrets, and machine identities across your programme.
Published by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org