Nobody knows what software is inside your plant

Ask an engineer what a plant runs on and you will get a list of products. Seven, maybe ten. A control system, a database, a couple of things that move data around, something that draws graphs.

That is the honest answer to the question, and it is off by a factor of about four hundred.

Why this suddenly matters#

From 11 September 2026, a European rule called the Cyber Resilience Act starts to bite. If you sell something with software in it into Europe, and a weakness in it is being actively used against people, you have 24 hours to report it. Then 72 hours for the details, and a fortnight after the fix to close it off.

Whether this lands on you depends on whether you sell a product or build one-off systems for single clients, and honest people are still arguing about where integrators sit. I am not going to settle it here — the official guidance is the place to look, and if you sell anything more than once, assume it applies.

The part I found interesting is what the rule actually asks for. It does not require you to have no weaknesses. It asks whether you can find out, within a day, whether the thing you sold contains the one that is being exploited right now.

So I tried to answer that question about a plant, and timed myself.

Counting what is really in there#

I took a small but realistic setup — a control system, a tool that shuffles data between machines, two message brokers, a device at the edge, a database for history, and a dashboard — and counted every separate piece of software inside them.

Two thousand seven hundred and thirty-five. Not files: separate pieces of software, each written by somebody else, each with its own version number and its own history.

Nobody at the plant chose 2,735 of anything. They chose seven products. The rest arrived inside them, the way a car contains parts from a hundred suppliers the buyer never hears about.

The number designed to frighten you#

Next I checked those 2,735 pieces against the public record of known security weaknesses. There are 342 of them in this plant.

That is the number that would go in a scary headline, and I am not going to use it that way, because the next check is the one that matters.

There is a public list of weaknesses that criminals are actually using right now — not theoretical, observed. It had 1,685 entries the week I looked. I checked all 342 against it.

None of them matched. Not one.

One had any real likelihood of being used, and it is a flaw in an encryption method from 2011 that most of the industry stopped relying on years ago.

I should be careful about what that proves. It is one plant, on one day, and the list of actively-used weaknesses grows every week. It does not mean the plant is safe. It means that if the rule had applied that morning, there would have been nothing to report.

The bit that surprised me#

There is a common belief that industrial software is ancient — frozen versions, holes from a decade ago, nobody maintaining anything.

The dates say otherwise.

Nine out of ten of those weaknesses were found in the last two years. Only 6% date from 2020 or earlier.

That is not decay. That is what being looked after looks like. Somebody is examining this software and publishing what they find. Software nobody is checking produces no findings at all, which reads as a clean bill of health and is the opposite of one.

So a plant with 342 known issues and a steady stream of new ones is in better shape than a plant with twelve. That is the reverse of how the number is usually read.

Where it would actually go wrong#

Here is the thing I did not expect, and it is the one that would cost you the day.

Sixty-three of those pieces of software appear in more than one of the seven products. And fifty of those sixty-three are there at different versions in different places.

One common utility is present three separate times, at three different versions. The encryption library is there twice, at two.

So when a warning arrives naming one particular version, "do we have that?" has no clean answer. It is: yes, in two of our seven products, at two different versions, one already fixed and one not — and the one that is not sits inside a supplier's package we do not build ourselves.

That is the real work. Not finding the weakness. Finding yourself in it, under a deadline, at four in the afternoon.

The five-minute job nobody has done#

Here is what removes most of the excuses.

Counting all of it — seven products, every piece of software, every known weakness, checked against the list of what is really being exploited — took four minutes and thirty-six seconds. It is a free tool, pointed at software you already have, and it writes the answer to a file you can keep.

Four and a half minutes, against a 24-hour deadline.

The difference between a plant that can answer and one that cannot is not money or headcount. One of them has run a short command once and kept the result. The other has never run it.

What is worth doing#

Make the list and keep it, with the date on it. Today's answer is not the point. The point is that when a warning arrives in March you can say what you sold in August without rebuilding anything.

Watch what is being exploited, not the total. Your 342 is noise. The handful that become actively used is the signal, and it is a far shorter list.

Sort out the duplicates first. Fifty pieces of software sitting at inconsistent versions is fifty chances to give a regulator the wrong answer in a hurry. That is a bigger exposure than any single unpatched library.

Ask your suppliers for their lists. Most of those 2,735 pieces are inside packages you did not build. If a supplier cannot tell you what is in theirs, that is a purchasing problem before it is a security one.

The deadline is real and it is close. The work it actually demands, at this stage, is small. What is missing is not skill or budget. Nobody has run the command.

The full count — product by product, how it was done, and the duplicate problem in detail — is in what a plant stack is actually made of.