The CRA Clause That Turns an Update Into a New Product

---

The short answer

Under the Cyber Resilience Act, a substantial modification can restart your conformity obligations.

The product you assessed is, legally, no longer the product you are shipping. Technical documentation must be updated, and depending on the class, the conformity assessment may need to be redone.

For hardware, teams understand this instinctively — a new revision is a new product. For software, the same logic applies and almost nobody has a process for it.

---

Why this is a software problem specifically

A hardware revision is visible, planned, and rare. A software release is invisible from outside, frequent, and often automated.

hardware   a few revisions per product lifetime
software   dozens or hundreds of releases per year

If even a small fraction of releases are substantial modifications, and no process detects them, the assessed configuration and the shipped configuration diverge silently.

An authority does not audit your release process. It audits the product in the market against the documentation you hold. Divergence is the finding.

---

What tends to make a modification substantial

The Commission's July 2026 guidance addressed this among its practical examples, and the underlying logic is consistent: a modification is substantial when it changes the intended purpose, or affects compliance with the essential requirements.

In practice, the changes that most often qualify:

• A new network interface or protocol — the attack surface changed
• A new data category processed, particularly personal or sensitive data
• A change in the authentication or update mechanism — these are essential requirements in their own right
• New functionality that changes intended purpose — a monitoring device that becomes a control device
• Integration of a new remote data processing component

And the ones that generally do not: security patches that restore the assessed behaviour, bug fixes, performance work, cosmetic changes.

---

The clarification that matters most

A security update is not, by itself, a substantial modification.

This matters because the opposite reading produces a perverse outcome: teams delaying patches to avoid triggering reassessment. The regulation is not built to discourage patching, and reading it that way gets both the law and the security wrong.

The distinction is direction of travel. A patch that restores the product to its assessed security behaviour is maintenance. A change that moves the product somewhere it has not been assessed is a modification.

---

What a working process looks like

A gate in the release process, not a periodic review. Periodic review discovers divergence months later, which is exactly the finding you are trying to avoid.

each release  ->  does it change intended purpose?
                  does it change an essential requirement?
                  new interface, new data, new update path?
                       |
                  no   -> ship, note the determination
                  yes  -> update technical documentation,
                          reassess conformity route

Record the determination either way. The "no" answers are the evidence that the gate exists and runs — and a gate with no recorded negatives looks like a gate nobody uses.

Name who decides. In practice this needs an engineer who understands the change and someone who understands the obligation. It rarely works as a compliance-only decision, because compliance cannot see the diff.

---

Why this is worth doing before September 2026

CRA Article 14 reporting obligations apply from 11 September 2026, and the full regulation from 11 December 2027.

A modification process is cheap to build now and expensive to reconstruct later, because reconstructing it means going back through releases you have already shipped and determining, retroactively, which were substantial. Those determinations carry today's date on a decision made months ago — and that is precisely the pattern an authority reads as a process that did not exist.

---

Four things to do this quarter

1. 1Add the question to your release checklist. Four lines, asked every time.
2. 2Write down who decides, and make sure that person sees the actual change.
3. 3Record every determination, including the negatives.
4. 4Separate "security patch" from "modification" explicitly in policy, so nobody delays a patch out of compliance anxiety.

---

Check what applies to your product — free, no account

• [Free readiness assessment](/assess) — your CRA class and the obligations that follow
• [Penalty calculator](/resources/penalty-calculator) — exposure on your own turnover

---

Further reading

→ Products with digital elements, defined → Important versus critical under the CRA → Audit-ready evidence for the CRA → Post-market monitoring

---

*This is regulatory information, not legal advice, and nothing here constitutes a compliance guarantee. Whether a specific modification is substantial is a determination on the facts of your product. Verify against the current text and Commission guidance, and consult your competent authority or a qualified adviser.*