Independent information resource Product security · EU CRA
CRA reporting / 16

CRA Reporting for Products Placed on the Market Before December 2027

Understand why Article 14 CRA reporting already applies to in-scope products placed on the market before 11 December 2027 and how this differs from the Regulation's wider transitional rules.

IN BRIEF

Manufacturers should not exclude older product lines from CRA vulnerability and incident reporting merely because they were placed on the market before the Regulation's general application date. Article 69(3) specifically brings those in-scope products into Article 14 reporting.

01 / 08

Article 14 Started Before the CRA's General Application Date

The Cyber Resilience Act generally applies from 11 December 2027, but Article 71(2) creates an earlier date for manufacturer reporting obligations. Article 14 applies from 11 September 2026. This means manufacturers already have legally applicable duties concerning actively exploited vulnerabilities and severe incidents even though many of the Regulation's broader product requirements do not become generally applicable until December 2027.

  • General CRA application date: 11 December 2027.
  • Article 14 application date: 11 September 2026.
  • Reporting is therefore already a live compliance obligation.
  • Do not use the general 2027 date as the reporting start date.
02 / 08

Article 69 Contains the Transitional Rule for Older Products

Article 69 addresses products with digital elements placed on the market before 11 December 2027. Paragraph 2 provides the general transitional position: those products are subject to the Regulation's requirements only if, from that date, they are subject to a substantial modification. Read alone, that rule might appear to keep many older products outside later CRA obligations unless they are substantially modified. Paragraph 3 then creates an important express exception for Article 14.

  • Article 69(2) contains the general transition rule.
  • It concerns products placed on the market before 11 December 2027.
  • It links broader CRA requirements to substantial modification from that date.
  • Article 69(3) must be read separately for reporting.
03 / 08

Article 69(3) Expressly Brings Legacy Products Into Article 14

Article 69(3) states, by way of derogation from paragraph 2, that the obligations laid down in Article 14 apply to all products with digital elements within the scope of the Regulation that were placed on the market before 11 December 2027. The reporting exception is therefore deliberate. A manufacturer cannot rely on the product's pre-2027 market-placement date alone to exclude it from actively exploited vulnerability or severe-incident reporting.

  • Article 69(3) is an express exception to Article 69(2).
  • It applies Article 14 to in-scope pre-11 December 2027 products.
  • The product does not need to wait for a substantial modification before Article 14 reporting can apply.
  • Legacy product portfolios should be included in reporting readiness.
04 / 08

Substantial Modification Is Not the Trigger for Article 14 Reporting

The substantial-modification condition in Article 69(2) should not be imported into Article 14 reporting. Paragraph 3 expressly overrides paragraph 2 for Article 14. The relevant reporting questions remain whether the product falls within the CRA's scope and whether the manufacturer becomes aware of an actively exploited vulnerability or severe incident meeting the Article 14 criteria. A manufacturer should not delay reporting while asking whether the older product has undergone a post-2027 substantial modification.

  • Substantial modification is not a prerequisite for Article 14 reporting.
  • Check whether the product falls within CRA scope.
  • Apply the normal Article 14 trigger tests.
  • Apply the normal Article 14 reporting deadlines.
05 / 08

Legacy Products Need to Be Included in Security Monitoring

The practical consequence is that reporting readiness cannot cover only newly launched products. Manufacturers need visibility into relevant older products that remain part of their product-security environment. Vulnerability intake, threat intelligence, customer reports, incident monitoring and PSIRT processes should be able to identify the affected product and determine whether the Article 14 reporting trigger is met. If old product records sit outside the security team's normal inventory, the manufacturer may lose valuable time determining ownership and affected versions after awareness begins the reporting clock.

  • Include relevant legacy products in the PSIRT inventory.
  • Maintain product and version ownership information.
  • Keep vulnerability intake connected to older products.
  • Ensure escalation contacts exist for maintained legacy lines.
06 / 08

The Same Article 14 Reporting Stages Apply

Article 69(3) does not create a lighter reporting timetable for older products. Once an in-scope legacy product gives rise to an Article 14 reporting obligation, the manufacturer applies the same relevant reporting sequence. This can include the 24-hour early warning, the 72-hour notification and the applicable final report. The Article 14(8) user-information obligation also needs to be considered after awareness of an actively exploited vulnerability or severe incident.

  • Use the normal 24-hour early-warning rules.
  • Use the normal 72-hour notification rules.
  • Use the applicable final-report rules.
  • Consider the Article 14(8) user-information duty.
07 / 08

Do Not Confuse Legacy With Out of Scope

Article 69(3) applies to products with digital elements that fall within the scope of the CRA. A product's age does not automatically make it in scope, and the transitional provision does not expand the substantive scope of the Regulation. Manufacturers should therefore preserve the normal scope analysis. The correct sequence is to determine whether the product falls within the CRA and then apply Article 69 and Article 14 as appropriate.

  • First determine whether the product is within CRA scope.
  • Do not assume every historical product is covered.
  • Do not assume every historical product is excluded.
  • Document the scope and transitional analysis.
08 / 08

Create a Legacy-Product Reporting Register

A practical register can identify legacy product families, versions, EU market history, product owner, security owner, support status, current user communication route and vulnerability-monitoring source. The objective is not to recreate every historical commercial record. It is to ensure that the manufacturer can identify an in-scope pre-2027 product quickly enough to make the Article 14 determination and meet the live reporting deadlines. The register should be reviewed when product ownership, support arrangements or vulnerability-handling responsibilities change.

  • List relevant legacy product families.
  • Identify security and product owners.
  • Record supported or deployed versions where available.
  • Record user-communication routes.
  • Connect legacy products to the Article 14 escalation process.
REFERENCE DESK

Official sources

Read the full legal text and Commission material for precise wording, qualifications and updates.

Editorial review: 26 September 2026. Regulatory material can change; follow the official sources for current guidance.