EU Cyber Resilience Act: reporting duties from September 2026

The EU Cyber Resilience Act (CRA) did not start applying in full on 11 September 2026. That date marks the start of its reporting obligations: from then on, affected manufacturers must report certain actively exploited vulnerabilities and serious incidents that have an impact on the security of their products with digital elements. The regulation’s general application is scheduled for 11 December 2027. These are two separate milestones, and confusing them may lead people to mistakenly believe either that all the Act’s obligations already apply or, conversely, that none of them is in force yet.

The measure is Regulation (EU) 2024/2847. Its scope covers hardware and software products with digital elements placed on the Union market, including certain components marketed separately. It is not a universal obligation on anyone who discovers a flaw: the main reporting obligations in Article 14 apply to manufacturers when the criteria set out in the regulation are met. The Commission describes the CRA as a horizontal framework of cybersecurity requirements for these products; to resolve specific cases, however, it is necessary to consult the legal text and determine whether the product and entity fall within its scope. European Commission: CRA overview and text of the regulation.

The reporting obligation is not triggered by every potential vulnerability or every IT incident at a company. According to the Commission’s guidance, it concerns actively exploited vulnerabilities and serious incidents that have an impact on the security of a product with digital elements. The assessment therefore requires distinguishing a known or theoretical problem from one that is being exploited, and determining whether an incident affects product security. The guidance summarises the regime; it does not replace the regulation’s definitions, conditions and exceptions. European Commission: reporting obligations.

The main party subject to the obligation is the manufacturer, not automatically every user, researcher or distributor who reports a flaw. The law also provides for obligations on open-source software stewards, but under a different provision and timetable: the Commission places their application from 11 December 2027, under Article 24(3) and Article 71(2). This does not mean that every open-source project, solely by virtue of being open source, already has the same obligations as a manufacturer. An entity’s classification and its particular role in the product lifecycle matter; when in doubt, it is not advisable to decide the issue solely on the basis of a commercial label or the fact that the code is open source.

The deadlines start when the manufacturer becomes aware of the relevant event. The Commission’s guidance sets an initial alert within a maximum of 24 hours and a more complete notification within a maximum of 72 hours. For an actively exploited vulnerability, the final report must be submitted no later than 14 days after a corrective measure becomes available. In the case of a serious incident, the final report is due within one month of the 72-hour notification. These are separate clocks and should not be reduced to a single response deadline.

The table summarises the deadlines published by the Commission, but it does not replace Article 14 or include every detail of each procedure. In particular, companies must distinguish which event category they are reporting and record when they became aware of it and when the corrective measure became available. The official guidance sets out the deadlines as part of the CRA reporting regime. Source.

The Commission says that manufacturers submit a single report through the Single Reporting Platform (SRP), a common platform for the CRA regime. The report is sent to the computer security incident response team (CSIRT) for the place where the manufacturer has its main establishment. The Commission also explains that, except in particularly exceptional circumstances, the information is shared with other relevant authorities. Thus, “once” describes the indicated submission channel, not a guarantee that there will be no further interactions with authorities.

ENISA publishes the SRP page and supporting materials, including FAQs and user guides. These resources help explain the channel and its functions; they do not, by themselves, change who must report, which facts trigger the obligation or what the legal deadlines are. For affected organisations, a practical check is to identify in advance the internal owner, the process for escalating events and the information needed to submit and update a report. The platform is part of the reporting process, but it does not replace technical vulnerability management or the duty to take corrective measures. ENISA: Single Reporting Platform.

For manufacturers, the September 2026 date is a reason to review whether their products fall within the CRA’s scope and whether their processes allow them to respond within the deadlines. Preparation may include a procedure for recording the time of awareness, classifying the event, coordinating technical and legal teams and preparing successive communications. It is also worth reviewing products already placed on the market: the Commission’s guidance sets out the date and reporting categories, while the legal text must be consulted for the scope and transitional provisions that apply to a particular case.

For people who buy or use devices and software, the date does not mean they must submit these reports or that all products have suddenly received a new certification. The CRA also introduces manufacturer requirements for secure design, development and maintenance, but the regulation’s general application begins in December 2027. In practice, users can ask suppliers about updates, support and vulnerability management, without assuming that the reporting obligation’s start date by itself guarantees a product is free of flaws. Reporting a problem and eliminating it are related but distinct tasks.

The verifiable conclusion is limited: as of 3 October 2026, the CRA reporting obligations have applied since 11 September to manufacturers and to the events described by the Commission; the regulation’s general application follows a different timetable, and the specific obligation for open-source software stewards begins in December 2027. The Commission identifies the SRP as the reporting channel and publishes the main deadlines. These facts are enough to correct the idea that the change is still only a future possibility, but not enough to resolve the situation of every company or product.

There are limits worth preserving. This explanation is based on the regulation and the Commission’s public guidance, together with ENISA’s operational resources; it includes no interviews or individual legal advice, and it does not seek to determine whether a particular product is covered or whether an incident meets the legal thresholds. Those answers depend on the facts and on reading the full text, including its definitions and exceptions. In a real situation, organisations should check Regulation (EU) 2024/2847 and the current SRP documentation, and seek specialist advice when the classification of the event or party is unclear.