Yes. From 11 September 2026, manufacturers must apply Article 14 of the Cyber Resilience Act to in-scope products already placed on the EU market, including those sold before 11 December 2027. Article 69(3) expressly preserves that reporting duty. The product’s age does not remove it from the reporting assessment; an actual reporting obligation still depends on the event and when the manufacturer became aware.
CRA Article 69(2)–(3) — transitional provisions·CRA Article 71(2) — application dates
The reporting exception in Article 69(3)
Article 69(2) gives products placed on the market before 11 December 2027 a transition rule for the broader CRA requirements: those requirements apply if the products undergo a substantial modification from that date. Paragraph 3 then makes an express exception for Article 14. Reporting applies to older products that fall within the Regulation’s scope.
That is why a team cannot close a reporting review with “we sold this before 2027.” The reporting exception does not require a substantial modification first. It also does not bring a product excluded from CRA scope into the Regulation.
For this question, “sold” is shorthand. The legal test is placing the product on the Union market: its first making available there. A design date, internal release date or product-family launch date cannot establish that fact on its own.
Sources: CRA Article 69(2)–(3) — transitional provisions·CRA Articles 2 and 3 — scope and market definitions
Product age and awareness are separate facts
The date an older product entered the market answers a transition question. The manufacturer’s awareness of an actively exploited vulnerability or severe incident starts the reporting review. Keep those dates in separate fields.
ENISA’s FAQ makes the distinction explicit for actively exploited vulnerabilities. Question 12 confirms coverage of older products. Question 13 explains that manufacturers need not retrospectively report active exploitation they were already aware of before 11 September 2026. Earlier exploitation discovered after that date is a different situation.
| Recorded facts | Effect on the reporting decision |
|---|---|
| The manufacturer first becomes aware of active exploitation on 13 September 2026. | Assess Article 14 reporting. The 2025 placement date does not exempt the product. |
| The manufacturer was already aware of that active exploitation on 10 September 2026. | ENISA says no retrospective report is required solely because the reporting rules start on 11 September. |
Sources: ENISA SRP FAQ, questions 12–13 — older products and earlier awareness·CRA Article 14 — manufacturer reporting
A worked example for an older connected product
Consider a hypothetical network sensor placed on the EU market in 2025. At 09:00 UTC on 13 September 2026, its manufacturer first receives reliable evidence establishing active exploitation of a vulnerability in the product. Assume the product is in CRA scope and the evidence satisfies the reporting threshold.
Using those assumptions in our public reporting example, the published assessment returns “notification sequence in progress” while the first notifications are being prepared. The assessment structures the reporting sequence; the older product’s inclusion follows from Article 69(3).
The calculator gives outer targets of 09:00 UTC on 14 September for the early warning and 09:00 UTC on 16 September for the vulnerability notification. Article 14 also requires action without undue delay. If no corrective or mitigating measure is available, the vulnerability final-report trigger remains unrecorded; its 14-day period is tied to availability of that measure.
This is a hypothetical worked path, not a customer incident. The public example exposes the recorded assumptions and schema version so you can inspect what produced the result.
Sources: CRA Article 14 — manufacturer reporting·European Commission — CRA reporting obligations
Inspect the active-exploitation facts and worked assessment result
Calculate the reporting targets from your awareness timestamp
Keep the decision with the older product’s evidence
Keep the product and affected versions, the EU market-placement evidence, the exploitation evidence and the first-awareness timestamp together. Name the person responsible for the reporting decision and retain the actual submission receipts. An inventory label such as “legacy” cannot substitute for that record.
CRA Operations links the assessment result and its retained ProseID Record to the product’s vulnerability case. Mandatory notifications are submitted through ENISA’s Single Reporting Platform; CRA Operations does not file them for you. For a severe security incident, use the separate incident assessment and its reporting sequence.
Sources: ENISA — Single Reporting Platform
Review the broader CRA vulnerability reporting decision process
Record the reporting decision for the older product
Open the affected product’s vulnerability case and run the actively exploited vulnerability assessment. Keep the awareness evidence and reporting status with the result.
Start the reporting assessmentThis article explains an operational approach to CRA preparation. It does not replace the Regulation, official guidance or advice for a specific product and organisation.
Not lawyer-reviewed.