Guide Last updated 8 October 2026 11 min read

Substantial modification: when an update makes a new product

Not every update is just an update. If a new version changes the security or the intended purpose of a product, the Cyber Resilience Act treats it as a new product. This page explains where the line lies, what follows and how to assess and record the decision for each release.

Under Article 3, point (30), of the Cyber Resilience Act, a substantial modification is a change made after placing on the market. There is a substantial modification where the change affects compliance with the security requirements in Annex I, Part I, or modifies the intended purpose of the product. A security update that reduces a risk is not a substantial modification; a feature update that modifies the functions, type or performance of the product usually is (recital 39). The consequence: the modified version is treated as newly placed on the market, and its conformity must be reviewed. Legacy products that are substantially modified after 11 December 2027 thereby become subject to the requirements (Article 69(2)).

Key points

Two questions decide: does the change affect compliance with Annex I, Part I, or does it modify the intended purpose (Article 3, point (30))?
Security fixes that reduce risk and do not change the purpose are not a substantial modification. New features often are, but not automatically: according to the guidance, what counts is whether they introduce new or increased risks not foreseen in the risk assessment, not their size (paragraphs 104 to 107).
The consequence is a new or supplementary conformity assessment, limited to the aspects affected (recital 41).
Anyone who substantially modifies someone else's product becomes a manufacturer (Articles 21 and 22).
Version numbers are irrelevant. What matters is what changes in the product, and that the decision is documented for each release.

What does the Regulation say?

Article 3, point (30), defines substantial modification by two criteria. The first is an effect on compliance with the essential cybersecurity requirements in Annex I, Part I. The second is a modification to the intended purpose for which the product was assessed. Recital 39 translates this for software. A software change is substantial if it modifies the intended purpose and was not foreseen in the initial risk assessment, or if the nature of the hazard has changed or the level of risk has increased, and the updated version is made available on the market.

The same recital also sets the lower limit. A security update that decreases the risk and does not modify the intended purpose is not a substantial modification, even if functions or performance are adjusted for that purpose. Minor functionality updates such as a visual enhancement, new languages or pictograms are generally not substantial either. A feature update that modifies the functions, type or performance of the product and meets the criteria in the recital, on the other hand, is substantial, because new features typically broaden the attack surface; the recital's example is a new input element that requires input validation. Whether the update is provided separately or together with a security update makes no difference.

Which changes are substantial and which are not?

The Commission guidance of 27 July 2026 (Annex to Communication C(2026) 5252, section 4) requires a case-by-case assessment (paragraphs 104 and 110). The yardstick is not the size of the change but whether it introduces new or increased risks not covered by the risk assessment (paragraph 107). The examples from the guidance are marked here with their paragraph or example number. The guidance is not legally binding; it will only be formally adopted once all language versions are available.

Change	Substantial?	Reason and source
Security fix that closes a flaw without changing the purpose	Generally no	Risk goes down, purpose stays the same, even with larger technical changes (recital 39, guidance, paragraph 108)
New languages, pictograms, visual enhancements	Generally no	Minor functionality update (recital 39)
New or newly enabled function that the risk assessment already foresaw and secured	No	Covered by the risk assessment (guidance, paragraph 106, examples 42 and 43)
Replacing a part with an identical spare part	No	Spare parts are excluded under Article 2(6) (guidance, section 4.2)
New input element that requires input validation	Yes	New attack surface (recital 39)
Retrofitting remote connectivity or a cloud interface	Often yes, case by case	A new externally reachable interface is a strong indication; the risk assessment must be reviewed, and the change is substantial if it introduces risks not foreseen there (guidance, paragraphs 109, 110 and 112)
Security update that introduces an external key service from a third party	Yes	New interfaces and dependencies, despite the security purpose (guidance, example 50)
Persistent login with locally stored access tokens	Yes	New risk (guidance, example 44)
A display of operating data becomes a machine control function through an update	Generally yes	The new function changes the intended purpose as a whole (guidance, paragraph 105, example 40)
Local encryption is replaced by a remote service of the manufacturer	Yes	Change of purpose (guidance, example 49)
Convenience feature such as a diagnostic export	Check	Substantial if it exposes sensitive data without protection (guidance, example 45)

In paragraph 110, the guidance lists four questions to consider: Does the update introduce new threat vectors? Does it enable new attack scenarios? Does it change the likelihood of previously identified scenarios? Does it change their potential impact? A yes to any of them means reassessing the risks and determining whether the requirements continue to be met (paragraph 112). If all four answers are no, that indicates there is no substantial modification (paragraph 111).

What follows from a substantial modification?

Review conformity. Recital 41 requires conformity to be verified and, where applicable, a new conformity assessment to be carried out. According to the guidance (paragraph 123), this applies only to the aspects affected; tests and documents for parts that are unaffected do not have to be repeated. If a notified body was involved, it must be informed (Annex VIII, Part II, point (7), addition to the EU-type examination certificate).
New placing on the market. The modified version is treated as newly placed on the market (guidance, paragraphs 116 and 122). This triggers the obligations under Article 13 for that version: technical documentation, EU declaration of conformity, CE marking.
Legacy products are brought into scope. Products placed on the market before 11 December 2027 are only subject to the requirements if they are substantially modified after that date (Article 69(2)). A new function for a machine from 2020 therefore brings that machine under the CRA. According to the guidance (paragraph 124), this applies to the modified part or, if the cybersecurity of the product as a whole is affected, to the entire product. The reporting obligation under Article 14 applies to all products regardless (Article 69(3)).
Reassess the support period. According to the guidance, a substantial modification requires the support period to be reassessed. It does not automatically restart or extend; the period is only recalculated if the factors determining the expected use time change (paragraphs 133 to 135). For software, the guidance requires a separately declared period for each substantially modified version (paragraph 131). Article 13(10) allows vulnerability handling to be limited to the latest substantially modified version if the upgrade is free of charge. Details under Support period.

Whoever modifies becomes the manufacturer: Articles 21 and 22

Substantial modification is not only an issue for the original manufacturer. Under Article 21, an importer or distributor is considered a manufacturer if it substantially modifies a product already placed on the market. Article 22(1) extends this to any other person who substantially modifies a product and makes it available on the market. Under Article 22(2), that person is then subject to the obligations under Articles 13 and 14 for the part affected or, if the cybersecurity of the product as a whole is affected, for the entire product.

This works in both directions. If you extend a bought-in control system with your own software and resell it, you are the manufacturer for that part. If an integrator or customer substantially rebuilds the product and makes it available to others, responsibility for the modification lies with them. More on this under Importers, distributors and authorised representatives.

How do I assess this for each release?

The decision belongs in the release process, not in hindsight. Five steps, repeated for each version:

List the changesWhat is new, changed or removed: functions, interfaces, communication channels, dependencies, execution environments. The SBOM difference from the previous version is part of this.
Compare with the intended purposeAfter the update, can the product do something it was not assessed for? A display becomes a controller, local becomes networked, manual becomes automatic.
Ask the questions from the guidanceNew threat vectors, new attack scenarios, a changed likelihood or impact of known scenarios. The risk assessment under Article 13(3) is updated in the process.
Decide and give reasonsSubstantial or not, with reasons for each change. If substantial: name the aspects affected, plan the conformity assessment for those aspects, inform the notified body, set the support period for the new version.
Record itDecision, reasons, date and responsible person go into the technical documentation. The market surveillance authority can inspect them on reasoned request (Article 13(22)).

The last step is the one most often missing. If you keep a short record of the decision and the reasons for each release, you can later show that you asked the question, even if the authority sees the answer differently. The same record helps when a vulnerability is reported after an update: it shows which version can do what, and since when. When it matters, CRA Response Center keeps the evidence record from the moment a report comes in; the release decision before that remains with the manufacturer.

Common mistakes

Declaring feature releases as "minor". Version numbers are irrelevant. What matters is what changes in the product.
Security fix and new feature in the same package. The security update is not substantial, but the new feature may be; shipping them together does not change that.
Assuming legacy products are safe. The next new feature after 11 December 2027 brings the older product under the CRA.
Not recording the decision. An unreasoned "not substantial" classification is hard to defend before market surveillance authorities.

What remains open?

The line between a change of purpose and a new function within the existing purpose remains a case-by-case matter; harmonised standards could make it more concrete, but as at 7 October 2026 none has been published in the Official Journal. The guidance is not binding; its formal adoption is pending until all language versions are available.

Free templatesCRA Reporting KitReporting playbook, awareness record, notification templates for the ENISA platform, call chain and deadline calculator. Six Word templates, two Excel workbooks and a handbook, free by e-mail.Request the kit

Frequently asked questions

Is a security patch a substantial modification?

No, if it reduces the risk and does not modify the intended purpose (recital 39). That remains true even if functions or performance are adjusted for that purpose.

Is every new feature a substantial modification?

No. Often yes, if it modifies the functions, type or performance of the product and thereby introduces new risks (recital 39); if it changes the intended purpose as a whole, generally yes (guidance, paragraph 105). If the risk assessment already foresaw and secured the feature, it is not a substantial modification (paragraph 106). Minor changes such as new languages or pictograms are excluded.

Do I have to retest everything after a substantial modification?

No. According to the guidance (paragraph 123), only the aspects affected; tests and documents for unaffected parts are not repeated. Article 22(2) states this expressly for third parties.

Does the support period restart?

Not automatically. The period must be reassessed; according to the guidance (paragraph 133), it only restarts or is extended if the factors determining the expected use time change (paragraph 135).

What about products sold before December 2027?

They are only subject to the requirements if they are substantially modified after 11 December 2027 (Article 69(2)). The reporting obligation under Article 14 applies to them nonetheless (Article 69(3)).

My customer rebuilds my product. Am I responsible?

Under Article 22, anyone who substantially modifies a product and makes it available on the market is considered the manufacturer for the modified part. Responsibility for the modification then lies with them, not with the original manufacturer.

Sources

Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 2(6), Article 3, point (30), Article 13(10), Articles 21, 22 and 69, Annex VIII, Part II, point (7), recitals 39, 40 and 41, Publications Office of the EU, 20 November 2024.
Commission guidance on the application of the Cyber Resilience Act, Annex to Communication C(2026) 5252, section 4 (paragraphs 90 to 124), paragraph 131 and section 5.1 (paragraphs 132 to 135), European Commission, 27 July 2026.
EU Cyber Resilience Act: New Guidance Clarifies Scope, Orrick, September 2026.
CRA: Takeaways from the European Commission's Guidelines, SKW Schwarz, 2026.
Cyber Resilience Act guidance: products, obligations, Gamingtechlaw, 5 August 2026.
The new CRA guidance in practice, Schutzwerk, 2026.
CRA Commission guidance, Noze, 28 July 2026.