The Cyber Resilience Act reporting portal is live. For manufacturers, the 24-hour clock starts when they become aware of the problem

The Cyber Resilience Act has reached the point where some of its obligations are no longer just something to worry about in 2027. Since 11 September 2026, manufacturers of products with digital elements have been required to report actively exploited vulnerabilities and severe incidents affecting product security. ENISA has launched the Single Reporting Platform (SRP) for exactly that purpose.

The key point is that not every vulnerability has to be reported. The CRA sets specific triggers: the vulnerability must be actively exploited, or there must be a severe incident affecting the security of the product. Once that happens, the clock starts running for the manufacturer.

24 hours is only the first step

• Within 24 hours of becoming aware of the event, the manufacturer must submit an early warning.
• Within 72 hours, the full notification must follow.
• For an actively exploited vulnerability, the final report must be submitted no later than 14 days after a corrective or mitigating measure becomes available.
• For a severe incident, the final report is due within one month of the 72-hour notification.

The manufacturer does not have to send separate forms to multiple countries. The notification goes through ENISA’s platform to the relevant CSIRT, and the system then distributes the information to the appropriate authorities. This is one of the more practical parts of the whole setup: instead of building a European collection of separate inboxes, there is one common reporting channel.

Who does this apply to – and who doesn’t it?

The CRA applies to products with digital elements made available on the EU market. In practice, that can include both software and hardware. It does not mean that every company with a website suddenly has to report a vulnerability in one of its WordPress plugins to ENISA.

What matters is the company’s role in relation to the product. A business that merely uses WordPress, WooCommerce, hosting or an external SaaS service does not become the manufacturer of those products. The situation can be different if the company develops and commercially makes available its own plugin, application, device or another solution covered by the CRA. In that case, it is much better to work out the role and reporting process before the first incident – not in hour 23.

What about open source?

This is where oversimplifying gets misleading very quickly. ENISA clearly distinguishes between manufacturers and open-source software stewards. The reporting obligations under Article 24(3) for open-source software stewards start applying on 11 December 2027. Simply publishing open-source code therefore does not automatically mean that, from September 2026, its maintainer is subject to the same reporting deadlines as the manufacturer of a commercial product.

The biggest problem may not be the form

The 24-hour period starts when the manufacturer becomes aware of an actively exploited vulnerability or a severe incident. That shifts the real challenge from simply “knowing how to report” to “being able to notice the problem in the first place”. A company without a clear route for receiving security reports, monitoring its own product and assigning responsibility for incident assessment can lose most of that time before anyone even realises a regulatory deadline has started running.

That is why the procedure should not start with a link to the ENISA portal. It should start with answers to much more basic questions: who receives a security report, who decides whether a vulnerability is being actively exploited, who can authorise the notification, where the necessary technical data is kept and who communicates with customers. The platform is the final stretch of that process.

WebsiteGarage says

EU digital law tends to turn into a competition for the most dramatic headline very quickly. The more interesting thing here is almost the opposite: the EU has launched a single reporting point and set a fairly concrete rhythm for notifications. For a company that really is a manufacturer covered by the CRA, this can be turned into a process instead of a panic ritual every time a CVE appears.

At the same time, copying obligations from somebody else’s checklist without first checking your own role is not a great idea either. An online store owner, a WooCommerce plugin manufacturer and a company selling an IoT device may all have very different obligations even though all three of them “do something on the internet”. First work out the role, then build the procedure. Do it the other way round and you get documents that look excellent in a folder and help surprisingly little during a real incident.