TL;DR: Only 2-7% of published vulnerabilities are ever seen exploited in the wild, according to ArmorCode's analysis, which argues that CVSS-only queues push teams toward volume over real exposure. Risk-based remediation becomes defensible when severity, likelihood, business context, and reachability are combined into one ranked decision model.
At a glance
What this is: ArmorCode's analysis says vulnerability remediation fails when teams rank findings by CVSS alone instead of combining severity with exploit likelihood, business context, and reachability.
Why it matters: IAM and security teams need risk-based remediation because exposure is determined by what is reachable and exploitable, not by abstract score volume or ticket closure rates.
Context
Vulnerability remediation often fails when teams treat every finding as equally urgent. A static severity score does not tell you whether a flaw is exposed, reachable, or meaningful to the business, so the queue fills with work that looks important but does not reduce real risk.
This is a governance problem as much as a technical one. In practice, prioritisation needs to reflect exploitability, asset criticality, data exposure, and runtime reachability, especially where application code, cloud services, and identity-linked access paths intersect.
The article's core position is typical of mature exposure management thinking: teams that keep trying to close everything end up measuring throughput instead of risk reduction.
Key questions
Q: How should teams prioritise NHI vulnerabilities when CVSS and EPSS disagree?
A: Treat disagreement as a signal to look at exposure and privilege, not as a reason to pick one score and ignore the other. CVSS shows severity, EPSS shows likelihood, and the deciding factor should be whether the affected NHI has meaningful reach, reuse, or delegated access.
Q: Why do severity scores fail in modern vulnerability management?
A: Severity scores describe the bug, not the environment. A high CVSS score on a dead code path can matter less than a medium score on an internet-facing asset with real data access. Modern programmes fail when they treat every critical as equal instead of asking whether the issue is reachable, exploitable, and business-relevant.
Q: How do you know if vulnerability prioritisation is working?
A: You should see fewer blocking tickets, faster remediation on exploitable issues, and better alignment between security work and business risk. If developers are constantly interrupted by findings that never matter, the model is still severity-led. A good programme can explain why some issues are deferred without losing auditability.
Q: When should organisations treat a medium-severity vulnerability as more urgent than a critical one?
A: When the medium-severity issue is on a reachable, internet-facing, or business-critical system and the critical flaw is isolated, blocked, or otherwise unlikely to be exploited. Prioritisation should follow exploitable exposure, not a score that ignores environment, data sensitivity, and attack path.
Technical breakdown
Why CVSS becomes a weak prioritisation signal
CVSS describes how severe a flaw could be under worst-case assumptions, but it is not a prioritisation model. It does not know whether the asset is internet-facing, whether the vulnerable code path is reachable, or whether compensating controls already break the attack path. That makes CVSS useful as a common language and poor as a queue manager. In practice, treating severity as priority turns remediation into a volume exercise, where the loudest score wins even when the real exposure is elsewhere.
Practical implication: Use CVSS as one input, not the final ranking mechanism.
How EPSS adds exploit likelihood to the queue
EPSS estimates the probability that a vulnerability will be exploited in the next 30 days, which makes it a fundamentally different signal from severity. A high CVSS score with a low EPSS score may represent theoretical damage, while a moderate score with a high EPSS value may reflect active attacker interest. That distinction is what changes remediation order. Without likelihood, teams are forced to assume all serious flaws are equally urgent, even when the threat landscape says otherwise.
Practical implication: Prioritise findings with both material impact and high near-term exploit probability.
Why reachability analysis filters out false urgency
Reachability analysis asks whether an attacker can actually trigger the vulnerable code in your deployment. A flaw in a library or component may exist on paper, but if the function is never called, or the runtime path is blocked, remediation priority drops sharply. This is where code-level vulnerability data becomes operationally useful. Reachability helps separate exploitable exposure from scanner noise, which is especially important when teams are drowning in tens of thousands of findings.
Practical implication: Gate remediation on whether the vulnerable path is reachable in your environment.
Threat narrative
Attacker objective: Exploit the small set of vulnerabilities that are both reachable and worth attacking, while defenders are distracted by low-value queue volume.
- Entry begins when a published vulnerability enters the scanner queue, often long before anyone confirms whether it is exploitable in the environment.
- Escalation occurs when severity-only workflows elevate every critical or high finding, regardless of exploit likelihood, business impact, or code reachability.
- Impact follows when teams spend remediation capacity on theoretical flaws while reachable, attacker-relevant exposures remain open and unaddressed.
Breaches seen in the wild
- ShinyHunters FBI breach claim 2026: ShinyHunters claims it used a PeopleSoft flaw to breach the FBI and pivot into AWS GovCloud; the FBI has confirmed only an investigation.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
CVSS-only remediation is exposure theatre: when teams rank everything by severity, they optimise ticket throughput rather than risk reduction. That approach assumes the score is the problem, when the real issue is whether the flaw is reachable, valuable to an attacker, and relevant to the business. The practical conclusion is that remediation governance must be built around exposure, not queue volume.
Dynamic risk scoring is now the sane operating model: severity, exploit likelihood, business context, and reachability belong in one decision framework because no single signal is sufficient on its own. This does not remove analyst judgment, it makes that judgment defensible. For practitioners, the important shift is from triage as a backlog-management task to triage as a risk-selection function.
Remediation programmes should be measured by risk retired, not tickets closed: if the highest-exposure items are not moving first, the programme is failing even when SLA dashboards are green. That is especially relevant in environments where application findings, cloud exposure, and identity-linked access paths converge. The right conclusion is that queue health is not a security outcome.
Reachability blindness: the central failure mode in vulnerability operations is assuming that presence in a scanner output equals practical exploitability. That assumption breaks as soon as code paths are unused, blocked, or isolated by runtime controls. Practitioners should treat reachability as the control boundary that decides whether a finding deserves operational attention.
From our research library:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.
- Only 26% of known exploited vulnerabilities were fully remediated in 2025, down from 38% the year before, according to Verizon's 2026 Data Breach Investigations Report.
What this signals
Exposure management only works when prioritisation follows exploitability, not inventory volume. Teams that keep severity as the main queueing rule will continue to spend capacity on findings that never become incidents, while the attack surface that matters remains under-managed.
Reachability is the control boundary that changes remediation economics. Once practitioners remove findings that cannot actually be triggered, the remaining queue becomes small enough to govern and far more likely to reflect real operational risk.
A mature programme treats exploit likelihood and runtime reachability as the practical filters that turn vulnerability management from a ticketing exercise into an exposure-reduction discipline.
For practitioners
- Build a four-signal prioritisation model Rank vulnerabilities using severity, exploit likelihood, business context, and reachability in one workflow so analysts are not forced to triage separate lists.
- Separate exploitable from theoretical findings Use reachability analysis to suppress issues that cannot be triggered in your runtime environment, especially in dependencies that are present but not executed.
- Tie remediation to business exposure Weight internet-facing assets, regulated data, and revenue-critical systems above isolated or non-production environments when the same vulnerability appears in both.
- Measure risk retired, not ticket volume Track whether the highest-risk findings are being cleared first and whether exposure on critical assets is actually declining over time.
Key takeaways
- CVSS alone cannot tell teams which vulnerabilities create real exposure in their environment.
- A defensible remediation model combines severity, exploit likelihood, business context, and reachability.
- Programmes should measure success by risk reduced on critical assets, not by the number of tickets closed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 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 — Credential Access | The article is about exploitable vulnerability paths that attackers use to gain access. |
| Recommendation — Map high-priority exposures to TA0006 and focus remediation on flaws attackers can realistically reach. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset vulnerabilities are identified and documented | The article centers on assessing vulnerability risk in context, not just listing findings. |
| Recommendation — Use risk assessment to rank vulnerabilities by exposure, not by scan volume alone. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | This is directly about improving vulnerability prioritisation and remediation flow. |
| Recommendation — Apply continuous vulnerability management to sort findings by exploitability and business impact. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | The article discusses how vulnerability findings should be monitored and prioritised. |
| Recommendation — Use RA-5 to govern vulnerability identification with prioritisation criteria beyond severity scores. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | The article includes environmental reachability and exposed attack paths, which often stem from misconfiguration. |
| Recommendation — Check whether exposed attack paths create API misconfiguration risk before escalating findings. | ||
Key terms
- Exploit Prediction Scoring System: A daily-updated score that estimates the likelihood a vulnerability will be exploited in the near term. It does not replace severity scoring, but it adds probability context that helps teams order work before exploitation becomes widespread.
- Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
- Business Context: Business context is the interpretive layer that explains what a dataset means, who owns it, how trustworthy it is and where it came from. In governance programmes, it turns raw metadata into something practitioners can use for accountability, access decisions and audit evidence.
- Dynamic risk score: A continuously updated value that represents how risky a session, device, or user looks right now. In identity programmes, it is used to change access outcomes such as granting, stepping up verification, narrowing entitlements, or denying connections.
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 NHI Foundation Level course, the industry's only accredited NHI security programme, if you are building governance across identity and access programmes.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org