Cyber Resilience Act
Reporting obligations from 11 September 2026
The Cyber Resilience Act does not start applying all at once. The first part that really reaches companies is the reporting obligations in Article 14, and they apply from 11 September 2026.
The Cyber Resilience Act (CRA) has three dates of application, and the second of them is 11 September 2026. From that day, Article 14 applies: the duty to report actively exploited vulnerabilities and severe incidents. Under the schedule in Article 71(2), the rest of the regulation follows on 11 December 2027; only Chapter IV, the provisions on notification of conformity assessment bodies, has applied since 11 June 2026.
What applies on 11 September and what does not
The CRA does not take full effect on 11 September 2026. CE marking, conformity assessment, technical documentation and the essential cybersecurity requirements only arrive in 2027. What falls due first is Article 14 alone, but in full: notification to the authorities, the details that follow, and informing your own users.
One point here is easy to miss. Article 69(2) exempts products placed on the market before 11 December 2027 from the requirements of the regulation, as long as they do not undergo a substantial modification from that date. Article 69(3) makes exactly one exception, and it is Article 14: the reporting obligations apply to all products within scope that were placed on the market before 11 December 2027. So a maintained product line in the field is covered in full from 11 September 2026, not from the next release onwards.
Two triggers, not one
Article 14 sets out two separate occasions for reporting, each with its own clock.
- An actively exploited vulnerability contained in a product with digital elements, as soon as the manufacturer becomes aware of it (paragraph 1).
- A severe incident affecting product security (paragraph 3).
Paragraph 5 defines when an incident counts as severe, in two alternatives. Either it negatively affects or is capable of negatively affecting the ability of the product to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions. Or it has led or is capable of leading to the introduction or execution of malicious code in the product or in a user’s network and information system. Both alternatives include the word “capable”. The harm need not have materialised.
The rhythm: 24 hours, 72 hours, final report
Both occasions follow the same three stages, but the last stage runs differently.
- Without undue delay, and in any event within 24 hours of becoming aware: the early warning. For a vulnerability it names, where applicable, the Member States in whose territory the product has been made available, to the manufacturer’s knowledge. For an incident it must at least state whether the incident is suspected of being caused by unlawful or malicious acts.
- Without undue delay, and in any event within 72 hours of becoming aware: the notification itself. It carries general information, where available, about the product, about the nature of the exploit and of the vulnerability, or about the nature of the incident and an initial assessment of it, together with any corrective or mitigating measures taken and those users can take.
- The final report is due, for a vulnerability, no later than 14 days after a corrective or mitigating measure is available. For an incident it is due within one month of the 72-hour notification. One clock therefore starts when a remedy exists, the other when the previous notification was filed.
Between these stages, the CSIRT designated as coordinator may request an intermediate report with status updates under paragraph 6. Information already supplied need not be repeated: stages two and three each apply only to the extent that the relevant information has not already been provided.
Where the notification goes
Reporting goes to two places at once: the CSIRT designated as coordinator and ENISA. The route is the single reporting platform that ENISA establishes and operates under Article 16, with electronic notification end-points.
Which CSIRT is responsible follows from paragraph 7 and should be settled before the first real case. What counts is the Member State of the main establishment in the Union, meaning the state where decisions related to the cybersecurity of the products are predominantly taken. Where that cannot be determined, the establishment with the highest number of employees in the Union decides. Manufacturers without a main establishment in the Union work through a fixed order: authorised representative, importer, distributor, and finally the Member State with the largest number of users.
Users are part of the duty
Article 14 does not stop at the authorities. Under paragraph 8 the manufacturer also informs affected users about the vulnerability or the incident and, where necessary, about the measures they can take themselves. Where appropriate all users are to be informed, and where appropriate in a structured, machine-readable format. If this informing of users does not happen in time, the notified CSIRTs designated as coordinators may provide the information to users themselves where they consider it proportionate and necessary to prevent or mitigate the impact.
What this means for preparation
The 24-hour deadline is the real organisational demand. It runs from awareness, not from the start of business hours, and it does not recognise weekends. What should be in place by 11 September 2026:
- Round-the-clock availability with a clear deputy arrangement and the authority to file a notification at night,
- a product register that answers within minutes in which Member States a product has been made available and who the affected users are,
- the responsible CSIRT and access to its reporting end-point, established and documented before it is needed,
- a decision path for whether an incident meets the threshold in paragraph 5, because that judgement cannot begin during the event,
- prepared wording for the early warning, the notification and the user information, because nobody drafts well under a running clock.
A word on consequences: infringements of Article 14 fall into the highest tier of fines in the regulation under Article 64(2), up to EUR 15 000 000 or, for undertakings, up to 2.5 % of total worldwide annual turnover for the preceding financial year, whichever is higher. Article 64(10), point (a), exempts manufacturers qualifying as micro or small enterprises from the fines under paragraphs 3 to 9 in respect of the 24-hour deadline. The notification itself is still owed by small manufacturers. For open-source software stewards Article 14 applies only in part, and fines do not reach them at all under Article 64(10), point (b).
What is fixed is the route of the notification, not its form. How the information under paragraphs 2 and 4 has to be structured is not prescribed by the regulation; the Commission may specify the format and procedures by implementing acts under paragraph 10, and the input forms of the reporting platform will only be known with the platform itself. Preparation therefore works from the wording of Article 14: it says what has to be delivered.
Practical questions
-
From the moment the manufacturer becomes aware of the actively exploited vulnerability or the severe incident. The regulation turns on awareness alone and does not define that moment further. A defensible anchor for your own records is therefore the timestamp of the first credible internal report. Waiting to establish the root cause usually consumes the deadline.
-
Yes. Article 14(1) attaches to the active exploitation, not to whether the flaw still exists. A security update that has already shipped does not remove the duty to notify, it only shortens the path to the final report: that is due no later than 14 days after a corrective or mitigating measure is available.
-
Yes. Article 69(3) expressly makes the obligations in Article 14 applicable to all products within scope that were placed on the market before 11 December 2027. That is the exception to the rule in paragraph 2, under which existing products otherwise fall under the regulation only upon a substantial modification. For the reporting obligations, the whole installed base counts.
The bottom line
11 September 2026 is not the deadline for the whole regulation, but it is the first one that genuinely tests companies. From that day the reporting obligations cover the entire installed base, and the 24-hour deadline does not forgive unresolved responsibilities. Whoever settles availability, the product register and the responsible CSIRT in advance will experience a notification as a process. Whoever starts during an incident spends the deadline getting organised.
The posts in this blog are for orientation and do not constitute legal advice. The wording of Regulation (EU) 2024/2847 prevails.