Cyber Resilience Act: reporting duties starting on 11 September 2026

A manufacturer discovers that attackers are exploiting a vulnerability in a connected product. Under the Cyber Resilience Act, the first legal question is no longer just when a patch can be released: it is also when the manufacturer became aware of the exploitation and when the reporting clock started. Certain reporting duties begin on 11 September 2026, well before the regulation's main application date.

This is a targeted obligation for products and operators within the regulation's scope. It does not turn every security bug, failed login or general IT problem into a reportable CRA incident. The distinction matters because both the reporting threshold and the deadlines depend on what actually happened.

What begins on 11 September 2026

Regulation (EU) 2024/2847, the Cyber Resilience Act or CRA, generally applies from 11 December 2027. Article 14 reporting duties apply earlier, from 11 September 2026. The European Commission's reporting guidance distinguishes these dates: an organisation should not assume that every CRA requirement starts in September 2026, or postpone the specific reporting duties until December 2027.

Article 14 concerns two main situations: an actively exploited vulnerability contained in a product with digital elements, and a severe incident affecting the security of such a product. The manufacturer must assess each against the relevant legal definition.

Which products and organisations are affected

The CRA covers products with digital elements made available on the EU market whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. The scope can include hardware, software and certain remote data-processing solutions needed for a product's functions. Sector-specific exclusions and special rules must also be checked.

The Article 14 reporting duties addressed here fall on manufacturers. A business is not automatically a manufacturer simply because it uses software or sells somebody else's connected device. Conversely, placing a product on the market under its own name or trademark can affect its legal role. Importers, distributors and organisations substantially modifying products need a separate assessment of their responsibilities.

Free and open-source software developed or supplied outside the course of a commercial activity falls outside the CRA's scope. That is not an exemption for every product containing open-source components. The separate obligations for open-source software stewards apply from 11 December 2027. The Commission's CRA overview explains the regulation's structure and scope.

An exploited vulnerability is different from an ordinary bug

An actively exploited vulnerability requires reliable evidence that a malicious actor has exploited it in a system without the system owner's permission. A theoretical weakness, a scanner alert or a proof of concept does not automatically establish that threshold. Equally, a manufacturer should not ignore credible exploitation evidence merely because its technical investigation is incomplete.

A severe incident affecting product security is a separate category. Its assessment concerns the product's ability to protect important or sensitive data or functions, or the introduction or execution of malicious code in the product or a user's network and information systems. A vulnerability and an incident can overlap, but their final reporting deadlines differ.

How the 24-hour, 72-hour and final deadlines work

The early stages run from the manufacturer's awareness, not from completion of an internal investigation or a management meeting. The statutory requirements also include acting without undue delay: the outer time limit is not a reason to wait where a report can responsibly be submitted earlier.

The 72-hour deadline is not an additional 72 hours after the early warning. Both initial periods start from awareness. For the final report, do not substitute the vulnerability's 14-day rule for the incident's one-month rule. Article 14 sets out the information required at each stage; later findings can be supplied through the appropriate follow-up.

A practical timeline

Assume a manufacturer becomes aware of active exploitation on 14 September 2026 at 10:00. The early-warning outer limit is 15 September at 10:00; the notification outer limit is 17 September at 10:00. If a corrective or mitigating measure becomes available on 18 September, the vulnerability final-report deadline is 2 October.

This is an illustration of the two starting points, not a determination of when a real business legally became aware. Preserve the original technical alerts, incident chronology, escalation messages, assessment decisions and the time a measure became available. A record created afterwards should not overwrite the original evidence.

The reporting platform and a readiness checklist

Reports use the Single Reporting Platform (SRP), with the relevant coordinating CSIRT and ENISA receiving them under the regulation's arrangements. In its guidance updated on 8 September, ENISA states that the platform is scheduled to start operating on 11 September 2026. That announcement does not establish that ordinary submissions are already available or that this publication has tested a submission.

1. Map products and versions: identify owners, important components and the markets where products are supplied.
2. Provide a clear intake route: decide who receives reports from customers and researchers and who assesses them promptly.
3. Identify a representative and a backup: clarify reporting responsibility and prepare the representative's personal EU Login with multifactor authentication.
4. Keep one incident chronology: record awareness, evidence, decisions, notifications and availability of corrective measures.
5. Prepare user instructions: specify the affected versions and the concrete action a user should take.
6. Run a hypothetical exercise: check that internal decisions and handovers fit the legal time limits.

This checklist is a practical organisational proposal. ENISA recommends starting manufacturer registration in the SRP when a report needs to be submitted, with the representative's EU Login already active. Check the current official SRP questions and answers for operational details.

Why GDPR and NIS2 need separate checks

A CRA report should not be treated as automatic fulfilment of every other notification duty. The GDPR addresses personal-data breaches. Where Article 33 requires notification, a controller must notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to individuals' rights and freedoms. The European Data Protection Board's breach guidance explains that assessment.

NIS2 concerns particular categories of entities and significant incidents affecting their services. Whether the relevant national framework applies must be assessed independently. One event may therefore require several assessments and notifications with different recipients and content. The Commission's NIS2 overview provides the wider context.

Frequently asked questions

Does this cover products already on the market?

Yes. The reporting duties also cover in-scope products placed on the market before 11 December 2027. An earlier release date is not, by itself, an exemption.

Must every old vulnerability be reported retrospectively?

ENISA explains that the reporting duty is not retrospective for active exploitation of which the manufacturer was already aware before 11 September 2026. Awareness matters, rather than the age of the underlying bug alone.

Is notifying the authorities enough?

Article 14(8) also provides for informing affected users, including the necessary risk-mitigation measures. A technical report to the authorities and clear instructions for users serve different purposes.

For transitional cases, consult the ENISA answers and CRA Articles 14, 69 and 71.

Nomika Epilekta Editorial Team
Official sources checked: 9 September 2026.

This article was prepared with artificial intelligence assistance and cross-checking of the cited official sources. It provides general legal information and does not replace assessment of a specific case. Sources checked: 9 September 2026.