Turn CVSS + EPSS into a risk score that actually matches your environment.
Vulnerability Risk Model (VRM) 3.0 is a context-aware approach to vulnerability management. It blends technical severity, exploit probability, and enterprise business context to reduce noise, accelerate remediation, and focus effort on the vulnerabilities that matter most.
At the core of VRM 3.0 is a simple idea:
the same CVE on two different systems does not represent
the same risk. We express that with a model of the form
Criticality = Base × Risk + Context Modifier, where
Base is CVSS, Risk is EPSS (or equivalent), and
Context captures data sensitivity, system criticality,
OS lifecycle, vulnerability density, and age.
Why traditional severity models fall short
Most vulnerability programs still rely on static scores like CVSS or broad assumptions such as “our EDR will catch it.” Those signals are important, but on their own they don’t answer the questions that matter most to the business: How likely is this to be exploited? and What happens to our data, operations, and compliance posture if it is?
CVSS: impact without likelihood
CVSS describes how technically severe a vulnerability can be under generic conditions. It does not know which systems in your environment are internet-facing, store PHI or PII, or sit in the middle of critical business workflows. Thousands of “critical” findings can easily hide the handful that truly threaten the business.
EPSS: likelihood without business impact
EPSS brings data-driven exploit probability, answering, “How likely is this CVE to be exploited in the next 30 days?” But it is still generic: it doesn’t know where the vulnerable asset lives, what data it holds, or what would break if it goes offline.
Risk is context: Likelihood × Impact
Enterprise risk frameworks (ISO 31000, NIST, etc.) treat risk as a function of likelihood × impact. VRM 3.0 applies the same principle to vulnerability management by combining CVSS (impact), EPSS (likelihood), and asset context into a single, dynamic risk score.
The Vulnerability Risk Model (VRM) 3.0
VRM 3.0 doesn’t replace CVSS or EPSS — it orchestrates them. It treats each as an input to a broader risk equation and layers on business context so that every vulnerability on every system gets a criticality score grounded in how your organization actually operates.
VRM 3.0 expresses risk as:
Criticality = Base × Risk + Context Modifier
- Base (CVSS): The technical severity of the vulnerability, typically the CVSS v3.x Base score (0–10). Where CVSS isn’t available, a compatible base score (for example, from OWASP risk models) can be used instead.
- Risk (EPSS): The probability that the vulnerability will be exploited in the next 30 days, usually from EPSS (0–100%). Other threat-informed sources can be substituted when EPSS is not available.
-
Context Modifier: A set of additive
modifiers that reflect how this specific system is used,
including:
- Presence of PHI, PII, or other sensitive data
- System business criticality and dependencies
- OS end-of-life status
- Vulnerability density on the asset
- Age of the vulnerability in your environment
The result is a dynamic score that changes as your assets, data, and threat landscape evolve — not a static label assigned the day the CVE was published.
From severity-only to context-aware risk
- 1.0 – CVSS era: CVSS v1 (2005), v2 (2007), v3.0 (2015), v3.1 (2019), v4.0 (2023). Excellent for describing impact, but not real-world likelihood of exploitation.
- 2.0 – EPSS era: EPSS v1.0 (2021), v2.0 (2022), v3.0 (2023). Excellent for predicting exploitation, but not the business impact of a breach.
- 3.0 – VRM (2025): Combines CVSS and EPSS into a unified risk score, focusing remediation on vulnerabilities with the highest real-world impact.
- 3.1 – VRM + Context (2025): Adds system business risk modifiers, OS end-of-life, vulnerability density, and other asset-level context.
- 3.2 – VRM + Habits (2025): Introduces age-of-vulnerability as a modifier so long-lived issues naturally rise in criticality, creating healthy pressure to close out “forever findings” instead of living with them indefinitely.
Fluctuations: risk that moves with your business
Risk is not static. A vulnerability that looked harmless last quarter may become critical today because:
- An application starts processing PHI/PII due to a new feature or AI initiative.
- An OS transitions into end-of-life and loses vendor support.
- Threat actors begin actively targeting a previously obscure vulnerability, driving EPSS sharply upward.
VRM 3.0 embraces this reality. As context and threat signals change, so does the criticality score, keeping your prioritization aligned with the current risk landscape.
Remapping: no model is perfect
Even the best model needs human judgment. VRM 3.0 expects and encourages severity remapping by your enterprise vulnerability management team:
- Review outliers where the score doesn’t match intuition
- Document approved overrides and rationale
- Feed lessons learned back into the model over time
This creates a feedback loop: the more you use the model, the better it reflects how your organization actually sees and manages risk.
VRM 3.0 encourages healthy vulnerability management habits
VRM 3.0 is not just better math; it’s a way to build healthier, more sustainable behaviors in security, IT, and application teams. The model is intentionally designed to reward the practices you want more of: good inventory, clean architectures, and prompt closure of long-lived risk.
Less noise, more meaningful action
By focusing on likelihood, impact, and context, VRM 3.0 helps teams move away from “patch everything” toward reduce meaningful risk.
- Fewer “critical” findings that aren’t truly urgent
- Clearer guidance on what to fix first on each asset
- Stronger alignment with business outcomes like data protection, operational continuity, and compliance (HIPAA, PCI DSS, FedRAMP, and more)
System owners are no longer overwhelmed by static dashboards; they see a prioritized roadmap of what actually matters.
Good habits, built into the model
The context modifiers in VRM 3.0 and beyond are chosen to nudge organizations toward mature behaviors:
- Data classification: Knowing where PHI, PII, and other sensitive data lives becomes directly relevant to vulnerability risk.
- Asset and application inventory: You can’t assign meaningful criticality without knowing what a system does and who depends on it.
- Lifecycle management: End-of-life OS and high vulnerability density increase risk, reinforcing the value of modernization and rationalization.
- Timely remediation: Age-based modifiers in VRM 3.2 make it increasingly expensive to ignore issues that linger year after year.
Over time, these incentives help teams work smarter, not just harder, by spending energy where it meaningfully reduces risk.
VRM 3.0 is going to be published soon.
The reference model, scoring details, and implementation guidance for VRM 3.0 are being finalized now, with follow-on 3.1 and 3.2 phases that introduce richer context and healthy aging modifiers. If you’re interested in aligning vulnerability management with how your business actually measures risk, we’d love to keep you informed.
You can also monitor future public repositories and integrations that bring VRM 3.x into common vulnerability management and ticketing workflows.