Cyber Resilience Act: what the reporting duty has required of manufacturers since September 2026

One regulation for everything that exchanges data

The Cyber Resilience Act, Regulation (EU) 2024/2847, has been in force since 10 December 2024. It regulates the security of products, not of operations, and applies to manufacturers of "products with digital elements". This means hardware and software with a data connection that is made available commercially on the EU market. Most of the obligations only take effect at the end of 2027. One obligation, however, already applies: the reporting duty under Article 14, since 11 September 2026.

Many mid-sized manufacturers have so far not seen themselves as covered by these rules, because they think of themselves as machine builders, electrical engineers or building services suppliers, not as software houses. The regulation does not ask how you see yourself, but what your product is. Typical cases from mid-sized companies:

• Machine and plant controllers with a network connection, web interface or remote maintenance.
• Inverters, storage and charging equipment monitored via an app or portal.
• Building services equipment such as controllers for heating, ventilation and air conditioning, access control systems and building management systems.
• Connected devices of all kinds, from measuring instruments to sensors in the field.
• Software products that you sell or license to customers, for example configuration or diagnostic tools.
• Apps that belong to your devices or are offered on their own.

Areas that already have their own rules are excluded: medical devices, vehicles and aviation. Anyone who manufactures devices in these areas follows their regulations. Important for everyone else: under Article 69(3), the reporting duty also applies to products placed on the market before 11 December 2027. The controller that has been running at a customer's site for years is included.

What triggers the reporting duty and what does not

The regulation has two triggers. The first is an actively exploited vulnerability in your own product. Actively exploited means that there is reliable evidence that an attacker has actually used the vulnerability. The second is a severe security incident that affects the security of the product, for example when a manufacturer's update infrastructure is attacked.

Just as important is what does not trigger a reporting duty. A vulnerability that your own development team finds during testing does not have to be reported, as long as nobody exploits it. Nor does mere suspicion. That is no invitation to leave findings lying around: from December 2027 the regulation requires orderly vulnerability management anyway. But it does mean that not every notice from a security researcher starts the clock immediately. The first task is therefore classification, and that needs criteria you have set in advance.

The clock starts when you become aware. In practice, that is the moment a reliable report reaches your company, whether in the support inbox, in sales or in development. Anyone who first checks who is responsible loses hours that already count towards the deadline.

Three stages, three deadlines

Reporting is staggered. The first notification is meant to come quickly and may be incomplete; the later ones supply the details.

The recipient is the computer security incident response team (CSIRT) designated as coordinator in your member state, in Germany at the Federal Office for Information Security (BSI), and at the same time the European Union Agency for Cybersecurity (ENISA). You reach both through a single point: ENISA's single reporting platform, which has been running since 11 September 2026. So you report once, not twice.

The 24 hours are tight but achievable if it is clear who reports and which details are needed. They become impossible if, on the first evening, nobody knows in which countries the affected product was sold.

User information: the harder part

In addition to the notification to the authority, Article 14(8) requires you to inform the affected users: about the vulnerability or incident and about the measures they can take to mitigate or remedy the risk. If you do not, the CSIRTs may inform the users themselves. No manufacturer wants that, because then your customers learn from the authority what they should have heard from you.

In practice this part is harder than the notification to the authority, for three reasons:

• The installed base. The authority receives one notification. The users number in the hundreds or thousands, and only those with certain versions are affected. Which customer runs which firmware is rarely recorded in one place: deliveries in the ERP, contacts in the CRM, versions in the remote maintenance system, if the devices are connected at all.
• The languages. A manufacturer that sells in several countries informs its users in several languages. A security notice translated under time pressure is a source of errors in its own right.
• The partners. Many products reach the end customer through dealers, system integrators or maintenance firms. The manufacturer often does not know the operator. Then the information has to go through the partners, and they need to know what they may pass on.

Anyone who only asks these questions after the early warning will manage the notification to the authority and lose the customers. The order of information, the templates and the list of critical customers therefore belong in place before the first case.

Components and the supply chain

Hardly any product consists only of its own code. Operating system, network library, radio module: much of it comes from other manufacturers. For the notification to the authority there is a clear line: a vulnerability in a third-party component only has to be reported if it is actively exploited in your product. Independently of that, Article 13 requires you to report vulnerabilities you find in integrated components to their manufacturers. For this you need a contact for every component and a way of documenting the report.

From December 2027, importers and distributors also have obligations of their own. They may then only place products on the market whose manufacturer meets its obligations, and they must inform the manufacturer if they learn of a vulnerability. Anyone who sells a product under their own name or substantially modifies it is itself deemed the manufacturer (Article 21). For dealers with own brands, a look at their own product list is therefore worthwhile.

The timetable, as of October 2026

The reporting duty is the first part of the regulation to take effect. The remaining manufacturer obligations follow a good year later.

A software bill of materials (SBOM) is a machine-readable list of all components and versions in a product. It only becomes mandatory in 2027. For the reporting duty it is already useful today: if you have one, you know within minutes which products contain a reported component.

Fines, and what takes effect instead until 2027

Article 64(2) provides for fines of up to €15 million or 2.5 percent of worldwide annual turnover, whichever is higher. They are applicable from 11 December 2027. Concluding that the reporting duty is not binding until then would be a mistake. It applies, and it is already taking effect in other ways:

• Supply chains: customers who are manufacturers themselves ask how their suppliers handle and report vulnerabilities, because those suppliers' components are in their products.
• Tenders: public contracting authorities and operators of critical facilities include the reporting duty in their requirements.
• Contracts: framework agreements require evidence of security management. A missed notice to the customer then becomes a contractual issue, regardless of any fine.

What to prepare now

The notification itself is a form. What decides whether you meet the deadline comes before it. You can tackle these seven points without outside help:

1. Product list with versions. Which of your products have digital elements, which firmware and software versions are in the field, and which components they contain.
2. Installed base. Which customer uses which product in which version, with security contact and language. Where dealers sit in between: which dealer looks after which customers.
3. Incoming channel for security researchers. A fixed address or a form on the website that someone reads, including on a Friday evening. And a rule that reports from support and sales arrive there.
4. Classification criteria. When is a report an actively exploited vulnerability, when a test finding, when a severe incident. In writing, with examples.
5. Templates. For the early warning, notification and final report with the mandatory details, plus user information in every language you sell in.
6. Responsibilities. Who classifies, who approves, who reports, who informs the customers, and who deputises for each of them during holidays.
7. Trial run. Play through a made-up case once, with the clock running. It shows where the list is wrong and who cannot be reached.

How it differs from NIS2 and the GDPR

The Cyber Resilience Act is not the only reporting duty with 24 and 72 hours. The NIS2 Directive requires certain entities to report significant security incidents in their own operations; there the concern is your networks and systems, not the product you sell. The GDPR requires a notification when personal data is affected. A single attack can trigger all three, for example when your own network is reached via your product's remote maintenance and customer data leaks in the process. Then three clocks are running, to different bodies. What the other two notifications look like as a workflow is described under NIS2: reporting a security incident and GDPR: reporting a data breach within 72 hours.

This article reflects the legal position as of October 2026 and is not legal advice. Whether your product falls under the regulation and whether a specific case must be reported is something to clarify with your legal department or a law firm.

What this means for your business

If you manufacture devices or software with a data connection, the reporting duty has applied to you since 11 September 2026, including for everything already at your customers' sites. The notification to the authority is the smaller part. The larger part is knowing within 24 hours which customers are affected, reaching them in their language and, at the end, being able to show when you did what. That is work for a workflow, not for an Excel list: take in the report, propose the classification, keep the deadlines, prepare notifications and customer information, log every approval. What such a workflow looks like hour by hour is shown in our Cyber Resilience Act use case. Whether your product list and installed base are up to it, we can clarify in a 30-minute call: book a call.

Further reading

• Use case: the reporting chain under the Cyber Resilience Act as a workflow
• The EU AI Act for mid-sized companies: which obligations arise for which workflows
• Before AI is let into the CRM: sorting out duplicates, mandatory fields and spellings
• Service: putting data in order
• Case study: routing enquiries from twelve countries according to rules