CRA Substantial Modification: When Does a Software Update Re-Trigger Your Conformity Assessment?

Most software teams ship updates constantly - patches, bug fixes, new features, performance improvements. Under the Cyber Resilience Act, one question now sits behind every release: does this update constitute a substantial modification? If it does, the updated product is treated as newly placed on the market, and your conformity work starts again. If it doesn't, your existing CE marking and Declaration of Conformity hold.

The good news: the bar is not as low as many teams fear. The bad news: you need a documented process to prove you cleared it.

This article is general guidance on the Cyber Resilience Act, not legal advice. Confirm specifics against the official regulation text and, where needed, a qualified adviser.

---

Key points

• A CRA substantial modification is defined in Article 3(30) of Regulation (EU) 2024/2847: a post-market change that either affects compliance with the Annex I essential cybersecurity requirements, or changes the product's intended purpose.
• Routine security patches, bug fixes, and minor functional changes are generally not substantial modifications.
• The test hinges on one question: does this update introduce new or increased cybersecurity risks that were not already covered in the original Article 13 risk assessment?
• A substantially modified product is treated as a new product: it needs renewed conformity work, a new EU Declaration of Conformity, and a fresh support period declaration.
• On 3 March 2026, the European Commission published a ~70-page draft guidance document interpreting the CRA; the consultation closed 31 March 2026. The guidance is draft and non-binding - the regulation text prevails. Treat it as a strong signal of enforcement intent, not settled law.

---

What "substantial modification" actually means in the CRA

Article 3(30) of Regulation (EU) 2024/2847 defines a substantial modification as a change to a product with digital elements, following its placing on the market, which affects the product's compliance with the essential cybersecurity requirements in Annex I, Part I, or which results in a modification to the intended purpose for which the product was assessed.

Two limbs, either of which is enough:

1. Compliance effect - the change affects whether the product meets the Annex I, Part I essential requirements.
2. Intended purpose - the change alters the purpose for which the product was originally assessed.

The CRA's preamble adds important texture. A product is substantially modified by a software change where the update modifies the intended purpose in a way not foreseen in the initial risk assessment, or where the nature of the hazard has changed or the level of cybersecurity risk has increased. Conversely, a security update designed to decrease cybersecurity risk, without modifying the intended purpose, is explicitly not a substantial modification - even if it involves non-trivial code changes.

The preamble also flags feature updates specifically: where a feature update modifies the original intended functions or the type or performance of a product and meets the above criteria, it should be considered a substantial modification, because adding new features typically broadens the attack surface.

What the Commission's 2026 draft guidance adds

The Commission's draft guidance - published under Article 26 of the CRA, which requires the Commission to assist economic operators - gives the most detailed interpretation yet of how to apply these rules to software updates in practice.

The guidance stresses that this is a case-by-case assessment. It should take into account the intended purpose of the product, whether compliance is affected, and how the risk profile changes after the modification. For software updates specifically, the guidance focuses on whether the update introduces new threat vectors or materially alters existing attack scenarios.

The practical upshot: the question is not "how big is this update?" but "does it introduce cybersecurity risks that my original Article 13 risk assessment did not address?"

The Commission's draft guidance also clarifies that, for conformity assessment following a substantial modification, existing tests and documentation can be reused for unchanged aspects - assessment concentrates on the modified parts while considering the effect on the product as a whole. You do not start from zero.

The practical line: what is and isn't a substantial modification

Use this as a working reference, not a legal checklist. Every case turns on its own facts.

What happens when a modification is substantial

If a change qualifies as a substantial modification, the modified product is treated as newly placed on the market, and the party carrying out or commissioning the modification is treated as the manufacturer for CRA purposes.

That has three concrete consequences:

1. Renewed conformity assessment. You must re-run the appropriate conformity route for your product class - self-assessment (Module A) for default products, third-party assessment for Important Class II and Critical products. Crucially, you only re-run the parts affected by the change; existing documentation and test results for unchanged aspects can be carried forward.

2. New EU Declaration of Conformity. The substantially modified version needs its own DoC. See our CE marking and Declaration of Conformity guide for what that document must contain.

3. New support period declaration. The Commission's draft guidance clarifies that the manufacturer must declare a new support period for each substantially modified version. This matters for how long you are obligated to provide security updates for that version. See the support period guide for the full picture.

One further consequence worth noting: products placed on the market before 11 December 2027 are subject to the CRA only if, from that date, they are subject to a substantial modification. This means the substantial modification concept is also the gateway that brings legacy products into scope - making it doubly important to get the assessment right.

Building a "substantial modification gate" into your release process

The most practical thing you can do right now is add a lightweight decision step to your release workflow. It does not need to be a legal review for every patch. It needs to be a documented, consistent check that you can show to a market surveillance authority if asked.

The gate should be keyed to two questions drawn directly from the regulation and the Commission's draft guidance:

Question 1: New or changed functions that raise cybersecurity risk? Does this update add or alter product functions in a way that increases the cybersecurity risk - for example, by adding a new network interface, a new input field, or a new third-party integration? If yes, does the original Article 13 risk assessment already cover those risks? If not, you are likely in substantial modification territory.

Question 2: Change of intended purpose? Does the update change what the product is for in a way that was not foreseen in the original risk assessment? A product that starts doing something materially different - even if the code change looks small - may cross the line.

If the answer to both is no: document that conclusion and move on. If the answer to either is yes: treat the update as a substantial modification and re-run the relevant conformity steps.

Keep your Article 13 risk assessment current and versioned

The substantial modification test is anchored to your Article 13 risk assessment. A change is substantial if it introduces risks not already covered by that document. Which means: the more current and comprehensive your risk assessment, the clearer your substantial modification decisions will be.

Practically, this means:

• Version your risk assessment alongside your product releases. When you ship a significant update, update the risk assessment to reflect it - even if the update is not a substantial modification.
• Record your substantial modification decisions in or alongside the risk assessment. Note the update, the question you asked, and the conclusion you reached.
• Keep the record with your technical documentation. Market surveillance authorities can ask to see it. The burden of proof that a change is not substantial sits with the person who made the change.

See our Article 13 risk assessment guide for how to structure and maintain this document, and use the scope and class checker to confirm which conformity route applies to your product.