Read Article 71(2), then 69(2), then 69(3)
Article 71(2) says the regulation applies from 11 December 2027, except that Article 14 applies from 11 September 2026 (and Chapter IV from 11 June 2026). Article 69(2) is the grandfathering clause people remember: products placed on the market before 11 December 2027 are subject to the CRA's requirements only if, from that date, they undergo a substantial modification. Article 69(3) is the sentence that undoes the comfortable reading: by way of derogation from paragraph 2, 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. There is no age cut-off in that derogation.
What legacy products still do not owe (yet)
For a product placed before 11 December 2027 and not substantially modified after that date, you typically do not yet owe the full Annex I essential cybersecurity requirements, CRA conformity assessment, technical documentation package, EU declaration of conformity, or CE marking under the CRA. That is the Article 69(2) relief. It is not a pass on telling CSIRTs and ENISA when you become aware of an actively exploited vulnerability or a severe incident affecting product security. Treat reporting readiness as a separate workstream from the 2027 conformity programme.
Commission FAQ 5.3: notify even when you cannot fully investigate
The Commission's CRA implementation FAQ (entry 5.3) confirms reporting for products placed before 11 December 2027 from 11 September 2026. It also addresses the practical panic about decade-old code: manufacturers may be unable to investigate because tooling to scan or run old versions no longer exists, build environments cannot be recreated, dependencies are unavailable or incompatible, or staff who knew the codebase have left. For such products, you must still notify the vulnerability or incident; the CRA does not require you to meet other obligations such as vulnerability handling for that case. You still owe users Article 14(8) information where applicable — and if you do not inform them in a timely manner, notified CSIRTs may do so where proportionate and necessary. Declared end-of-support is a separate trap: it does not cancel Article 14 either — see Article 14 after the support period ends.
The trigger is awareness, not ship date
ENISA's SRP FAQ points back to the same Commission material: the duty starts when the manufacturer becomes aware after the reporting rules apply. There is no requirement to clear a retrospective backlog of exploitation you already knew about before 11 September 2026. If you become aware of active exploitation on or after that date, Article 14 runs — including where the underlying flaw or the product itself is old. Details: when the 24-hour clock starts.
Same Article 14 clocks once awareness hits
Early warning within 24 hours, fuller notification within 72 hours, then the final report (14 days after a corrective or mitigating measure is available for an exploited vulnerability; within one month after the 72-hour notification for a severe incident). Overview: reporting deadlines explained. Official submission still goes through the ENISA Single Reporting Platform. Non-EU makers and white-label brands use the same clocks — see non-EU manufacturers and white-label / OEM-ODM.
Questions people ask
- Our connected product shipped years ago. Do we still have to file Article 14?
- Yes, if it is in scope and still on the Union market in users' hands. Article 69(2) generally grandfathers products placed before 11 December 2027 until a substantial modification — but Article 69(3) derogates for Article 14. Reporting applies to those legacy products from 11 September 2026.
- Does grandfathering under Article 69(2) cancel the 24-hour early warning?
- No. Article 69(2) delays many CRA product requirements until substantial modification after 11 December 2027. Article 69(3) says that, by way of derogation, the obligations in Article 14 still apply to all in-scope products placed before that date. The clocks are live now.
- We discontinued the line and cannot rebuild the old toolchain. What do we still owe?
- Commission FAQ 5.3 says you must still notify the actively exploited vulnerability or severe incident. If you genuinely cannot investigate (old tooling gone, build environment impossible to recreate, dependencies unavailable, staff who knew the code left), the CRA does not require you to meet other obligations such as vulnerability handling for that legacy product — but you still file what you know and Article 14(8) still expects you to inform impacted users.
- Do we need to clear a backlog of every exploit we knew about before 11 September 2026?
- No. Awareness after the reporting rules apply starts the clock. The Commission and ENISA say you are not required to retrospectively report active exploitation you already knew about before 11 September 2026. Fresh awareness on or after that date does start Article 14 — even for an old product or a long-known vulnerability.
- Are unsupported or end-of-life products out of Article 14?
- Article 69(3) draws no cut-off for age or support period. If the product falls within the CRA's scope and was placed on the Union market, Article 14 can still apply when you become aware of active exploitation or a severe incident. Map discontinued SKUs the same way you map live ones for who files and which CSIRT end-point you use. Full walkthrough: Article 14 after the support period ends.
- What should we do operationally for a legacy catalogue?
- List every in-scope product still in the field, including discontinued lines. Decide the manufacturer entity and CSIRT route, how awareness is timestamped, and who can submit on the ENISA Single Reporting Platform. Then practice the 24h / 72h / final-report chain on the free desk or deadline calculator — filing still goes through ENISA.