Cyber Resilience Act: reporting duties from 11 September 2026

01

Facts: what changed on 11 September 2026?

The Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force on 10 December 2024. The European Commission states that the reporting obligations for actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements apply from 11 September 2026.

Most other CRA obligations will apply from 11 December 2027. Reporting is therefore not merely preparation for future compliance: it already applies to manufacturers within scope. The official and legal information in this article was checked on 21 September 2026. It is general operational information, not individual legal advice.

02

Facts: who is covered by CRA reporting?

The CRA covers products with digital elements made available on the EU market, including hardware and software and their remote data processing solutions. The reporting duties discussed here are directed primarily at manufacturers. Simply using software or equipment in a business does not make that user its manufacturer.

The first task is to determine the company’s role for each product: whether it develops and markets it under its own name or trademark, or acts as an importer, distributor, integrator or user. The CRA contains exclusions and specific rules, so borderline cases should be checked against the Regulation and the Commission guidance published on 27 July 2026.

• an application, library or device offered to customers may need a scope assessment;
• a product sold under the company’s own brand requires a manufacturer-role check even when a supplier performs some development;
• open-source components do not automatically remove a commercial product from scope;
• the Article 24(3) reporting duty for open-source software stewards will apply from 11 December 2027.

03

Facts: what must be reported and when?

The European Commission distinguishes an actively exploited vulnerability from a severe incident affecting product security. Not every defect or service ticket automatically meets those tests, but the classification decision should be fast, documented and based on the current CRA definitions.

For both categories, the manufacturer submits an early warning within 24 hours of becoming aware and a full notification within 72 hours. For an actively exploited vulnerability, the final report is due 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.

• 24 hours: early warning after becoming aware of the event;
• 72 hours: fuller notification with the information and assessment available;
• vulnerability: final report within 14 days after a corrective or mitigating measure is available;
• severe incident: final report within one month of the 72-hour notification.

04

Facts: where is the notification submitted?

ENISA launched the Single Reporting Platform on 11 September 2026. A manufacturer reports once through the platform to the CSIRT responsible for the Member State of its main establishment; except in particularly exceptional circumstances, the information is made available to ENISA at the same time.

ENISA provides registration and notification guidance, a field glossary, FAQs and training materials. Businesses should use the current versions because the agency notes that the platform documentation may be updated as the service develops.

05

WEBee recommendation: design a process that fits inside 24 hours

The main operational risk is not the form itself, but time lost identifying the product, owner, impact and person authorised to decide. The process should start when monitoring, a researcher, customer, supplier or support team provides a credible signal.

Name a reporting owner, a deputy and an out-of-hours route. The team should have a simple classification matrix, a clock recording when awareness was established, an evidence repository and an approval path that does not require a large committee before an early warning can be sent.

• an inventory of products, versions, owners and markets;
• one intake channel for vulnerability and incident reports;
• escalation criteria and a named classification owner;
• an awareness timestamp and alerts before the 24- and 72-hour limits;
• SRP accounts and roles prepared before an event;
• a controlled log of decisions, evidence, communications and corrective actions.

06

WEBee recommendation: run a readiness exercise

Use a short realistic scenario: an external researcher reports an exploited vulnerability in a product used by customers in several countries. Measure the time needed to identify affected versions, classify the event, collect minimum information and draft the notification. The resulting gap list is more useful than a general statement of compliance.

Review contracts with component suppliers, hosting providers and security partners at the same time. They should support rapid transfer of information and evidence, but the manufacturer’s process should not depend entirely on a subcontractor responding. A readiness audit can connect the product map, vulnerability handling, roles, tools, integrations and the roadmap to 2027.

• confirm which products and company roles need a CRA assessment;
• check contact details, deputies and SRP account readiness;
• test both vulnerability and severe-incident scenarios;
• measure time from the first signal to a decision and draft report;
• close gaps in monitoring, contracts, instructions and evidence retention;
• plan the remaining product-security obligations before 11 December 2027.