How KROMSE assesses risk
Your risk is a level from Low to Critical for each finding. It starts from how serious the flaw is, then moves up or down using what we know about the flaw and about your product. Every step is written down, so you can see why a finding is ranked where it is.
Your risk is one of four levels: Critical, High, Medium or Low. It tells you which findings to look at first for this product. It is not a probability that you will be attacked, and it is not a legal classification. The CRA class it uses is the one you declare for your product; KROMSE does not decide it for you.
Every level is built from the same four inputs. The first two come from the finding. The last two come from what you tell us about your product.
1
We start from the flaw's severity: the higher of the scanner's own label and the published rating of the vulnerability. We never start below what the scanner says.
2
Whether the flaw is on the CISA list of known exploited vulnerabilities, how likely exploitation is (the EPSS score), and whether your own code reaches the vulnerable part.
3
Who uses it, including the sectors named in the EU NIS2 directive. Whether it belongs to a product category the EU Cyber Resilience Act calls important or critical. Whether it runs on an industrial network. And the worst thing an attack could cause.
4
Yes, partly or no. A flaw an attacker can reach from the internet is more urgent than one that sits behind a firewall.
The last two inputs come from four questions KROMSE asks about each product: who uses it, what it is, whether it can be reached from the internet, and the worst that could happen if it were attacked. You can change your answers at any time.
A finding starts at the level of its severity. Each fact below then moves it up or down. One step is one level. The result is always held between Low and Critical.
| Severity | Starts at |
|---|---|
| Rated Critical | Critical (4) |
| Rated High | High (3) |
| Rated Medium | Medium (2) |
| Rated Low | Low (1) |
| Not rated | Medium (2): treated as Medium |
| Informational, not a vulnerability | Low (1): stays Low, unless it is on the CISA KEV list or a known malicious package |
These facts differ from one finding to the next. A low exploit likelihood never lowers the level: most vulnerabilities have a low likelihood, and that is not evidence of safety.
| What we check | Steps |
|---|---|
| Known malicious package | always Critical |
| Known exploited (on the CISA KEV list) | +2, and never below High |
| Exploit likelihood (EPSS) of 50% or more | +1 |
| Exploit likelihood (EPSS) below 50% | 0 |
| Vulnerable function reachable from your code | +1 |
| Vulnerable package imported by your code | 0 |
| Vulnerable package not imported by your code, or its function not reachable | −1 |
These facts are the same for every finding of a product. Only the highest row that applies counts, and it counts once, so a product that is in the energy sector, is a CRA critical product and could cause physical harm does not add up to +3.
| What we check | Steps |
|---|---|
| Used in a NIS2 Annex I sector (energy, transport, banking, health, water, digital infrastructure, public administration and others) | +1 |
| Used in a NIS2 Annex II sector (postal, waste, chemicals, food, manufacturing, online platforms, research) | 0 |
| Used by consumers or other businesses | 0 |
| CRA critical product (Annex IV), or important product class II (Annex III) | +1 |
| CRA important product class I, or none of the CRA categories | 0 |
| Runs on an industrial (OT) network | +1 |
| An attack could cause physical harm | +1 |
| Lives could be at risk | +2 |
| Money could be lost | 0 |
| No safety impact, used by consumers or other businesses, no CRA category, not on an industrial network (all four questions answered) | −1 |
Being reachable from the internet makes a flaw more urgent. Being inside a closed network makes it less urgent.
| What we check | Steps |
|---|---|
| Reachable from the internet | +1 |
| Partly reachable from the internet | 0 |
| Not reachable from the internet | −1 |
The flaw: a High-severity bug (CVSS 7.5) in a TLS library. Its exploit likelihood is 12%, your code imports the library, and it is not on the CISA list. Here is what that means for three different products.
A public website for consumers, hosted in the cloud. An attack would affect only data or service.
A device used in the energy sector and a CRA critical product (smart meter gateways, Annex IV). An attack could cause physical harm.
A desktop tool used inside other businesses. It cannot be reached from the internet and has no safety impact.
If any of the four product questions is unanswered, or you answered Not sure, that missing answer adds no risk steps. Known impact and internet exposure still count. When you answer, the level may go down or up based on those facts.
The same flaw on a product with none of the four questions answered is shown as High, using only the known facts about the flaw. High
KROMSE may suggest an answer from what it finds in your scan. A suggestion counts only after you confirm it.
Next to every Your risk level we show the severity the scanner gave the flaw. Your risk never replaces it. Seeing both tells you where your product's context changed the picture.
The level is calculated by the fixed rules on this page, not by an AI model. The same finding on the same product answers always gets the same level. An AI review can still suggest that a finding looks like a false positive; that only moves the finding down the list within its level and never changes the level.
Rules version: your-risk/2. If a weight changes, the version changes and this page changes with it.
NIS2 is the EU directive on the security of network and information systems. The Cyber Resilience Act (CRA) is the EU regulation on the cybersecurity of products with digital elements. KROMSE uses their lists of sectors and product categories only to understand how much harm a flaw could do. It does not tell you whether either law applies to you.
Open KROMSE
