Substantial modification under the CRA

This definition does more work than any other in the Cyber Resilience Act. It decides when you have to reassess a product you already sold, when somebody else becomes its manufacturer instead of you, and whether your existing catalogue is in scope at all.

The definition, and its two limbs

Article 3 defines it as follows:

‘substantial modification’ means a change to the product with digital elements following its placing on the market, which affects the compliance of the product with digital elements with the essential cybersecurity requirements set out in Part I of Annex I or which results in a modification to the intended purpose for which the product with digital elements has been assessed

Three observations, each of which narrows or widens it in a way people get wrong.

• The limbs are alternatives. “or”, not “and”. A change that leaves Annex I compliance untouched but changes the intended purpose is a substantial modification, and so is the reverse.
• It is Part I only. The first limb refers to the essential cybersecurity requirements in Part I of Annex I — the thirteen product properties. Changes to your Part II vulnerability-handling processes are not within the first limb, because Part II is about how you work rather than what the product is.
• “Affects” is not “breaks”. The wording is that the change affects compliance, not that the product becomes non-compliant. A change that alters how a Part I requirement is met — a new authentication mechanism, a different encryption approach — affects compliance even if the product still complies.

The recitals add the test that makes this operable. Recital 38 puts it this way: where products are subsequently modified, by physical or digital means, in a way that is not foreseen by the manufacturer in the initial risk assessment and that may imply that they no longer meet the relevant essential cybersecurity requirements, the modification should be considered substantial.

That phrase — not foreseen in the initial risk assessment — is the practical hinge, and it has a consequence worth acting on: the scope of your risk assessment determines how often you will have to redo it. An assessment that anticipates the product's planned evolution absorbs changes that a narrow one would treat as substantial. That is not gaming the rule; it is the rule working as designed, and it is a reason to write the assessment with the roadmap in front of you.

Why security updates do not count

This is the question everyone asks first, and the regulation answers it directly. Recital 39:

Where a security update which is designed to decrease the level of cybersecurity risk of a product with digital elements does not modify the intended purpose of a product with digital elements, it is not considered to be a substantial modification.

Note the two conditions built into that sentence. The update must be designed to decrease the level of cybersecurity risk, and it must not modify the intended purpose. A patch that also quietly adds a feature has failed the second condition.

The outcome is the only coherent one. Annex I Part II point 2 obliges you to remediate vulnerabilities without delay, and point 8 obliges you to ship the fix free of charge. A regime in which every patch triggered a fresh conformity assessment would make those duties impossible to discharge. This is also, incidentally, a good argument for Part II point 2's preference that security updates be shipped separately from functionality updates where technically feasible: separation keeps your patches cleanly inside Recital 39.

Why feature updates often do

The recitals reason that a software change adding new functionality typically broadens the attack surface, and thereby increases cybersecurity risk. That is exactly the kind of change the first limb of the definition is aimed at — and Annex I Part I (j) requires the product to be designed, developed and produced to limit attack surfaces, so a change that widens it engages a named requirement.

It is not automatic. The test remains whether Annex I Part I compliance is affected or the intended purpose changes. A cosmetic redesign of a settings screen probably does neither; adding a remote-access capability, a new network-facing API or a cloud sync feature probably does both.

Repair, maintenance and refurbishment

The recitals indicate that repair, maintenance and refurbishment operations do not necessarily lead to a substantial modification, provided the intended purpose and the functionalities remain unchanged. That is the sensible outcome for the repair and circular-economy rules the EU has been building elsewhere, and it lines up with Article 2(6), which takes identical-specification spare parts out of scope entirely.

The qualifier does real work, though. A refurbishment that upgrades firmware to a newer major version, or that adds connectivity a product did not previously have, is not leaving functionality unchanged.

The provision that decides your existing fleet

Article 69(2):

Products with digital elements that have been placed on the market before 11 December 2027 shall be subject to the requirements set out in this Regulation only if, from that date, those products are subject to a substantial modification.

So for everything you have already sold, this definition is the whole of the question. Products that stay as they are stay outside Annex I; products you substantially modify after 11 December 2027 come in, and have to be assessed and documented as though new.

Three consequences that are worth planning around now rather than in 2028:

• Your continuing security updates do not bring old products in. Recital 39 means you can keep patching a 2024 product indefinitely without triggering Annex I.
• Your next major release of an old product probably does. Which makes the roadmap decision a compliance decision. A product you were going to modernise in 2028 is a product you were going to bring into CRA scope in 2028, whether or not anybody framed it that way.
• Article 69(3) overrides all of this for reporting. By way of derogation from Article 69(2), the Article 14 obligations apply to all in-scope products placed on the market before 11 December 2027 — and Article 14 has applied since 11 September 2026. Your existing fleet is outside Annex I and inside the reporting regime, today.

How a modifier becomes a manufacturer

Article 22 is two paragraphs and it reallocates responsibility wholesale:

A natural or legal person, other than the manufacturer, the importer or the distributor, that carries out a substantial modification of a product with digital elements and makes that product available on the market, shall be considered to be a manufacturer for the purposes of this Regulation.

And the scope of what they take on:

The person referred to in paragraph 1 of this Article shall be subject to the obligations set out in Articles 13 and 14 for the part of the product with digital elements that is affected by the substantial modification or, if the substantial modification has an impact on the cybersecurity of the product with digital elements as a whole, for the entire product.

The second paragraph is the one to read twice. The default is that you take on Articles 13 and 14 for the part you modified. But if your modification affects the cybersecurity of the product as a whole, you take on the whole product — somebody else's engineering, somebody else's components, all of it.

This catches more businesses than it appears to. Systems integrators, value-added resellers, white-label rebranders and OEM customers who ship modified firmware are all potentially inside Article 22. Note that it applies to a person other than the manufacturer, importer or distributor — those three have their own routes into manufacturer obligations, covered in importers, distributors and rebranders.

What follows from a substantial modification

The Regulation does not gather the consequences in one place, so here they are together.

That last row is the one that quietly breaks filing systems, and it is the reason retention is a versioning problem rather than a storage problem. A substantial modification does not replace your documentation. It adds a version alongside it, and both have to survive.

Deciding it in practice

Nobody from an authority is going to tell you whether a given release was substantial. You decide, and the useful discipline is to decide in writing, at the time, in four lines:

1. What changed, in concrete terms.
2. Was it foreseen in the risk assessment? If yes, say where.
3. Does it affect how any Annex I Part I requirement is met? Name the letters, or state that none is affected and why.
4. Does it modify the intended purpose as assessed? Compare against the intended purpose as your technical documentation actually states it.

Four lines per release, dated and kept. It costs almost nothing and it is the only thing that distinguishes a considered judgement from a convenient one — which is the distinction that matters if the question is ever asked years later, by which time nobody remembers the release.