Cyber Resilience Act FAQ Substantial Modification

A CRA substantial modification is a change made after a product with digital elements has been placed on the market that affects the product's compliance with Annex I Part I essential cybersecurity requirements or changes the intended purpose for which the product was assessed.

The test is about the change's cybersecurity and intended-purpose effect. A release note label such as patch, upgrade, repair, maintenance, hotfix, or feature update does not decide the answer by itself.

No. Software development is iterative, and the CRA guidance expects a case-by-case assessment.

A later software iteration is not substantial merely because the code changed. The key question is whether the update introduces new or increased cybersecurity risks that were not already covered in the original risk assessment, affects compliance with the essential requirements, or changes the product's assessed intended purpose.

Usually no. A security update whose purpose is to reduce cybersecurity risk, and that does not change the product's intended purpose or introduce new cybersecurity risks, should generally not be treated as a substantial modification.

That remains true even if the update changes internal implementation or constrains an existing feature solely to mitigate a vulnerability.

Yes. A security-driven change can still be substantial if it moves the product beyond the intended purpose originally assessed or introduces new risks that were not foreseen in the original cybersecurity risk assessment.

Examples from the draft guidance include security updates that move local processing to a remote service, change the trust model, add new external dependencies, or materially change data flows.

Start with the original intended purpose, architecture, threat model, risk assessment, technical documentation, and release scope. Then check whether the update changes the cybersecurity risk profile in a way the original assessment did not cover.

New functionality is more likely to be substantial when it changes the product's intended purpose as a whole or introduces cybersecurity risks that were not considered and mitigated in the original risk assessment.

A large feature is not required. A small-looking addition can be substantial if it changes the attack surface or risk profile in a way that affects compliance with the essential requirements.

Yes, if the later functionality and its risks were already included in the original intended purpose, cybersecurity risk assessment, mitigations, and technical documentation.

The practical evidence should show that the update implements a foreseen design path rather than expanding the product into a new intended use or unassessed risk profile.

No. Repairs, maintenance, and refurbishment do not necessarily lead to a substantial modification when the product's intended purpose, functionality, and cybersecurity risk level remain unaffected.

The repair becomes more sensitive when it changes how core functions operate, changes intended purpose, or affects compliance with Annex I Part I requirements.

No. Replacing a defective or worn item with a better-performing part does not itself trigger substantial modification.

It becomes substantial only if the performance change or changed operation affects compliance with essential cybersecurity requirements or changes the intended purpose that was covered by the original risk assessment.

A non-identical spare part may itself be a CRA product because it does not fall within the identical-spare-parts exemption. That does not automatically mean the host product has been substantially modified.

For the host product, assess whether the replacement changes intended purpose, functions, interoperability assumptions, cybersecurity risk profile, or compliance with Annex I Part I. For the spare part itself, assess CRA compliance in light of its own intended purpose and any compatibility or interoperability constraints.

When a product is substantially modified and the modified product is made available on the market, the modified product is treated as a new CRA product event. The person carrying out the substantial modification, or having it carried out, is treated as the manufacturer for the modified product.

If the original manufacturer makes the substantial modification, it remains the manufacturer. If another party makes the substantial modification and makes the modified product available on the market, that party can become responsible for the relevant CRA manufacturer obligations.

No. The CRA separates the provisions.

Article 21 covers importers and distributors that carry out a substantial modification of a product already placed on the market. Article 22 covers other natural or legal persons where they carry out a substantial modification and make the modified product available on the market.

Article 22 narrows the obligation to the part affected by the substantial modification, unless the modification affects the cybersecurity of the product as a whole.

In practice, the evidence should explain the affected boundary. If the changed part alters shared authentication, update mechanisms, communications, data flows, remote processing, or other whole-product security assumptions, teams should expect the whole-product assessment to be relevant.

Where a substantial modification may affect CRA compliance or changes intended purpose, compliance should be verified again and, where applicable, the product should undergo a new conformity assessment.

If a third-party conformity assessment was used, a change that might lead to a substantial modification should be notified to the third party where applicable.

No. Existing tests and documentation can be reused for parts of the product that are not affected by the substantial modification.

The person placing the modified product on the market must still update the technical documentation for impacted requirements, demonstrate why unchanged parts do not need new evidence, take responsibility for the modified product's conformity, and draw the required declaration of conformity.

Keep enough evidence to show the change was assessed against the CRA test rather than only approved as an engineering release.

A useful file links the release scope to the original intended purpose, risk assessment, threat model, affected architecture, Annex I Part I controls, vulnerability-handling impact, user instructions, test results, conformity route, declaration status, and any third-party assessment notification.

Users should receive practical information tied to the actual change: what changed, whether action is needed, any configuration or security-update steps, changed support information, and any known constraints introduced by replacement parts or interoperability measures.

For security updates, the CRA separately requires security updates to be disseminated without delay and accompanied by advisory messages with relevant information, including potential user action. Where technically feasible, new security updates should be provided separately from functionality updates.

Products with digital elements placed on the market before 11 December 2027 are subject to CRA requirements only if, from that date, they are subject to a substantial modification.

The Commission FAQ gives a practical contrast: a non-substantial bug-fix update for a smart TV placed on the market in 2027 does not require bringing that TV into full CRA conformity, but a later update that adds smart-home-control functionality and qualifies as substantial does.

Yes. For products placed on the market before 11 December 2027 where the CRA was not applied at initial placement, the draft guidance says manufacturers must be able to demonstrate to a market surveillance authority that later updates do not constitute substantial modifications.

A cybersecurity risk assessment covering Article 13(2) elements, plus documented compliance reasoning, should make that position easier to support.

The manufacturer must comply with the CRA in its entirety before placing the substantially modified product on the market, and then for the duration of that product's support period.

Teams should treat this as a release gate: confirm product scope, update the risk assessment and technical documentation, choose or confirm the conformity assessment route, prepare conformity evidence, update user information, and confirm vulnerability-handling processes before the modified product is made available.