A specific obligation, not the full application of the CRA
On 11 September 2026, the Cyber Resilience Act (CRA) reporting obligation for manufacturers began to apply. Manufacturers must report actively exploited vulnerabilities and certain serious incidents affecting the security of products with digital elements. The date matters, but it should be described precisely: it does not mean that every obligation in the regulation started on that day, or that every security problem must automatically be reported through this channel. The immediate scope is narrower and depends on whether the conditions set out in the legislation are met. The start date introduces a specific reporting duty, not a fully applicable regime.
The CRA is Regulation (EU) 2024/2847, an EU framework setting cybersecurity requirements for products with digital elements. The European Commission distinguishes between reports that are already required and other provisions that will apply later. For product, security and compliance teams, the task is therefore not to assume that every future obligation is already active. It is to identify the cases covered by the reporting duty and establish a procedure for recognising and escalating them. A clear distinction between the reporting phase and the wider timetable helps organisations avoid both under-reporting and treating every security concern as a statutory report. This article addresses that initial obligation and its practical implications, rather than claiming that the whole regulation is already in force.
Who is covered and which cases should trigger a review
The obligation currently applies to manufacturers of products with digital elements within the scope of the CRA. The Commission’s guidance describes two reportable situations: an actively exploited vulnerability and a serious incident that has an impact on the security of the product. Reporting should not, therefore, be treated as a general list of faults, alerts or potential vulnerabilities. An organisation needs to assess whether the facts fit the legal categories and retain a documented basis for its decision. A signal may warrant investigation without necessarily meeting the threshold for a report; equally, a case that does meet the threshold should not be missed because it was first handled as an ordinary technical issue.
The term manufacturer has a regulatory meaning; it is not simply another name for every developer or team involved in software. The legislation organises duties according to the role played by each economic operator and also includes provisions for open-source software stewards. The Commission says that reporting duties for these stewards begin on 11 December 2027, not at the start of the current manufacturer phase. Where supply chains, third-party components or products built on open-source software are involved, organisations should establish who is responsible under the regulation before assigning the reporting task. A company’s technical label does not replace an assessment of its legal role. This can require looking beyond who wrote a particular component to the way the product is placed on the market and the responsibilities assigned by the CRA. Technical involvement alone does not determine legal responsibility.
The reporting deadlines
According to the Commission, the process includes an early warning within 24 hours of the manufacturer becoming aware of the case, followed by a complete notification within 72 hours. It also requires a final report, with deadlines that vary according to the situation: for actively exploited vulnerabilities, no later than 14 days after a corrective measure becomes available; for serious incidents, within one month after the 72-hour notification. These are separate milestones, not a single deadline calculated from discovery. The different stages reflect the need to alert the relevant authorities promptly while allowing information to be completed as the response develops.
The reference to when the manufacturer becomes aware makes the way an organisation detects, validates and escalates signals important. An internal process that waits for the entire investigation to be completed before involving the responsible functions could make an early warning difficult to meet. At the same time, submitting an initial notification does not remove the need to complete the information and issue a final report where required. The regulation and official instructions should guide how the deadlines are interpreted in each case. An operational response should distinguish initial assessment, complete notification and closure, with named owners and records for each stage. Recording when the organisation became aware, and how the case was assessed, can also help it manage the separate reporting steps consistently.
The single platform and how a report is routed
Manufacturers submit reports through the CRA Single Reporting Platform (SRP), established by ENISA in cooperation with the CSIRT network. The channel has been operational since 11 September 2026. The Commission says the manufacturer submits a notification once: it is sent to the CSIRT in the Member State where the manufacturer has its main establishment and, except in exceptional circumstances, the information is made available to ENISA at the same time. The single submission is intended to provide a defined route into the reporting system rather than require a manufacturer to send separate initial reports to every relevant recipient.
The receiving CSIRT shares the notification without delay with the other CSIRTs in whose territories the product has been made available on the market. The Commission also notes that, in exceptional circumstances and for justified cybersecurity reasons, dissemination to other teams may be delayed. The platform should therefore not be understood as an open publication mechanism, or as a process through which a company individually selects every recipient. In practical terms, internal procedures should identify who can prepare a submission, who authorises it and how the reported information is recorded. ENISA publishes guidance materials for using the platform; those instructions help with the reporting channel but do not replace legal analysis of the obligation’s scope. Organisations should make sure the people responsible can access and use the SRP when a report is needed.
What this phase does not allow us to conclude
The fact that the reporting obligation is active does not mean that all substantive provisions of the CRA already apply. The general date set for application of most of the regulation is 11 December 2027, while reporting began earlier. This staggered timetable explains why a company may need to prepare and submit reports now while continuing to work towards other duties whose application date has not yet arrived. Treating those dates as distinct helps teams plan accurately without either delaying the current reporting work or misrepresenting the status of later requirements.
Nor should this description be read as a conclusion that every organisation writing or distributing code is a manufacturer, or that every cloud-hosted service falls within the CRA. The regulation defines its scope by reference to products with digital elements and particular functions, and includes specific conditions for remote data processing solutions linked to a product. This article summarises the initial reporting obligation; it does not decide individual questions about classification, exemptions or interaction with other EU rules. Where a product or business model sits near the boundary of the legal scope, the answer requires review of the legislation and applicable official clarifications. General guidance can orient an assessment; it cannot replace analysis of the particular case.
What organisations should prepare now
A useful preparation exercise can start with an inventory of products made available on the EU market, the manufacturers responsible for them and the channels through which vulnerability and incident reports are received. The organisation can then define escalation criteria that enable a prompt assessment of whether a case might involve active exploitation or a serious incident affecting product security. This work does not assume that every signal must be reported. Its purpose is to ensure that a decision reaches the appropriate people in time, and that relevant facts are not lost as information moves between technical, security, legal and compliance teams.
It is also sensible to assign roles for assessing a case, gathering technical information, validating the notification and submitting it through the SRP. Organisations should keep a record of when they became aware of the facts and of the decisions made, because the official deadlines run from that awareness and notifications involve several stages. Finally, the compliance calendar should distinguish the milestone already in force from 11 September 2026 and the obligations that begin on 11 December 2027. A practical starting point is to verify scope, rehearse the decision-making flow and consult ENISA’s official platform instructions. Do not assume reporting is universal, and do not wait until the last moment to decide who is responsible for responding.