Does the CRA Apply to Products Already on the EU Market?

Article 69 Provides the Starting Rule for Existing Products

Article 69 contains the CRA's transitional provisions. For products with digital elements placed on the market before 11 December 2027, the general rule is that the Regulation's requirements apply to those products only if, from that date, they are subject to a substantial modification. This prevents the main 2027 application date from operating as a blanket requirement to redesign every historical product that was already placed on the market. The rule is product and version specific, so portfolio analysis needs reliable records of when a product was placed on the market and what happens to it afterwards. A company should not describe the transition simply as a permanent exemption for old products because subsequent modifications can change the analysis, and Article 14 has its own explicit exception.

• Identify products placed on the market before 11 December 2027.
• Maintain product and version history.
• Track modifications after the application date.
• Keep Article 14 reporting separate from the general transition.

Article 14 Reporting Is the Important Exception

Article 69 expressly states that Article 14 applies to all products with digital elements within CRA scope that were placed on the market before 11 December 2027. A manufacturer therefore cannot rely on the legacy-product transition to avoid the applicable reporting duties for an actively exploited vulnerability or severe incident affecting product security. This is already operational because Article 14 began applying in September 2026. The distinction is important for companies with long-lived products. A legacy product can fall outside the main post-2027 product requirements under the transitional rule while still creating a current Article 14 reporting obligation when the statutory trigger is met. Product-security teams should therefore keep legacy products in the reporting inventory even where the broader CRA transition applies.

A Substantial Modification Can Bring the Product Into the Main CRA Regime

The concept of substantial modification is central to the transition. The CRA explains that a software change can be substantial where an update modifies the product's intended purpose in a way not foreseen in the original risk assessment, or where the nature of the hazard changes or the cybersecurity risk increases and the updated product is made available on the market. A substantial modification can therefore require a fresh compliance analysis rather than being treated as routine maintenance. Articles 21 and 22 also address situations in which importers, distributors or other persons can acquire manufacturer responsibilities when they substantially modify a product. Organisations maintaining products through 2027 and beyond should classify major changes before release instead of deciding retrospectively after the updated version reaches users.

• Review changes to intended purpose.
• Assess whether the nature of cybersecurity hazards changes.
• Assess whether the cybersecurity risk increases.
• Determine who performs the modification and what legal role follows.

A Normal Security Update Is Not Automatically a Substantial Modification

The CRA's recitals distinguish substantial modifications from ordinary security maintenance. A security update designed to reduce cybersecurity risk without modifying the product's intended purpose is not, by that fact alone, a substantial modification. This is important because a rule that treated every vulnerability fix as a new product-compliance trigger could discourage the very security maintenance the CRA is intended to promote. A patch for a known vulnerability, including a limited functional adjustment made solely to reduce the cybersecurity risk, can therefore fall outside the substantial-modification concept. The assessment should still be documented where the change is significant enough to raise a question. Labels such as patch, hotfix or security release do not decide the legal outcome on their own.

• A security fix is not automatically a substantial modification.
• The intended purpose remains important.
• Risk reduction differs from a change that creates new or increased cybersecurity risk.
• Document borderline decisions.

Feature Updates Need a More Careful Assessment

Feature updates can present a different situation. The CRA recitals explain that a feature update that changes original intended functions or product performance and meets the substantial-modification criteria can trigger the concept because new functionality can expand the attack surface. A software product that receives major inputs, integrations, network capabilities, privilege changes or a materially different use case may therefore require more scrutiny than a minor user-interface enhancement. The analysis should focus on what the update actually changes, not the release label selected by the product team. Combining a feature update with a security update does not prevent the feature change from being assessed. Change-control procedures should therefore include a CRA review point for material product changes after the main application date.

• Review new functions and interfaces.
• Consider attack-surface changes.
• Assess changes to product purpose and performance.
• Do not use release naming as the legal test.

Repair and Maintenance Do Not Automatically Trigger the CRA

Repair, maintenance and refurbishment do not necessarily amount to a substantial modification. The CRA distinguishes these activities from changes that alter intended purpose, functionality or the level of cybersecurity risk. A routine repair or maintenance operation that restores expected functionality without materially changing the product can therefore produce a different result from a redesign or capability expansion. Hardware manufacturers should apply the same disciplined change analysis that software manufacturers use for updates. The relevant question is not simply whether something in the product changed, but whether the change meets the CRA criteria for a substantial modification. Maintaining records of the original product baseline and the purpose of later changes makes that assessment much easier to support.

• Separate maintenance from product redesign.
• Retain a clear product baseline.
• Assess functionality and cybersecurity risk after material changes.
• Escalate uncertain modifications before market release.

Existing Certificates Have Their Own Transitional Rule

Article 69 also addresses certain EU type-examination certificates and approval decisions issued for cybersecurity requirements under other Union harmonisation legislation. The Regulation provides a transitional validity rule extending specified certificates or decisions until 11 June 2028 unless they expire earlier or another applicable Union law provides otherwise. This provision is separate from the general legacy-product rule in Article 69(2). Manufacturers should therefore avoid combining all transitional questions into one grandfathering analysis. Product market-placement history, substantial modification, Article 14 reporting and pre-existing conformity certificates each have their own legal function. Where multiple Union product regimes apply, the transition should be mapped with the relevant sector-specific requirements as well.

• Do not treat all Article 69 paragraphs as the same transition.
• Check certificate expiry dates.
• Check other applicable Union harmonisation legislation.
• Maintain product-specific transition records.

How to Build a Legacy-Product CRA Inventory

A practical transition inventory should identify the product, relevant version, initial market-placement status, manufacturer, support status, planned updates and whether significant feature development will continue after December 2027. Each product record should also state that Article 14 reporting remains relevant where the product is within CRA scope. Products scheduled for major post-2027 development deserve early substantial-modification analysis because the conclusion can change the required engineering and conformity work. Products receiving only maintenance still need enough documentation to support that conclusion. This approach is more reliable than a single spreadsheet column labelled old product or grandfathered because the CRA transition depends on future product changes as well as historical placement on the market.

• Record the product and version.
• Record pre-2027 market-placement status.
• Record planned feature and security updates.
• Flag potential substantial modifications.
• Keep Article 14 reporting active for covered legacy products.
• Document the legal reasoning used for transition decisions.