Deadlines
What the CRA reporting duty requires from 11 September 2026, hour by hour
Published . Reviewed against Regulation (EU) 2024/2847, OJ L, 20.11.2024.
Article 14 of the Cyber Resilience Act applies from 11 September 2026. It is the first part of the Regulation that puts manufacturers on a clock, and it lands fifteen months before the rest of the CRA binds manufacturers.
“This Regulation shall apply from 11 December 2027. However, Article 14 shall apply from 11 September 2026 and Chapter IV (Articles 35 to 51) shall apply from 11 June 2026.” (Art. 71(2), CELEX 32024R2847)
What starts on 11 September 2026
Reporting starts, and only reporting. Technical documentation, the software bill of materials, the declared support period, conformity assessment and CE marking all wait until 11 December 2027.
Article 14 has two tracks. One is triggered by an actively exploited vulnerability in your product, the other by a severe incident affecting the security of your product. Each track has three filings: an early warning, a notification, and a final report.
Who has to report
The heading of Article 14 names one role and no other.
“Reporting obligations of manufacturers” (Art. 14, heading, CELEX 32024R2847)
A manufacturer under the CRA is not a factory.
“a natural or legal person who develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets them under its name or trademark, whether for payment, monetisation or free of charge” (Art. 3, point (13), CELEX 32024R2847)
Importers and distributors do not file under Article 14 in their own right. They can be pulled into it: an importer or distributor that places a product on the market under its own name or trademark, or that carries out a substantial modification of a product already placed on the market, is treated as the manufacturer under Article 21, and inherits Articles 13 and 14 with it.
Track one: an actively exploited vulnerability
An actively exploited vulnerability is defined narrowly.
“a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner” (Art. 3, point (42), CELEX 32024R2847)
The three filings on this track are:
- Early warning, “without undue delay and in any event within 24 hours of the manufacturer becoming aware of it” (Art. 14, early warning).
- Vulnerability notification, “within 72 hours” (Art. 14, notification).
- Final report, “a final report, no later than 14 days after a corrective or mitigating measure is available” (Art. 14(2)(c)).
The last one is the deadline most summaries get wrong. On this track the final report is not tied to a fixed period after the notification. It is tied to the availability of a fix, and it runs for 14 days from that availability.
Track two: a severe incident
An incident is severe when it hits the security properties of the product.
“an incident having an impact on the security of the product with digital elements shall be considered to be severe where: (a) it negatively affects or is capable of negatively affecting the ability of a product with digital elements to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions” (Art. 14(5), CELEX 32024R2847)
The early warning and the notification carry the same 24-hour and 72-hour clocks. The final report does not.
“a final report, within one month after the submission of the incident notification under point (b)” (Art. 14(4)(c), CELEX 32024R2847)
The two tracks side by side
| Filing | Actively exploited vulnerability | Severe incident |
|---|---|---|
| Early warning | Within 24 hours of becoming aware | Within 24 hours of becoming aware |
| Notification | Within 72 hours | Within 72 hours |
| Final report | No later than 14 days after a corrective or mitigating measure is available (Art. 14(2)(c)) | Within one month after the notification was submitted (Art. 14(4)(c)) |
Two tracks, two different final-report rules. A team that builds one template for both will file the wrong one under pressure.
The clock starts at awareness
Not at exploitation, not at disclosure, not when a patch ships.
“without undue delay and in any event within 24 hours of the manufacturer becoming aware of it” (Art. 14, early warning, CELEX 32024R2847)
That single phrase decides most of the operational work. Awareness is an organisational fact, so it is worth writing down who inside the company can become aware on the company's behalf, and through which channels: the security inbox, the support queue, the bug bounty triage, the on-call rotation, a maintainer of a bundled dependency. Whatever route a report can arrive by, someone has to recognise it and start the 24 hours.
Where the reports go
Article 14(1) names both recipients and says they are notified at the same time.
“A manufacturer shall notify any actively exploited vulnerability contained in the product with digital elements that it becomes aware of simultaneously to the CSIRT designated as coordinator, in accordance with paragraph 7 of this Article, and to ENISA.” (Art. 14(1), CELEX 32024R2847)
Article 14(3) sets the same routing for severe incidents. The CSIRT designated as coordinator is the one appointed under Article 12(1) of Directive (EU) 2022/2555, the NIS2 Directive. Both notifications go through the single reporting platform established under Article 16, using “the electronic notification end-point of the CSIRT designated as coordinator of the Member State where the manufacturers have their main establishment” (Art. 14(7), CELEX 32024R2847).
ENISA, on a page last updated 31 August 2026, states that the platform is scheduled to be operational by 11 September 2026 and that a testing period is expected before that date. The European Commission, on a page last updated 31 July 2026, states that the platform will be operational by 11 September 2026 and that functional and security testing are under way. That is what the two of them have said, with the dates on which they said it. We are not going to tell you how the platform will behave on day one.
Products already on the market report too
This is the part that surprises people who have read only the 2027 date. Article 69(2) sets the transitional rule for the rest of the Regulation.
“Products with digital elements that have been placed on the market before 11 December 2027 shall be subject to the requirements set out in this Regulation only if, from that date, those products are subject to a substantial modification.” (Art. 69(2), CELEX 32024R2847)
Article 69(3) then removes Article 14 from that carve-out.
“By way of derogation from paragraph 2 of this Article, the obligations laid down in Article 14 shall apply to all products with digital elements that fall within the scope of this Regulation that have been placed on the market before 11 December 2027.” (Art. 69(3), CELEX 32024R2847)
So the older release you stopped developing in 2024 is out of the essential requirements until it is substantially modified, and inside the reporting duty from 11 September 2026 regardless.
What ready looks like before 11 September
Five things, none of which need a budget line:
- A named reporter and a deputy. One person who files, one who files when the first is unreachable.
- A written awareness trigger. Which inbox, which queue, which alert counts as the company becoming aware, and who watches it out of hours.
- The route, written down. Your CSIRT designated as coordinator, plus ENISA, notified at the same time.
- Two report templates, not one. The vulnerability track and the incident track diverge at the final report.
- A product list. Which of your releases are products with digital elements, including the ones you no longer develop, because Article 69(3) reaches them.
Under Article 64(2), breaches of Articles 13 and 14 sit in the Regulation's highest fine bracket. That is a description of the law's structure, not a prediction about anyone's product.
Orientation, not legal advice. Verify against the official text before relying on any item.