Cyber Resilience Act vulnerability reporting has started. Do you know what runs in your PLCs?

The cabinet on line 3 holds a PLC nobody in the building can fully account for. The firmware is whatever version the machine builder commissioned it with. The program opens only in one vendor's tool, on a laptop nobody dares to update. The machine builder changed hands twice since then and the last support email went unanswered. The machine itself runs fine.

On 11 September 2026 a clock started running that makes exactly that cabinet a problem. Not for you first, but for whoever built the controller and the machine around it. And the way the clock is designed, you will feel it too.

What the Cyber Resilience Act requires since 11 September

Since 11 September 2026, Article 14 of the Cyber Resilience Act applies. Manufacturers of products with digital elements must report two things: a vulnerability that is being actively exploited, and a severe incident that hits the security of the product. The timeline is tight:

• 24 hours after becoming aware: an early warning.
• 72 hours: a full notification with the nature of the vulnerability and the exploit, and the corrective measures taken or available.
• 14 days after a fix is available: a final report. For a severe incident the final report is due within one month.

The notification goes to the CSIRT of the country where the manufacturer has its main establishment and to ENISA at the same time, through the Single Reporting Platform that opened the same day. In the Netherlands the reports land at the NCSC, with the RDI as market surveillance authority; in Poland at CERT Polska. The manufacturer also has to inform the users of the affected product.

Two details matter more than the deadlines. The clock starts when the manufacturer becomes aware, not when the analysis is finished. And Article 69 of the regulation exempts products already on the market from the main requirements until they are substantially modified, but explicitly keeps the reporting duty applicable to all of them. A controller shipped in 2019 is in scope for reporting today; the rest of the CRA follows on 11 December 2027.

Whose clock is it?

The obligation lands on the manufacturer: whoever develops or produces a product with digital elements and markets it under their own name. On a factory floor that is more parties than the PLC vendor:

• The PLC and drive vendors, for their controllers, firmware and engineering software.
• The machine builder, for the digital elements in the machine as a whole: PLC, HMI, remote-access router and the software that ties them together.
• Anyone who substantially modifies such a product and makes it available on the market again. Article 22 makes that person the manufacturer for the modified part, or for the whole product if the change affects its security as a whole.

If you run a factory and never sell equipment, the CRA clock is not yours but your vendor's. But you are the user the manufacturer has to inform, and once you are in scope for NIS2 you have your own 24 and 72 hours for incidents in your operation. So when your PLC vendor reports an exploited vulnerability to ENISA, the question on your side is immediate: is that controller in our building, which version, on which network, and what can it reach?

That question has to be answered in hours. In most factories it takes weeks.

You can only report what you can see

The CRA asks manufacturers to know their own product. Annex I requires them to identify and document the components in it, including a software bill of materials in a machine-readable format covering at least the top-level dependencies. The support period has to run for at least five years, unless the product is expected to be in use for less.

Hold that list against the controller on line 3. Closed firmware: nobody outside the vendor knows which network stack, web server and real-time kernel are inside. No bill of materials, so when a library vulnerability is published nobody can say whether it applies. A program only the vendor's tool can read, from a vendor who may be gone.

This is why the 24-hour clock is unworkable for opaque equipment, whoever it formally belongs to. You can only disclose a vulnerability you know exists. And a plant that cannot list what runs in its cabinets cannot act on the vendor's warning when it lands.

Three questions for your PLC and machine vendors this month

Ask every vendor with digital equipment on your floor three questions:

1. Can you give us the software bill of materials of the controller and its firmware? Even just the top-level dependencies. If the answer is no, you know how they will do under Article 14.
2. How will you inform us of an actively exploited vulnerability, and within how many hours? Which address, which contact on our side, which channel? An account manager who "will get back to you" is not a channel.
3. Until when is this product in its support period, and what happens after? A controller past its support period gets no security updates. That is the date after which the machine has to be isolated or the controller replaced.

Write the answers down per machine, next to the firmware version that is actually running. That table is the start of the OT asset register NIS2 asks for. The controllers whose vendor cannot answer belong in their own network zone with logged access until they are replaced. That is the honest interim answer.

Why an open controller makes the reporting duty workable

For years the argument for open PLC modernization was engineering and independence: keep the machine, replace the controller, move the logic to IEC 61131-3 on a runtime you can read. Since 11 September there is a compliance argument next to it.

A closed controller is what you know from the big vendors: their hardware, their firmware as one signed package, their engineering tool. What is inside that firmware, which network stack, which libraries, which versions, only the vendor knows. You see one version number on the type plate. When a vulnerability is published somewhere, you cannot check yourself whether it touches your controller: you wait for the vendor's advisory, then for the patch, then for the maintenance window in which you are allowed to install it. Your grip reaches exactly as far as the vendor lets you look.

An open controller is built like an IT system: an industrial PC or edge controller with a Linux kernel, a runtime that executes IEC 61131-3, a fieldbus stack and libraries that each have a name and a public version number. Those components sit in the same public vulnerability registers (CVE) your IT department already follows every day. The software bill of materials is then not a document someone writes afterwards: it comes out of the build. When a vulnerability in one of those components is published, you check within the hour yourself whether it is in your controller, and you decide when to roll out the patch, without waiting for one vendor.

The same holds for control hardware and edge devices built for you. In our custom hardware and PCB development the firmware comes from the same house as the board, with signed over-the-air updates and a maintained software inventory from the first schematic. That is the only way to get a security update onto a device in the field without a site visit. And the controller stops being an island: it reports its firmware version, connections and update state to the same data layer that carries your production data, the layer IT-OT integration is about. The asset register is then live, and it answers a vendor's warning in minutes.

Honest about it: what open control does not fix

Three things belong on the table before anyone sells you "CRA compliance".

A controller does not make you compliant. Reporting within 24 hours is a process: someone on call, someone who knows which CSIRT, someone who can read the notification and check the plant. The controller only makes the checking fast.

Open is not automatically secure. A readable stack is a stack you can audit and patch. It becomes secure when someone does that, and keeps doing it for the life of the machine. That is work, and it has to be budgeted.

A modernization can put the clock on you. If you substantially modify a machine's control and only use it in your own plant, you are not placing it on the market. But a machine builder or integrator who does the same and delivers the machine to a customer becomes the manufacturer for that part under Article 22, with the full reporting duty. And this article is not legal advice.

Frequently asked questions about CRA vulnerability reporting

Does the CRA reporting duty apply to a factory that only uses PLCs?

No. The 24-hour duty sits with the manufacturer of the product with digital elements, not with the user. A factory feels it in two ways: as the user the manufacturer has to inform, and through NIS2, which puts its own 24-hour early warning on essential and important entities, manufacturing included.

What are the fines?

Breaching the reporting obligations of Article 14 or the essential requirements can cost up to 15 million euros or 2.5 percent of worldwide annual turnover, whichever is higher, under Article 64. Supplying incorrect information to the authorities is fined up to 5 million euros or 1 percent.

What is the difference between the CRA and the NIS2 reporting duty?

Who reports, and about what. The CRA puts the duty on the manufacturer of a product, about exploited vulnerabilities and severe incidents in that product, to ENISA and the national CSIRT. NIS2 puts the duty on the operator of essential or important services, about significant incidents in their own operation, to the national authority. A manufacturer that also sells equipment with digital elements has both.

Do you know what runs in your cabinets?

The controllers that cannot answer the three questions are the same ones we wrote about when Siemens set end dates for the S7-300 and S7-1200 G1. The CRA adds a second reason to deal with them, and a deadline that is not yours to move. Every project starts with the inventory. Tell us which cabinet keeps you up at night.