The CRA obligations to report vulnerabilities and incidents become applicable on 11 September 2026, while the remainder of the CRA provisions become applicable on 11 December 2027. Most compliance programmes have been built around the later date, when the product-facing requirements – security by design, technical documentation, conformity assessment and CE marking – start to apply.
However, the CRA reporting obligations apply earlier and reach further than many manufacturers expect.
Who is caught
The obligations fall on manufacturers of products with digital elements: software or hardware products and their remote data processing solutions, including components placed on the market separately. The CRA applies where the product's intended purpose or reasonably foreseeable use includes a direct or indirect data connection to a device or network. An indirect connection through another device is enough, as is a connection the manufacturer did not intend but which is reasonably foreseeable.
The range of products caught by the CRA is accordingly wide:
- industrial equipment such as programmable logic controllers, IoT gateways and production line sensors;
- network infrastructure such as routers, switches and firewalls;
- office equipment such as multifunction printers, payment terminals and remotely accessible CCTV; and
- consumer products from smart thermostats and electronic locks to connected toys.
Software that executes remotely and is merely accessed by the user is out of scope, unless it supports the functionality of a product with digital elements.
Manufacturer status does not depend on who built the product. An organisation that places a product on the market under its own name or trade mark takes on the manufacturer obligations, as does one that assembles bought-in components into a new product supplied under its own name.
What must be reported
Two events are reportable:
1. an actively exploited vulnerability, meaning one where there is reliable evidence of exploitation by a malicious actor without authorisation; and
2. a severe incident having an impact on the security of the product, meaning one that negatively affects the product's ability to protect the availability, authenticity, integrity or confidentiality of data, or that introduces malicious code into the product or its users' systems.
The existence of a vulnerability, however serious, does not by itself trigger a reporting obligation – the clock starts only once there is reliable evidence of active exploitation. Voluntary reporting is available, and worth considering where the classification of an event is uncertain.
Products already on the market
Products placed on the market before 11 December 2027 are generally subject to the CRA only if they are substantially modified after that date. The reporting obligations are an express exception and apply regardless of when a product was placed on the market. Whether the manufacturer still supports it is not relevant: the Commission guidance published in July 2026 confirms that reporting continues after a product is no longer supported, unlike vulnerability handling, which runs only for the support period. See our article EU Cyber Resilience Act – European Commission finalises guidance for more information.
The boundary is knowledge rather than existence. The CRA does not require manufacturers to sweep their historic portfolio, and reporting is not retroactive. However, manufacturers do not control how the knowledge arrives – a customer complaint, a distributor notification or a media report starts the clock in the same way. Defining what counts as becoming aware, and who makes that assessment, is the practical priority.
Vulnerabilities in third-party components
Where a product contains an actively exploited vulnerability originating in a third-party component, the manufacturer of the finished product must report it. Where the manufacturer knows that a component contains a vulnerability which either cannot be exploited in its own product – for example because the vulnerable code is not reachable, or has not been exploited in it – mandatory reporting does not arise. From 11 December 2027 the manufacturer must in addition handle the vulnerability and report it upstream to the component's maintainer.
Exploitability in the manufacturer's own product is therefore a judgement someone has to make quickly and justify afterwards. Supplier contracts should require notice of vulnerabilities early enough to meet the CRA deadlines, and manufacturers supplying business customers should expect the same commitments to be sought from them.
The deadlines: 24 hours, 72 hours, 14 days and one month
Deadlines run from the point at which the manufacturer becomes aware of the event, which the Commission guidance treats as the moment an initial assessment gives it a reasonable degree of certainty.
- 24 hours – an early warning to the coordinating CSIRT (a member state’s Computer Security Incident Response Team) and ENISA (the EU Cybersecurity Agency).
- 72 hours – a fuller notification, including a description of the event and the corrective or mitigating measures taken or planned.
- 14 days – a final report for an actively exploited vulnerability, running from the point at which a corrective or mitigating measure is available.
- One month – a final report for a severe incident, running from the 72-hour notification.
The early warning does not require a complete analysis: it is enough to indicate that the manufacturer is dealing with a reportable event and to identify the member states in which the product is available. Manufacturers must also inform affected users, on a risk-based basis rather than by public disclosure.
How to report: the Single Reporting Platform
Reports are submitted once, through a single reporting platform operated by ENISA, and routed simultaneously to the CSIRT designated as coordinator for the member state of the manufacturer's main establishment and to ENISA. ENISA has committed to the platform being operational on 11 September 2026.
Overlapping reporting regimes
Many in-scope manufacturers are also essential or important entities under NIS2 Directive and its national implementing legislation, financial entities or ICT service providers under DORA, and most fall under the GDPR. The regimes have not been aligned: thresholds and recipients differ, and the deadlines are only superficially similar.
- CRA – the manufacturer reports an actively exploited vulnerability or a severe incident affecting product security to the coordinating CSIRT and ENISA, within 24 and 72 hours of becoming aware.
- NIS2 – an essential or important entity reports a significant incident to a national or sectoral CSIRT, with national implementations differing on the triggering moment and the receiving body.
- DORA – a financial entity reports a major ICT-related incident to its competent authority, with an initial notification within 4 hours of classifying the incident as major and in any event no later than 24 hours of becoming aware, an intermediate report within 72 hours and a final report within one month.
- GDPR – the controller notifies a personal data breach to the supervisory authority within 72 hours of becoming aware, and informs data subjects where the risk is high.
A single event can therefore trigger several obligations at once, on clocks starting at different moments. The Digital Omnibus package proposes a single entry point across these regimes, but it would not resolve the underlying divergence: the thresholds and deadlines would remain as they are, with only the reporting channel consolidated. The proposal is still in the legislative process. For more information, see our article EU Digital Omnibus proposals to reform data and AI laws – the official version.
Penalties
Breach of the reporting obligations sits in the CRA's highest penalty tier: fines of up to EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher, against EUR 10 million or 2% for other infringements. Market surveillance powers may matter more – authorities can require a product to be withdrawn or prohibit it from being made available in the EU.
What do in-scope organisations need to do?
In-scope organisations should:
- map their products with digital elements, including those already on the market, and confirm their role – manufacturer, importer or distributor – for each;
- define what constitutes an actively exploited vulnerability and a severe incident for their products, what counts as becoming aware, and who makes that assessment;
- establish the internal decision path – who decides to report, who signs off, and how the decision and its basis are recorded, including where the conclusion is not to report;
- align CRA reporting with existing NIS2, GDPR and, where relevant, DORA procedures, so that a single event does not produce inconsistent notifications; and
- review supplier and component contracts to secure vulnerability information early enough to meet the CRA deadlines, and expect business customers to seek equivalent commitments in the other direction.
