CRA reporting duty: 24 hours, from the moment you know

Since 11 September 2026, manufacturers of connected products must report actively exploited vulnerabilities and severe security incidents. The first deadline is 24 hours — and it starts the moment you become aware of the problem, not when you have fixed it.

That has been the case for three days. For most machine builders it is the first Cyber Resilience Act duty that actually bites: the rest of the regulation applies from 11 December 2027, but Article 14 was brought forward by more than a year.

Who does this mean?

The manufacturer of a “product with digital elements”. Under Article 3, that is anyone who develops such a product, or has it developed, and markets it under their own name or trademark. And under Article 2, a product with digital elements is any product whose intended purpose or reasonably foreseeable use includes a direct or indirect data connection to a device or network.

A machine with a controller, remote maintenance access or a cloud link, sold under your name in the EU, is covered. The fact that you don’t think of yourself as a software company makes no difference.

Which deadlines actually run

Article 14 doesn’t describe a single report but a three-stage cascade. It distinguishes two triggers, and their final-report deadlines are not the same — this is frequently confused.

The 24-hour early warning is deliberately thin: it names the event and, where applicable, the member states in which you know your product has been made available. For an incident, it adds whether the incident is suspected of being caused by unlawful or malicious acts. Nobody expects a finished analysis after 24 hours — what is expected is that you report at all.

After 72 hours comes the substantive notification: the product concerned, the general nature of the vulnerability or an initial assessment of the incident, measures already taken, and measures users can take themselves.

An incident counts as severe under Article 14(5) if it negatively affects the product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions — or if it has led, or could lead, to malicious code being introduced into the product or into a user’s systems.

Article 14(8) adds a duty you can’t delegate to the authorities: you must inform affected users yourself, where appropriate in a machine-readable format. Reporting to the CSIRT does not replace telling your customers.

Including machines that shipped years ago

This is the part that creates the most work in practice. The rest of the CRA applies only to products placed on the market from 11 December 2027, or substantially modified after that date. Article 14 is explicitly carved out: under Article 69(3), the reporting obligations apply to all products within scope, including those placed on the market before 11 December 2027.

Put plainly: your installed base is reportable as of now. Including the line from 2019 whose software nobody has touched since commissioning.

Where you report

Through the Single Reporting Platform run by the EU cybersecurity agency ENISA. It went live on 11 September 2026 — according to ENISA as an “initial operating capability” that will be extended over the coming months.

One submission goes through a single interface to ENISA and to the national CSIRT responsible for you at the same time. Under Article 14(7), that is the CSIRT of the member state where you have your main establishment — defined as where the decisions about the cybersecurity of your products are predominantly taken, which is not necessarily your registered office. For manufacturers with no main establishment in the EU, the regulation sets out a fixed order of fallbacks.

Missing the deadlines carries administrative fines of up to EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher, under Article 64(2). That is the ceiling, not the norm — but it shows what weight class the legislator put this duty in.

Why this is an installed-base problem, not a reporting problem

Writing a 24-hour early warning does not take 24 hours. The form is the easy part.

The hard part is inside the form. The early warning asks which member states your affected product has been made available in. After 72 hours you have to say which product is affected and which measures apply. That presupposes three answers many manufacturers can’t produce on demand today:

• Which software runs on which machine? Not which version shipped, but which one is running now — after service visits, retrofits and on-site changes.
• Where are those machines? Customer, site, country. The early warning asks about member states.
• How does a fix get there? The 14-day clock for the final report only starts once a measure is available — so making it available is a clock you set yourself.

If the answer to the first question is a spreadsheet somebody updates when they get round to it, the 24-hour deadline is not your real risk. Your real risk is having to state something in a regulatory filing that you cannot evidence.

What this has to do with the controller

More than it looks. The three questions above aren’t compliance questions, they’re operational ones — they are settled in the architecture of your machine software, long before anyone opens a reporting form.

logiccloud ORCHESTRATE is built for exactly that answer: a central record of devices and software versions across the whole installed base, across hardware vendors; machines grouped by customer, plant, type and version; controlled rollouts — validated on one machine, piloted on ten, staged across hundreds, with automatic rollback when something goes wrong; role-based access and an audit trail for every change.

None of that makes your product CRA-compliant. Compliance is something your organisation achieves across the whole lifecycle, not a property you can install, and the responsibility stays with the manufacturer. What central device and software management does is more modest, and still decisive inside a 24-hour window: it makes the answer evidenced rather than reconstructed.

What to do now, in this order

1. Establish who is responsible. Which CSIRT is yours — that is, where are the decisions about the cybersecurity of your products predominantly taken? Determine it once, write it down, done.
2. Set up access to the reporting platform. Not on the day of the incident. Registering at 11pm means some of your 24 hours are already gone.
3. Name who reports. One person, one deputy, one phone number. The clock runs from the company becoming aware, not from the right person becoming aware — annual leave does not pause it.
4. Define the inbound channel. How would you learn about an exploited vulnerability in the first place? Support, service engineers, suppliers, a public disclosure. Without a defined route, you find out too late.
5. Answer the installed-base question. Which software runs on which machine, in which country. This is the longest of the five and the only one you cannot finish in a week.

Points 1 to 4 are organisation and can be done in days. Point 5 is engineering — and it decides whether the first four are worth anything when it matters.

This article sets out the legal position; it is not legal advice. Which duties apply to your company depends on your products.

The next step

If you can’t say with certainty which software version is running on which machine in the field right now, start there — everything else in the CRA builds on that answer.

Our CRA readiness check works through the questions one by one and shows where your installed base stands today.