No substantiated regulatory update: the deadline has already begun
The reporting obligation under the Cyber Resilience Act (CRA) has applied to manufacturers since 11 September 2026, according to the European Commission page on reporting obligations. That date matters, but the documentation provided does not substantiate an announcement of a legislative change or a new rule now. The subject is therefore better understood as an implementation guide than as news about a recent amendment. European Commission: reporting obligations.
The obligation concerns two cases: actively exploited vulnerabilities and serious incidents affecting the security of a product with digital elements. It is not a requirement to report every flaw, alert, or vulnerability found during development. The threshold matters: manufacturers need to define a classification and response process before receiving an urgent report. Regulation (EU) 2024/2847, text published in the Official Journal.
The later date for the Regulation’s general application should not be confused with this specific start date. The Commission says manufacturers’ reporting obligations began in September 2026, while the Regulation sets other dates for different obligations and actors. Application should be checked against the relevant article, not inferred from a single general date.
What must be reported—and what falls outside the requirement
The first case is a vulnerability that is being actively exploited. The mere existence of a defect, even one that could have security consequences, does not by itself establish that this criterion is met. The second case is a serious incident affecting product security. The Commission presents both categories as the subject of manufacturers’ reporting duty. European Commission: reporting obligations.
This distinction helps separate regulatory reporting from routine vulnerability management. A manufacturer needs to address and fix security problems throughout a product’s life cycle, but the reporting obligation described here is triggered in the specific cases set out by the CRA. If there is doubt about whether a particular case meets the threshold, secondary guidance does not replace the legal text or a legal assessment of the incident.
The CRA applies to products with digital elements made available on the Union market, according to the Commission’s summary. It is not limited to connected household devices: its scope also includes software and components, although the classification of a particular product must be checked against the full text and its exclusions. European Commission: summary of the legislative text.
Deadlines depend on when the case becomes known
The sequence begins when the manufacturer becomes aware of an actively exploited vulnerability or a serious incident. The Commission sets an early warning within 24 hours and a complete notification within 72 hours. These periods do not run from the publication of a patch, or from the moment a third party discovers the problem if the manufacturer does not yet know about it, according to the starting point summarised by the Commission. European Commission: reporting obligations.
A final report is then required, but the reference point differs by case. For actively exploited vulnerabilities, the limit is 14 days from the availability of a corrective measure. For serious incidents, the deadline is one month from the 72-hour notification. The two cases should not be reduced to a single timetable: the nature of the case determines how the final stage is calculated.
| Stage | Deadline indicated by the Commission | Time reference |
|---|---|---|
| Early warning | 24 hours | From when the manufacturer becomes aware of the case |
| Complete notification | 72 hours | From when the manufacturer becomes aware of the case |
| Final report: exploited vulnerability | 14 days | From when a corrective measure becomes available |
| Final report: serious incident | One month | From the 72-hour notification |
The deadlines and their starting points come from the European Commission’s summary; in a real case, consult Article 14 of the Regulation and the current operational instructions. Regulation (EU) 2024/2847.
Who reports, and why the platform matters
The party with the obligation is the manufacturer. The Commission says the report is submitted once through the CRA’s single reporting platform and addressed to the CSIRT designated as coordinator in the Member State where the manufacturer has its main establishment. The information is also made available to ENISA, under the mechanism described by the Commission. European Commission: reporting obligations.
ENISA maintains a dedicated page for the Single Reporting Platform (SRP) and publishes guidance materials relating to registration and the submission of reports. This documentation helps explain the channel, but the existence of a page or user instructions does not by itself prove that every function is available to every user at all times. Operational availability should be checked on the platform itself and in the current official instructions. ENISA: Single Reporting Platform.
For product and security teams, the practical consequence is organisational: they need to be able to detect a case, escalate it, record when it became known, and quickly decide whether it fits one of the reportable categories. This is not an additional list of textual requirements, but an operational inference from deadlines that begin when the case becomes known. It is sensible to assign owners and prepare coordination among security, product, support, and legal teams.
Open-source software stewards have a different timetable
The Commission says that open-source software stewards become subject to related reporting obligations from 11 December 2027, under Article 24(3) and the timetable in Article 71(2). This date differs from the start of manufacturers’ obligations, which began in September 2026. European Commission: reporting obligations.
It should not be assumed that everyone contributing to an open-source project is automatically a steward, or that the manufacturers’ timetable applies unchanged to every community project. Classification depends on the Regulation’s definitions and conditions. The official summary helps locate the issue, but the text published in the Official Journal is the legal reference for determining the scope in a specific situation. Regulation (EU) 2024/2847.
For organisations that develop or maintain open-source software, the prudent step is to identify who performs the relevant role and check whether the work is carried out under the conditions set by the CRA. The future date leaves time to prepare processes, but it does not justify anticipating a legal classification without examining the specific activity.
What to check before treating a case as reportable
The official information establishes the timetable, general categories, and reporting channel. It does not, by itself, resolve every technical nuance of a particular vulnerability or incident. For a documented decision, the responsible team can start with these checks:
- Identify the product and responsible party: check whether it is a product with digital elements within the Regulation’s scope and who acts as the manufacturer.
- Determine the case type: distinguish an actively exploited vulnerability from a serious incident and document the available indications.
- Record when the case became known: preserve the timeline needed to apply deadlines from the stated starting point.
- Consult the official procedure: review Article 14 and current SRP information, and escalate the case if its classification is unclear.
The Regulation does not turn every flaw into an automatic report, but it is also unwise to wait for an investigation to be complete before starting to assess the deadlines. The 24-hour window makes an early assessment process important. This is a practical implication of the legal time limits, not a measurement of how long companies take or a claim that an additional internal procedure is legally required.