Substantial modification under the Cyber Resilience Act, the
Machinery Regulation, the Product Liability Directive and the AI Act —
and why the decision is made in your architecture reviews, not in your
legal department.
Most engineering teams do not think of a software release as a
regulatory event. Requirements are collected, features are developed,
tests pass, cybersecurity reviews are signed off, and the update ships.
Business as usual.
Yet under four EU texts now entering into application, one firmware
update can legally turn a product you shipped years ago into a new
product — and turn whoever made the change into its manufacturer, with
everything that title implies: a new conformity assessment, CE marking
responsibilities, and a liability clock that starts again from zero.
The term that does this is substantial modification.
It appears in the Cyber Resilience Act (CRA), the new Machinery
Regulation (EU) 2023/1230, the revised Product Liability Directive (PLD)
and the AI Act — and each text applies its own test.
Table of Contents
Why this matters now
These are not distant deadlines. Two of the four texts apply within
months:
| EU text | Applies from |
|---|---|
| Product Liability Directive (EU) 2024/2853 | 9 December 2026 — products placed on the market from that date |
| Machinery Regulation (EU) 2023/1230 | 20 January 2027 |
| Cyber Resilience Act (EU) 2024/2847 | 11 December 2027 (reporting duties already apply since 11 September 2026) |
| AI Act (EU) 2024/1689 — high-risk systems | 2 December 2027 (stand-alone) / 2 August 2028 (AI in regulated products) |
Most companies treat these dates as a one-off compliance project. The
harder part comes afterwards: products are updated for years, and every
update can reopen the question of whether the product on the market is
still the product that was assessed.
What a missed
substantial modification costs
When a change crosses the line and nobody noticed, four consequences
follow:
- A new conformity assessment — updated risk
analysis, technical file, tests, and notified-body fees where required.
The release waits until it is done. - Loss of legacy status — a product placed on the
market before the CRA or AI Act applies stays outside those requirements
only until it is substantially modified. One update can pull an entire
legacy product line into full compliance: secure development process,
vulnerability handling, SBOM. - A liability clock restarted — under the new PLD,
the ten-year liability period restarts when the modified product is made
available. A nine-year-old product becomes a fresh ten-year risk,
carried by whoever made the modification. - Fines and market measures — up to €15 million or
2.5% of worldwide turnover under the CRA, €15 million or 3% under the AI
Act, plus possible withdrawal or recall orders.
And this applies to more than the original maker: under all four
texts, an integrator, distributor or importer who
substantially modifies a product is treated as its manufacturer.
The illusion of continuity
Why is this so easy to miss? Because software creates an illusion of
continuity. The customer sees the same enclosure, the same product name,
the same hardware — only a version number changes.
From a systems perspective, the situation can be radically different.
A machine that was isolated now talks to a cloud service. A controller
that processed everything locally now depends on external
infrastructure. A deterministic algorithm now embeds AI-assisted
decision support. The visible product is identical; the system that was
assessed is not.
The decision
is made in engineering, not in legal
When “substantial modification” comes up, people picture regulatory
specialists. In practice, the decisive choices are made months earlier,
in architecture reviews, when engineers decide to:
- add remote connectivity or remote maintenance,
- expose a new API or open a network port,
- move processing to a cloud service,
- touch a safety function or its parameters,
- introduce an AI-assisted function.
None of these are legal decisions. Every one of them can invalidate
the assumptions behind the original safety, cybersecurity or conformity
assessment. The same feature, designed differently, can pass every test
— or fail three of the four. Read-only diagnostics on an isolated
channel is not the same product evolution as write access to safety
parameters.
The one piece of good news: “not foreseen” is the common
thread of all four tests. A change that was planned, assessed
and documented in the initial conformity assessment is generally not
substantial. A product roadmap written into the first risk assessment is
a real cost lever.
The release check you
can run next week
A structured change-impact review takes a few hours of engineering
time per release — against the cost of a recertification, a recall, or a
restarted liability period. It starts with questions like these:
- Does the change add or alter a function, an interface or the
intended use? - Was it foreseen and documented in the original risk or conformity
assessment? - Does it change the cybersecurity risk: new connectivity, new data, a
new attack surface?
Those are three of the eight release-gate questions
we detail in our white paper, together with the four legal tests
compared article by article, the architectural patterns that most often
trigger them (connectivity, cloud migration, AI integration), a worked
servo-drive example and an architect’s checklist.
Frequently asked questions
Is a security patch a substantial modification under the
CRA? As a rule, no. The European Commission’s guidance confirms
that updates whose purpose is to reduce risk, without changing the
intended purpose or adding new risks, are not substantial
modifications.
Does a substantial modification affect a product sold before
the CRA applies? Yes. A product placed on the market before 11
December 2027 stays outside the CRA’s requirements only until it is
substantially modified. After that, the modified product must
comply.
Who is liable when an integrator modifies a product?
Under the PLD, the party that substantially modifies a product outside
the original manufacturer’s control is liable as a manufacturer of the
modified product, and the ten-year liability period restarts from that
modification.
Can a software-only change be a substantial modification
under the Machinery Regulation? Yes. The Regulation states
explicitly that the modification may be physical or digital, including a
change to safety-related software.
Free white paper — “Your Next Release May Change More Than
the Software”
The complete engineering guide to substantial modification under the
CRA, the Machinery Regulation, the PLD and the AI Act: the four tests
side by side, the costs, the architectural patterns, the eight-question
release gate and the architect’s checklist.
About ISIT-Neperis. ISIT-Neperis works where
functional safety, cybersecurity and regulation meet: change-impact
assessments, CRA and functional-safety training, and certified safety
communication stacks delivered with their certification evidence. If a
release on your roadmap raises one of these questions, talk to us before
the architecture is fixed.
This article provides general information and is not legal
advice. Check the official texts and your own risk assessment before
deciding.