Share This Article
Cyber Resilience Act reporting obligations are now live, but the difficult question for manufacturers is not simply whether they have to report a cyber incident. It is what happens after the report has been made, while the incident is still developing.
Since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements under the Cyber Resilience Act (CRA). An early warning must be submitted within 24 hours of becoming aware of the relevant event, followed by a full notification within 72 hours. The CRA also requires a final report in the circumstances and within the timeframes set out by the Regulation. Notifications are submitted through the CRA Single Reporting Platform established by ENISA.
I have already looked at the wider scope of the CRA and at the specific implications for gambling operators and suppliers. The CRA requirements for gambling operators and suppliers illustrate particularly well how the Regulation can reach products and technologies that businesses may not traditionally have regarded as part of their cybersecurity regulatory perimeter.
The next question is more practical: what should a company actually do when a vulnerability is exploited and the 24-hour clock starts running?
The 24-hour deadline changes incident response
The CRA reporting deadline creates a problem that cybersecurity teams know well but that legal teams increasingly need to address with them. When a serious cyber incident occurs, the company often does not know exactly what happened.
The investigation may still be in its early stages. The technical team may not yet know the root cause. It may still be unclear which products are affected, whether the vulnerability has actually been exploited, whether customers are exposed and whether the incident has affected other parts of the supply chain. Yet the reporting obligation may already have been triggered.
The European Commission’s guidance on CRA reporting obligations confirms that manufacturers must submit an early warning within 24 hours and a full notification within 72 hours. The reporting is made through the CRA Single Reporting Platform operated by ENISA.
This means that companies cannot simply wait until the technical investigation is complete before considering the legal consequences. They need to decide, while the facts are still developing, what they know, what they do not know, what they are required to report and how the information provided to the authorities should be framed. That is a very different exercise from preparing a compliance document in advance.
A CRA report can create consequences beyond the CRA
One of the issues I expect to become increasingly important is the interaction between the CRA and the other regulatory regimes that can apply to the same incident.
A vulnerability affecting a connected product may also involve personal data, making GDPR obligations relevant. The company may fall within NIS2 and have separate incident-reporting obligations. A financial institution affected by the incident may need to consider DORA. The incident may also trigger contractual notification obligations towards customers, suppliers or other business partners.
The company therefore needs to look at the incident as a whole.
The question is not simply: “Do we have to notify under the CRA?” It is also: “What are the consequences of what we tell the authorities under the CRA for our position under the other applicable regimes and in any subsequent claim?”
This is particularly important where the facts are still uncertain. A preliminary description of the incident may later need to be compared with the findings of the technical investigation. A customer may rely on information provided to a regulator when bringing a contractual claim. A supplier may challenge the company’s assessment of the cause of the vulnerability. A regulator may ask why a particular risk was not identified earlier.
The first notification can therefore become part of the legal history of the incident.
The Single Reporting Platform does not remove the legal complexity
ENISA’s CRA Single Reporting Platform is designed to simplify the reporting process. Manufacturers report through a single platform, and the information is transmitted to the relevant CSIRT and, under the applicable framework, made available to other relevant CSIRTs and ENISA. ENISA has also published FAQs and practical guidance on the CRA Single Reporting Platform.
This is an important development, but it does not answer the more difficult question of what the company should say. The information submitted during the first hours of an incident may be incomplete. At the same time, the company needs to avoid creating inconsistencies between its CRA notification, its communications with customers, its notifications under other legislation and the findings that will eventually emerge from the technical investigation.
This is why the legal and technical response should be coordinated from the beginning. It is not about slowing down the technical investigation. It is about ensuring that the company does not create a second problem while trying to solve the first one.
The supply chain may determine who bears the consequences
Cybersecurity incidents increasingly involve several organisations. A product may contain third-party software. A manufacturer may rely on a cloud provider. A component may have been developed by another technology company. The vulnerability may originate somewhere in the supply chain rather than in the manufacturer’s own code.
This creates questions that cannot be answered by the CRA alone.
- Who discovered the vulnerability?
- When did the relevant party become aware of it?
- Who had the obligation to notify?
- Did the technology agreement require immediate notification?
- Who was responsible for remediation?
- Who bears the cost?
- And, if customers bring claims, which party ultimately carries the liability?
The CRA therefore makes contractual arrangements around cybersecurity more important, not less.
Incident notification clauses, cooperation obligations, audit rights, vulnerability management, indemnities, liability limitations and insurance provisions can all become relevant when a vulnerability turns into an actual incident. This is one reason why I would not treat CRA compliance and technology contracting as separate exercises. The contract may ultimately determine how the cost of the incident is allocated.
Physical AI makes the problem even more complicated
The issue becomes more significant as AI moves into physical products. Robots, drones, autonomous systems and industrial equipment increasingly combine software, AI, connectivity and physical capabilities. A cybersecurity vulnerability affecting such a product may therefore have consequences that go well beyond the loss or compromise of data.
A successful attack could interrupt production, affect the operation of machinery, damage equipment or create risks for customers and other users. It also creates difficult questions of responsibility.
If an AI-enabled product behaves incorrectly following a cyber attack, is the problem attributable to the manufacturer, the AI developer, a software supplier, a component manufacturer or the operator?
The answer will depend on the architecture of the product, the respective roles of the parties, the applicable regulatory framework and the contracts between them. This is an area where cybersecurity, AI governance and product liability are increasingly converging.
I recently considered a related issue in When your own company’s AI agent is hacked, who is liable?, where I looked at how the interaction between the AI Act, GDPR, NIS2, DORA, CRA and the Data Act can affect the legal consequences of a compromised AI system. The same principle increasingly applies to connected physical products: the technical architecture can determine the legal architecture.
What should companies have in place before an incident?
The best time to address these questions is before the first incident.
Companies placing products with digital elements on the EU market should have a clear process identifying:
- who determines whether the CRA reporting threshold has been met;
- who has authority to make the notification;
- how the technical and legal teams coordinate;
- how the company assesses parallel obligations under NIS2, GDPR, DORA and other applicable regimes;
- which customers, suppliers and other counterparties need to be notified;
- what the relevant contracts require;
- how evidence and technical records are preserved;
- and how the company manages the risk of subsequent regulatory investigations or claims.
The objective is not to create another layer of bureaucracy around cybersecurity. It is to make sure that the company can take decisions quickly when the facts are still incomplete. This is particularly important because the consequences of an incident may continue long after the vulnerability has been fixed. A regulator may investigate the company’s response. A customer may bring a claim. An insurer may examine whether policy conditions were satisfied. A supplier may dispute responsibility. In some cases, the incident may become part of wider litigation. The quality of the decisions taken during the first hours can therefore matter months or even years later.
The CRA is becoming an incident-response issue
The CRA is often presented as a product cybersecurity regulation. That is true, but it is only part of the story.
Once the reporting obligations become operational, the Regulation becomes directly relevant to what companies do when technology fails. A manufacturer facing an exploited vulnerability may have only hours to assess the situation, report to the relevant authorities, coordinate with customers and suppliers and preserve its legal position, while the technical investigation is still underway. That is why I believe the real test of CRA readiness is not whether a company has completed a compliance assessment.
It is whether the company knows what to do when a product is hacked. And, when that happens, the legal response cannot wait until the technical response is over. It needs to start at the same time.