CRA timeline and reporting obligations — September 2026, December 2027, and the 24-hour rule

CRA was published on 20 November 2024 and entered into force on 10 December 2024. Notified-body chapter provisions apply from 11 June 2026; manufacturer reporting from 11 September 2026; main product duties from 11 December 2027. Open-source software stewards have a separate Article 24(3) reporting date.

Two reporting paths and final triggers

Manufacturers report actively exploited vulnerabilities and severe security incidents through the Single Reporting Platform. Both have 24-hour early warnings and 72-hour notifications from awareness. Article 14(2)(c): vulnerability final report within 14 days after a corrective or mitigating measure becomes available. Article 14(4)(c): severe-incident final report within one month after the 72-hour notification. Severity criteria are Article 14(5), not Annex VI. Do not invent a fixed monthly progress-report duty. Manufacturer reporting applies from 11 September 2026. The ENISA platform is operational.

Existing products and modifications

Distinguish products first placed before 11 December 2027, later substantial modifications, and Article 14 reporting. Article 69(2)/(3) does not automatically apply every Annex I and Article 13 duty to every legacy unit. Article 14 expressly also applies to relevant legacy products. Assess the particular product/version and placing date.

Penalty categories

Article 64(2) covers specified Annex I and Articles 13/14 non-compliance, with a maximum of EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher. Other categories have different limits. Article 64(10)(a) contains a micro/small enterprise exception concerning failure to meet the early-warning deadline, not exemption from reporting duties. Maximum penalties are not automatic fines or proof of personal liability for every signer.

Evidence to keep with the product

Record the intended purpose, responsible economic operator, target market, first placing date and exact hardware/firmware configuration. For each applicable requirement, link the actual test or assessment record, dated standard/specification, scope and reviewer decision. Proposed controls and supplier marketing statements are not evidence that the final configuration has passed an assessment.

Separate an open question from a completed assessment. A report outside the laboratory's relevant scope, a different firmware build or an unverified exemption needs a reasoned decision before it supports a declaration. Keep original evidence and the issued declaration alongside any AI-assisted working draft.

Using Cenitia for this work

Cenitia assists with a limited regulatory catalogue and draft documents. The manufacturer must confirm applicability, actual applied specifications and completed assessment procedures. AI scores are quality signals, not a probability of conformity. Source monitoring raises a review prompt when validated source text changes; it does not automatically verify amendments, update the corpus or monitor every national rule and OJ standard edition. Public QR verification records issuance, not product certification.

Review status

This guide was substantively corrected by Cenitia on 2 October 2026 using the primary references below. It is an editorial summary, not an authoritative legal quotation or an independently signed expert opinion. Product-specific and licensed-standard questions remain subject to a real technical review.

Primary references

• Primary source 1