CRA reporting obligations from 11 September 2026: what you need in place before that date

The Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) entered into force at the end of 2024, but the first obligation with real teeth is scheduled for 11 September 2026. From that date, Article 14 applies: the obligation to report actively exploited vulnerabilities and severe incidents. The full product requirements follow on 11 December 2027, but anyone placing hardware or software on the EU market needs a working reporting process well before then. This article covers what the reporting obligation entails, who it applies to and how a short self-assessment shows whether you are ready.

What you have to report

The reporting obligation covers two situations. The first is an actively exploited vulnerability: a vulnerability in your product for which you have reliable evidence that a malicious actor is actually exploiting it. A vulnerability you find and patch yourself before any exploitation does not fall under this. Neither does a routine security update. It is about the moment when vulnerability and actual exploitation come together.

The second situation is a severe incident affecting the security of the product itself. Think of a compromise of your build or update environment through which malicious code could end up in the product, or an impact on the availability, integrity or confidentiality of sensitive functions or data in the product.

Both categories are about the product, not about your organization. That is the essential difference with the incident reporting duty under NIS2 and the Dutch Cybersecurity Act, which concern services and organizations. A manufacturer can face both reporting duties at the same time.

The reporting stages: 24 hours, 72 hours, final report

Article 14 works with a staged regime. For an actively exploited vulnerability: an early warning within 24 hours of becoming aware, a vulnerability notification within 72 hours with the nature of the vulnerability, its severity and any corrective measures taken or planned, and a final report no later than 14 days after a corrective or mitigating measure is available. For a severe incident, the first two stages are the same (24 and 72 hours) and the final report follows within one month after the incident notification.

Reports go to ENISA and to the CSIRT designated as coordinator in the member state where you have your main establishment. Under the regulation, that is the member state where the decisions on the cybersecurity of your products are predominantly taken. Both notifications run through a joint electronic reporting platform. In addition, where relevant, you must inform the impacted users of the product about the incident or vulnerability and about measures they can take themselves.

Who falls under the reporting obligation

The reporting obligation rests on the manufacturer of a product with digital elements made available on the EU market. You are also a manufacturer if you develop and commercially offer software, sell an existing product under your own name or make a substantial modification to it. Importers and distributors have a derived role: if they learn of a vulnerability in a product, they must inform the manufacturer.

Importantly, from 11 September 2026 the obligation applies to products that are on the market at that point, including products you released years ago and still support. Waiting for the next product release is not an option.

What this requires operationally

You do not meet a 24-hour deadline with a procedure on paper. You need a chain that can do three things: detect, decide and report. Detecting means that vulnerability reports actually reach you: a published security policy with a contact point for reporters (coordinated vulnerability disclosure), monitoring of your own telemetry and of external sources on active exploitation. Deciding means someone with a mandate can assess within hours whether something is reportable, including on a Saturday night. Reporting means you know where the reporting platform is, who has access and what information the first notification minimally requires.

If you already run an incident response process for ISO 27001 or NIS2, you have a foundation, but no more than that. The CRA reporting duty requires product knowledge: which versions are affected, what the corrective measure is, how you reach the users of the product. That requires cooperation between security, product development and support that you have to organize in advance.

Self-assessment: are you ready?

Walk through the following questions. Every no is an action item for the coming months. Prefer an interactive version? The Dutch edition of this article includes an extended interactive check that also determines whether and in which role the CRA applies to you: www.secureaudit.nl/cra-check.

1. Do you know whether your products fall under the CRA and in which role (manufacturer, importer, distributor or own-brand seller)? 2. Do you have a current overview of all products and versions on the EU market, including the support period per product? 3. Do you have an up-to-date Software Bill of Materials per product, so that a vulnerability in a component immediately tells you which products are affected? 4. Is there a published contact point where researchers and users can report vulnerabilities, and is that mailbox monitored? 5. Do you actively monitor for signs of exploitation, for example through threat intelligence, your own telemetry and customer reports? 6. Is it defined who assesses whether a vulnerability or incident is reportable, and is that role covered outside office hours? 7. Can you demonstrably submit a first notification within 24 hours, including access to the reporting platform and a template for the early warning? 8. Is there a process to deliver the follow-up information within 72 hours: nature and severity of the vulnerability and the corrective measures? 9. Can you inform the users of your product in a targeted way, and do you know which channel you will use? 10. Have you exercised the process, for example with a tabletop exercise around a fictitious actively exploited vulnerability?

Ten times yes does not mean you are done with the CRA, but it does mean the September reporting duty will not cause panic. Mostly no: start now, because several of these items (building SBOMs, setting up a disclosure policy, exercising) take months.

After September comes December 2027

The reporting obligation is the first stage. On 11 December 2027 the full requirements apply: essential cybersecurity requirements for product design, conformity assessment and CE marking, technical documentation and structured vulnerability handling throughout the support period. Non-compliance with the essential requirements can lead to fines of up to 15 million euros or 2.5 percent of worldwide annual turnover. If you set up the reporting process properly before September 2026, you lay the foundation for that second stage at the same time: you will need the same inventory, the same SBOMs and the same vulnerability process again.

Source: Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 14 (reporting obligations), Article 69 (transitional provisions) and Article 71 (application dates), via EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/2847/oj

Secure Audit helps manufacturers, importers and distributors assess their CRA obligations, set up the reporting process and vulnerability handling, and prepare for the December 2027 conformity assessment. Contact us for a CRA readiness scan.