EPSS and CRA Triage: What to Do When a Vulnerability Lands

A Score Isn’t Enough: What “Risk-Based” Means Under the CRA

Every time a vulnerability is disclosed that affects one of your products, you likely have a triage process to determine how to respond. That triage process may require you to answer questions about the vulnerability’s severity and prevalence across your products, research how hard it would be to immediately mitigate and ultimately to fix, and to guess how likely it would be for the vulnerability to result in an incident.

That process is logical, responsible, and common. But it misses an important question: is this CVE reachable in my product? If you can confidently answer “no”—and back it up with evidence—then you can skip the triage entirely.

The CRA doesn’t prescribe a specific assessment methodology. Instead, it expects manufacturers to make risk-based decisions: a defensible judgment about each vulnerability in your product, documented well enough that a regulator, an auditor, or a customer can follow your reasoning after the fact.

That is manageable in small pieces and challenging at scale. A typical connected product carries thousands of known vulnerabilities, many of them inherited from third-party and open-source components, with some sitting in code that has not been touched in years. You cannot fix all of them, and the CRA does not ask you to. It asks you to decide, based on objective evidence, which ones warrant action and which can wait. The hard part is making that call quickly, consistently, and with documentation that you can stand behind months later.

Severity and Exploitability Are Only Part of the Solution

Most teams start with severity scoring. A Common Vulnerability Scoring System (CVSS) rating tells you how much damage a vulnerability could do if it were exploited under worst-case assumptions. It says nothing about the likelihood of actual exploitation, or whether that vulnerability is a concern in the product you shipped. Teams that prioritize only by severity aren’t making a true risk-based distinction, and they’re likely to spend time fixing the wrong vulnerabilities.

The Exploit Prediction Scoring System (EPSS) partially addresses this gap. EPSS estimates the probability that a given vulnerability will be exploited in the wild in the near term, on a scale from 0 to 1. This is a valuable signal to security teams in understanding whether they are likely to experience a worst-case scenario. But EPSS, like CVSS, is a global assessment of the vulnerability, and necessarily misses the context of the vulnerability within your specific product.

Take, for example, a vulnerability with an EPSS score of 0.9 that sits within a library that never compiles, or in a function never called by your firmware. Even if the vulnerability is exploited, it is unreachable in your product. Time spent remediating that vulnerability doesn’t make the product safer, and it comes at the cost of addressing other risks.

The Missing Piece: Reachability

A true risk-based decision depends on a third variable: whether the vulnerable code is present and reachable in the product you shipped. Knowing the answer for each product and firmware version allows you to get real risk reduction with limited resources. A vulnerability that is both likely to be exploited and reachable in your firmware is a real priority. One that is unreachable in your build, even if it is critically severe, can be set aside.

Making that reachability determination can be tricky, especially if you don’t have access to the original source code for your device. Maybe the code was developed by a third-party, or you no longer provide support. This is where Finite State can help: we analyze the compiled firmware binary to confirm whether the vulnerable function is present and reachable, without needing the source code. The reachability determination is grounded in what actually shipped, not based on a guess about libraries that may not end up in the build.

When a Disclosure Lands

Beginning in September, manufacturers are on a tight clock to make decisions about how to manage new vulnerabilities, especially once they have been actively exploited. Under that kind of pressure, you don’t want to waste time triaging vulnerabilities that don’t affect your products. You want to know what you’re shipping, determine reachability quickly and automatically for every new vulnerability, and have the evidence to support a confident risk-based decision.

That is the program that the CRA requires manufacturers to run, and that is the program Finite State can help you build.

If you want to see what risk-based vulnerability decisions look like for your specific products, we will walk your team through it. Request a CRA consultation.