EU Cyber Resilience Act FAQ Repairs and Spare Parts

No. The CRA definition of substantial modification focuses on changes made after placing on the market that affect compliance with the essential cybersecurity requirements or change the intended purpose for which the product was assessed.

Recital 42 says refurbishment, maintenance, and repair do not necessarily lead to substantial modification, for example where intended purpose, functionality, and risk level remain unaffected. A manufacturer-led upgrade can be different if it changes the product's design, development, intended purpose, or CRA compliance position.

Assess the repair case by case against the product's original CRA assessment. A physical repair is not substantial merely because hardware was opened, a component was replaced, or an old part was exchanged for a newer one.

The practical test is whether the repair changes the intended purpose, changes essential functionality, increases cybersecurity risk, or affects compliance with Annex I Part I in a way not covered by the existing cybersecurity risk assessment.

Yes, but the exclusion is narrow. Article 2(6) excludes spare parts made available on the market to replace identical components in products with digital elements, when those spare parts are manufactured according to the same specifications as the components they replace.

That means the part has to be an identical-specification replacement. It is not enough that the part is generally compatible or performs the same business function.

Yes. Recital 29 says the spare-part exemption is intended to cover spare parts used to repair legacy products made available before the CRA's date of application, as well as spare parts for products that have already undergone CRA conformity assessment.

For legacy products, the exclusion answers whether the identical spare part itself is outside the CRA. It does not remove the separate need to check whether the repair activity substantially modifies the product.

Then Article 2(6) does not settle the matter. The non-identical spare part may need to be assessed as a product with digital elements in its own right if it is made available on the market and otherwise falls within CRA scope.

The replacement part's CRA assessment should reflect its own intended purpose, including compatibility or interoperability with the existing product. Compatibility constraints can be relevant, but they should be documented rather than used as an unsupported exemption.

No. The fact that the spare part is not covered by Article 2(6) does not automatically mean the repaired product has been substantially modified.

The repaired product still has to be assessed against the substantial-modification test: whether the change affects compliance with the essential cybersecurity requirements, changes intended purpose, or changes the cybersecurity risk profile of the product.

No. The Article 2(6) exclusion requires an identical component manufactured according to the same specifications. A replacement can keep the same function, protocols, or security mechanisms and still fall outside the exclusion if its specifications differ.

That distinction matters for repair planning: same operational role may help the substantial-modification analysis, but it does not by itself make the part an identical spare part under Article 2(6).

The manufacturer should treat the compatibility limit as a cybersecurity risk-assessment issue, not as a reason to ignore the CRA. Where a requirement is not applicable or cannot be met in the usual way because of product nature, interoperability, or compatibility, the risk assessment and technical documentation should explain why.

The manufacturer should then use appropriate alternative or compensatory measures, describe the remaining constraints and risks in the technical documentation and user information, and reassess whether those constraints can be reduced during the support period.

Yes, often. Recital 39 says a security update designed to decrease cybersecurity risk is not considered a substantial modification when it does not modify the product's intended purpose.

The Commission FAQ gives a legacy smart-TV example: a post-2027 bug-fix update that does not qualify as a substantial modification does not require bringing that pre-application product into full CRA conformity.

A software update can become substantial when it changes the product's intended purpose or changes the type or performance of the product in a way that affects cybersecurity risk. The label attached to the release is not decisive.

Feature updates deserve particular attention when they add new interfaces, new inputs, new dependencies, new data flows, or new operating modes that were not covered by the original cybersecurity risk assessment.

For products with digital elements placed on the market before 11 December 2027, Article 69(2) says the CRA requirements apply only if, from that date, those products are subject to a substantial modification.

There is an important exception: Article 69(3) applies Article 14 reporting obligations to all in-scope products placed on the market before 11 December 2027. The Commission FAQ states that reporting obligations start applying from 11 September 2026.

No, not merely because they continue making those individual products available after that date. The Commission FAQ says products already placed on the market before 11 December 2027 are not subject to CRA requirements, except reporting obligations, unless they are substantially modified.

A distributor's position changes if the distributor carries out a substantial modification or places the product on the market under its own name or trademark. In those cases, Article 21 can make the distributor responsible as a manufacturer for CRA purposes.

The changed product is treated as a new product for the CRA analysis when it is made available on the market after the substantial modification. Compliance must be reassessed for the affected part, or for the whole product if the modification affects cybersecurity of the product as a whole.

If an importer or distributor carries out the substantial modification, Article 21 treats it as a manufacturer. If another person carries out the substantial modification and makes the product available on the market, Article 22 treats that person as a manufacturer for CRA purposes.

Not necessarily. The assessment should focus on the parts, risks, and requirements affected by the substantial modification.

Existing documentation, test evidence, and conformity work may still be relevant for unchanged aspects, but the modified product must have enough current technical documentation and assessment evidence to demonstrate CRA conformity for the affected scope.

No. The Blue Guide says repaired products that are not considered new products do not need conformity assessment again, including where the product was temporarily exported to a third country for repair.

For CRA purposes, the relevant question remains whether the repair is a substantial modification because it changes intended purpose, compliance with essential cybersecurity requirements, or the cybersecurity risk profile.

Repair planning should not be separated from the support-period duties. Manufacturers must determine a support period that reflects expected use, and vulnerability handling and security updates must continue during that period according to the CRA requirements.

Where legacy compatibility limits the best available security design, the manufacturer should document the constraint, explain residual risks to users where required, and reassess whether security can be improved during the support period instead of treating the constraint as permanent without review.

Keep enough evidence to show which question was answered: spare-part exclusion, repair substantial-modification analysis, or both. Useful records include the replaced component's specifications, the replacement part's specifications, the intended purpose before and after repair, affected interfaces and data flows, cybersecurity risk-assessment updates, and any compensatory controls.

For non-identical parts or compatibility-limited designs, the file should also record why identical replacement was not used, what risks remain, what user information was updated, and who made the product available on the market after the change.