Delfen
All articlesProduct Security

CRA Article 14 for machine builders: who files the 24-hour warning

Since 11 September 2026, a manufacturer that learns a vulnerability in its product is being exploited has 24 hours to warn the authorities, including for machines sold years ago. The law does not say who in a machine builder notices, decides and files, so name those people before the first incident.

Jacques Domenie·26 October 2026·6 min read

Since 11 September 2026, if you sell machines or equipment with software in them in the EU, you have a new legal duty. When you learn that attackers are exploiting a vulnerability in one of your products, you must send an early warning to the authorities within 24 hours. The duty comes from the Cyber Resilience Act (CRA), the EU law on the security of products that contain software. It also covers machines already running at customer sites. Software companies handle this with a product security incident response team (PSIRT). Without one, the law still applies, and it does not say who in your company notices, who decides, or who files. Settle that before the first incident, because during one you will have less than a day.

What you must report, and when

Two kinds of event start the clock. The first is an actively exploited vulnerability: there is reliable evidence that an attacker has used it in someone's system without the owner's permission. A researcher who tests your controller in good faith and tells you about it does not trigger a mandatory report. The second is a severe incident affecting the security of your product. Examples are an incident that compromises sensitive or important data or functions, or one that lets an attacker introduce or run malicious code. The regulation's own example fits machine builders: malicious code delivered through your software-update channel.

ReportActively exploited vulnerabilitySevere incident
Early warningWithin 24 hours of awarenessWithin 24 hours of awareness
NotificationWithin 72 hours of awarenessWithin 72 hours of awareness
Final reportWithin 14 days after a fix or mitigation is availableWithin one month after the 72-hour notification

For a controller with no patch yet, those 14 days can start months after the incident.

The duty covers every product you have placed on the EU market, whenever you sold it, and continues after your support period ends. Exploitation you already knew about before 11 September 2026 does not have to be reported; anything you learn after that date does. Your machines also contain other companies' products, such as an industrial PC or a remote-access gateway. If an exploited vulnerability in one of those is reachable in your machine, you report it as the machine's manufacturer.

The clock starts when you know

The European Commission's guidance places awareness at the point where, after an initial assessment, you have a reasonable degree of certainty. Its published questions and answers on the CRA add that the regulation does not specify how a manufacturer is to become aware.

In a machine builder, the signal rarely arrives labelled as a security report. It arrives as a service ticket about a machine behaving oddly, a customer's IT team asking about an unexpected connection from the remote-service box, or a supplier advisory in a purchasing mailbox. The failure I expect is a company where those facts sit in three inboxes for a week before anyone connects them. Then a regulator asks why the initial assessment took a week.

Who watches, who decides, who files

The fix is three named roles, each with a deputy, written on a one-page roster.

The watcher owns the intake: service tickets, reports from field service engineers, and security advisories from suppliers and public sources about the components in your machines. Matching advisories to machines needs a list of the software and firmware components in each product type and version. If that list does not exist for your older machines, that is the first gap to close. A language model can flag the tickets and advisories that mention your component versions, but it should not make the call. The legal test is reliable evidence of exploitation, and someone must be able to explain afterwards why they judged it so.

The decider makes that call: actively exploited or severe, yes or no. Pick someone senior enough to decide at night without calling a meeting, such as the head of engineering or whoever owns product security. Log the decision with the time and the evidence: your 24 hours run from the moment you became aware, and the log is how you show when that was. The filer has a working account on the reporting platform and has used it at least once in a test.

The one-page roster has a row per product family, with these columns:

  • product versions in the field
  • where the component list lives
  • watcher, decider and filer, each with a deputy
  • the date each filer's platform account was last checked
  • who tells affected customers
  • who decides whether a second report is needed under another law

Every six months, have your quality or compliance manager test the roster with a desk exercise. Your service desk logs a ticket at five on a Friday afternoon describing an exploited weakness in the remote-access module of a machine you sold seven years ago. Can you name the person who files the early warning by five on Saturday, and their deputy if that person is on a plane?

Where the report goes in the Netherlands

You file once, through the EU's single reporting platform run by ENISA, the EU cybersecurity agency. The report is addressed to the national incident response team of the country where your main establishment is. That is where your product cybersecurity decisions are mostly taken; failing that, where most of your staff work. For the Netherlands, that team is the National Cyber Security Centre (NCSC). Each filer needs a personal EU Login account with two-factor authentication, and the platform works in English only. A company can register one primary representative and up to 20 secondary ones, so register your deputies now.

The NCSC tells Dutch manufacturers to report through its MijnNCSC portal or its CRA web form. It says it passes the report on to ENISA and the other member states, and that you do not need to report in two places. ENISA says manufacturers submit through the single reporting platform, which member states may connect their own end-points to. Neither source says whether MijnNCSC is such an end-point. Set up the platform accounts anyway, and ask the NCSC in writing which route it expects from you.

When the CRA and NIS2 clocks fire on the same incident

The CRA has no provision that lets one report satisfy another law. Then there is NIS2, the EU directive on cybersecurity for essential and important organisations. In the Netherlands it took effect as the Cyberbeveiligingswet on 15 August 2026. If it applies to you, a significant incident that disrupts the services you provide has its own 24-hour, 72-hour and one-month deadlines. You file those with your sector's incident response team and your supervising authority. An attacker who gets through your remote-service platform into customer machines can, in my reading, trigger both: a CRA report about the product and a Cyberbeveiligingswet report about your own service. If you are unsure whether NIS2 applies to you, my article on NIS2 in acquisitions covers which sectors it reaches.

What to do before the next incident

Start by putting three names on paper, each with a deputy: who watches for actively exploited vulnerabilities, who decides whether one is reportable, and who files the early warning. Register the filer and their deputy on the reporting platform. Fines for breaching these reporting duties go up to EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher, and a mid-sized machine builder has no exemption. Preparing costs far less: a few days for the roster, an afternoon for the accounts, and the slow work of rebuilding component lists for machines sold years ago. That list will earn its keep twice: from 20 January 2027 the EU Machinery Regulation requires machines to identify the software they need to operate safely and protect it against corruption. If you are buying or selling a machine builder, the roster belongs in due diligence on its operational technology.

If you want a second reading of your roster before an incident tests it, Delfen advises on technology risk in regulated and industrial organisations.

Sources & further reading

Delfen CTO update

What changed for a decision you are making. Every Tuesday.

Three to five developments, each with a question for your team. Free. Unsubscribe anytime.

Subscribe to the Delfen CTO update →
← Back to all articles