On 2 November 2026, attackers heated supermarket freezers to 50°C in Belgium, the Netherlands, Sweden and other countries, three weeks after the same attack hit hundreds of stores in France. There was no CVE behind it, no KEV entry and only low EPSS scores. For OT vulnerability management, this is the problem in one example: a list sorted by severity scores would not have put this risk at the top.
At the same time, most OT teams face the opposite problem every Monday morning. The vulnerability report says almost everything is urgent: hundreds of findings, most rated high or critical, and a few at CVSS 9.8. Then you look at the plant. The PLC on line 3 can only be patched during the yearly shutdown. The HMI vendor has no fix yet. The engineering workstation runs software that breaks when you update it.
You cannot patch everything in an industrial environment, and certainly not today. So you have to choose, and you must be able to explain that choice to an engineer, a plant manager and an auditor. We come back to the fridge attacks below, because they show both questions that every OT security programme has to answer.
The short answer
A CVSS score shows how much damage a vulnerability could do in the worst case. It does not tell you whether the affected version runs in your plant, whether anyone is exploiting it, or what it costs you if that device fails. Good OT vulnerability management answers two questions at the same time:
- Where could things go wrong, and which weakness do I fix first? This is the proactive layer: a live asset inventory, presence checks, exploitation data and business impact.
- Is something going wrong right now? This is the reactive layer: indicators of compromise seen in live network traffic.
Most advice on vulnerability management only covers the first question. Most advice on detection only covers the second. When you run both on the same asset inventory, each layer helps you judge the other.
Why CVSS alone puts the wrong things first
CVSS (Common Vulnerability Scoring System) gives a vulnerability a severity score from 0 to 10. It looks at factors such as how hard the attack is, which privileges an attacker needs and what the possible impact is. The score is calculated once, in general terms, without any knowledge of your site.
In practice, severity and likelihood are two very different things. The SANS Internet Storm Center estimates that roughly 5 to 7 per cent of published CVEs are exploited in the wild. For the large majority there is no known exploitation. A list ranked only by CVSS treats both groups the same, so everything looks urgent and you still do not know where to start.
A CVSS 9.8 in a product you hardly use, with no known exploitation, is a smaller risk for your operation than a CVSS 6.5 that ransomware groups are exploiting this month in your sector.
Four steps of OT vulnerability management that reduce real risk
In a production environment, OT vulnerability prioritisation works best in this order.
1. Start with what is actually on your network. Not the asset register from the last audit, but a live inventory with vendor, model and software version for every device that communicates. Without version information, every statement about vulnerabilities is a guess. What a usable inventory looks like is described in our blog on OT asset visibility.
2. Check presence. Does this vulnerability exist on your devices, in the versions you actually run? A critical CVE in a firmware version you never installed is not your problem. This step alone removes a large part of the noise before anyone opens a change request.
3. Check exploitation with public threat intelligence. Two free sources do most of the work. Both are maintained independently of any security vendor:
- CISA KEV (the Known Exploited Vulnerabilities Catalog) lists vulnerabilities with reliable evidence that attackers use them in the real world. A vulnerability is only added when it has a CVE ID, there is evidence of active exploitation, and a clear fix or workaround exists, as described in CISA’s inclusion criteria. So a KEV listing is based on what attackers already do.
- EPSS (the Exploit Prediction Scoring System, published by FIRST) estimates the chance that a vulnerability will be exploited in the next 30 days. The score runs from 0 to 1, so 0.10 means a 10 per cent chance. CVSS does not look at likelihood at all.
A CVE on KEV goes to the top of the list. A high EPSS score also moves it up. A CVSS 9.8 that nobody is exploiting, with a low EPSS score, can usually wait for the next maintenance window. CVSS stays in the picture as background, but it no longer decides the order.
4. Express impact in money. What does it cost if this device stops? A vulnerable controller that can stop a production line is a much bigger problem than a vulnerable printer in the canteen. When impact is shown in euros per asset, the CFO and the plant manager can read the priority list too, not only the engineer who made it.
What each signal tells you
| Signal | Question it answers | What it cannot tell you |
| CVSS score | How severe would this be under worst-case conditions? | Whether it is present, exploited, or expensive for you |
| CISA KEV | Is this being exploited in the real world, right now? | Whether your devices run the affected version |
| EPSS | How probable is exploitation in the next 30 days? | What it would cost your operation |
| Business impact | What does it cost in euros if this asset fails? | Whether anyone is attacking it |
| Indicator of compromise | Is something already happening on my network? | Which weakness let it in |
The second question: is something going wrong right now?
A good priority list shows you where you are weak. It does not show you whether someone is already inside. For that you need a second layer: indicators of compromise, or IOCs.
An IOC is something you actually see on your network. For example, a device talking to an address known to be used by attackers, a known attack pattern in live traffic, or a machine that suddenly behaves differently than in the past eight months.
Think of your plant as a building. The first layer is about the door locks: which locks are weak, and which types of lock burglars are breaking elsewhere in the city this week. That tells you which locks to replace first. The second layer is about footprints on the floor of your own hallway. A footprint does not tell you which lock is weak. It tells you that somebody came in.
A list of weak locks will not warn you when footprints appear. And footprints alone do not tell you which doors to strengthen before the next visit.
What the supermarket fridge attacks mean for OT vulnerability management
On the night of 11 to 12 October 2026, attackers took over refrigeration controllers in hundreds of French supermarkets and switched fridges and freezers to defrost mode. Some heated up to 50°C, and stores had to throw away large amounts of food. According to Le Monde, the attackers also stretched some defrost cycles from one hour to eight hours, which delayed the temperature alarms.
Three weeks later, on 2 November, it happened again in Belgium, the Netherlands, Sweden, Estonia, Ireland, Luxembourg and other countries. In the Netherlands, according to Danfoss, at least 17 businesses were hit, including butchers and small local shops. The warnings had been public for weeks. In mid-October, RTL Z already found at least 75 Dutch Danfoss login pages that anyone could reach from the internet.
The French national CERT reported numerous compromises of remote controllers from Danfoss, Copeland and Dixell in its alert of 12 October. According to Danfoss, most units hit in France were older models that no longer receive security updates, and the newer units that were hit ran outdated firmware. Officials have not said how the attackers got in.
So why did CVSS, KEV and EPSS stay quiet? Part of the answer is simple. Changing a setpoint or a defrost cycle is a normal admin function: anyone with a valid login can do it, without using a software flaw. A weak password or a controller left open on the internet is a configuration problem, so it gets no CVE number.
KEV only lists vulnerabilities with a CVE ID, and nobody has officially linked a CVE to these attacks. In the CISA catalogue of 30 October 2026 there was no entry for any of these controllers. EPSS also scores per CVE: on 2 November, the known vulnerabilities in these controllers had an EPSS score between 0.7 and 4.5 per cent. Both are strong signals, but they can only reflect what has been confirmed in public. For OT vulnerability management, they cannot be the only input.
Why did the warnings not reach everyone? Many stores do not see the controller as their own system. Refrigeration is usually outsourced, and the internet connection is there so the contractor can log in remotely. The oldest models get no updates at all. According to the Belgian refrigeration firm Sabcobel, many installed units also need physical changes, which takes time and money. Sabcobel said most of its customers moved to a secure connection after the French attack, and it knew of around twenty affected units out of the hundreds it manages in Belgium. You cannot act on a warning about a device you do not know you have.
What should you do now? The CERT-FR advice, plus one point of our own, works for any OT device that a contractor manages remotely:
- Take it off the internet. Only allow remote access through a secure VPN or a protected network. Filtering on IP address is a temporary measure at most.
- Replace default passwords. Check which accounts exist and remove the ones nobody needs.
- Update or replace. Install available firmware updates, and plan the replacement of end-of-life models.
- Check the configuration. Look at setpoints and schedules such as defrost cycles.
- Make ownership clear. Agree with your contractor who is responsible for access, passwords and updates.
So a list sorted by CVSS, KEV or EPSS would not have put this risk at the top. There was no CVE to sort on, and for the oldest controllers there is no patch at all. What helps is layer 1 done well: knowing these controllers are on your network, which version they run, that they are end-of-life and that they can be reached from the internet. And layer 2: because the attackers delayed the stores’ own temperature alarms, you need a signal that does not depend on the controller itself, such as noticing when a device that normally only talks to your refrigeration contractor suddenly gets a connection from an unknown address at night. That is the footprint in the hallway. The same questions apply in factories. For more on the sector, see OT cybersecurity for manufacturing.
One priority list, fed by both layers
In OT vulnerability management, the real value comes when both layers work on the same inventory. Take three findings on the same network:
- A vulnerability with a CVSS score of 9.8, confirmed on a device, not on KEV, with a low EPSS score. Plan it.
- A KEV-listed vulnerability on a controller that can stop a production line. Plan it soon, and use compensating measures such as segmentation or tighter remote access until you can patch in the next maintenance window.
- The same KEV-listed vulnerability on a device that is also in contact with a known bad address. Handle this one today.
In the third case, the weakness is known to be exploited, the asset is valuable, and your own traffic shows that something is happening. A CVSS score alone could never give you that ranking. It also works the other way round. An IOC on a low-value device without known weaknesses still needs a look, but it comes after the same IOC on your most expensive production asset.
For organisations that fall under NIS2 and the Dutch Cyberbeveiligingswet, this combination also helps build the evidence that risk decisions are based on what is really on the network, not on a static spreadsheet. We apply the same reasoning to asset inventory in Cbw and NIS2: why your CMDB is not complete once OT is in scope.
How Nautilus handles OT vulnerability management without touching your network
Nautilus answers both questions of OT vulnerability management with one passive sensor.
For the first question, the platform reads the version information that devices already share in normal traffic: SSH banners, HTTP server headers, SNMP responses and industrial protocol identities such as Siemens order numbers. We match this against the CVE database and prioritise the results with CISA KEV and FIRST EPSS. This is passive CVE correlation: we never send a packet into the OT network to question a device. We only link a device to a CVE when the observed version supports it, because a missed match does less harm than a false alarm. Impact is shown in euros per asset, so the results work for management as well as for engineers.
For the second question, detection runs on the sensor itself. It uses four public rule and IOC sources that are updated daily, with more than 120,000 detection rules in total, including a dedicated SCADA and OT rule set.
We have also measured that the sensor stays passive: zero outgoing packets on the monitoring ports against tens of millions of incoming packets, with the same result after a restart. We only store metadata, never the content of your traffic, and all data stays within the EU. With the Nautilus OT solution you get a first view of your assets within hours of activation.
Frequently asked questions
Does a CVSS score of 9.8 mean you should patch immediately?
No. CVSS shows how severe a vulnerability could be in the worst case. It does not tell you whether the vulnerable version runs on your network, whether anyone is exploiting it, or what the affected asset is worth to your operation. A CVSS 9.8 without known exploitation and with a low EPSS score can usually wait for a planned maintenance window. A vulnerability with a lower score that is listed on CISA KEV may need action this week.
What is the difference between CVSS, KEV and EPSS?
CVSS shows how severe a vulnerability could be. CISA KEV lists vulnerabilities that are confirmed to be exploited. EPSS, published by FIRST, estimates the chance of exploitation in the next 30 days. These are three different measurements. Good OT vulnerability management uses all three, together with the business value of the asset.
How do you manage vulnerabilities on OT devices that cannot be patched?
With compensating measures and monitoring, which is a normal part of OT vulnerability management. When a PLC or HMI can only be changed during the yearly shutdown, the practical options are network segmentation, limiting and monitoring remote access, and continuous monitoring so that exploitation attempts become visible. The vulnerability remains, but the chance that someone exploits it without you noticing becomes much smaller.
What share of published CVEs is ever exploited?
The SANS Internet Storm Center estimates that roughly 5 to 7 per cent of published CVEs are exploited in the wild. So if your OT vulnerability management treats every critical finding as equally urgent, most of your effort goes to vulnerabilities that nobody is using.
Can you find vulnerabilities in an OT network without scanning it?
Yes. Devices share version information in normal communication, for example in SSH banners, HTTP headers, SNMP and industrial protocol identities. By reading this from a SPAN port or TAP, you can match CVEs without sending any traffic into the production network. That avoids the availability risk that makes active scanning unacceptable in most plants.
Where to start
Take your current vulnerability list and add three columns: is the finding confirmed in a version you actually run, is it on CISA KEV, and does it sit on an asset that can stop production? If you cannot fill in those columns today, your OT vulnerability management does not yet have a real priority list.
Is NIS2 the reason you are looking at this? Our free NIS2 compliance check gives you a first indication in two minutes. To see a two-layer priority list based on your own network, book a demo with one of our specialists.
