A substantial modification under the Cyber Resilience Act (CRA) is a post-market change that either affects a product's compliance with the essential cybersecurity requirements in Part I of Annex I or changes the intended purpose for which the product was assessed. That means not every patch, repair, upgrade or feature release creates a new CRA product obligation. The practical task is to decide, before making the changed product available on the EU market, whether the change crosses one of those two legal thresholds and to retain the evidence behind that decision.
This matters especially for products already on the market and for organisations that modify products they did not originally manufacture. A substantial modification can trigger manufacturer obligations for the modified product or affected part, and products placed on the market before the CRA's main application date can become subject to the Regulation after such a modification.
Start with the legal definition, not the size of the change
Article 3(30) of Regulation (EU) 2024/2847 defines a substantial modification as a change to a product with digital elements after it has been placed on the market that either:
- affects compliance with the essential cybersecurity requirements in Part I of Annex I; or
- changes the intended purpose for which the product with digital elements was assessed.
The definition does not use lines of code, release size, engineering effort, semantic versioning or internal change categories. A small-looking software change can be important if it changes the intended purpose or creates a cybersecurity effect relevant to Annex I. A large maintenance release can remain outside the definition if it does not cross either threshold.
For change control, the useful question is therefore not "is this a major release?" but "what changed in the assessed product, its purpose, its risk and its ability to meet the applicable essential cybersecurity requirements?"
Apply a two-part decision test
A practical substantial-modification review can begin with two gates.
Gate 1: did the intended purpose change?
The intended purpose is the use for which the product was assessed and is described by the manufacturer through instructions, technical documentation, product information and other relevant material. If a post-market change gives the product a materially different purpose, function or use context from the one assessed, the substantial-modification definition is directly relevant.
Useful questions include:
- Does the changed version perform a new core function?
- Does it serve a new user group, deployment environment or use case that changes the security assumptions?
- Does a new interface or remote capability make the product suitable for a purpose not covered by the previous assessment?
- Have product instructions, architecture or supported operating conditions changed in a way that alters the assessed purpose?
A change in marketing language alone does not determine the answer, but inconsistent descriptions across product documentation, architecture and release notes are a warning that the intended-purpose record needs to be reviewed.
Gate 2: does the change affect Annex I Part I compliance?
Part I of Annex I contains the product cybersecurity requirements that apply to the design, development and production of products with digital elements. A change can be substantial if it affects whether the product continues to meet those requirements, even where the high-level intended purpose remains the same.
The review should compare the changed product against the cybersecurity risk assessment and the security controls that support Annex I compliance. Consider whether the change:
- introduces a new attack surface or trust boundary;
- changes authentication, authorisation, access control or privilege assumptions;
- changes confidentiality, integrity, authenticity or availability protections;
- introduces or changes network, physical or software interfaces;
- alters update, logging, configuration or secure-default behaviour;
- changes cryptographic mechanisms or key-handling assumptions;
- introduces a new remote processing dependency or external service into the product boundary;
- changes the nature of a known hazard or increases the cybersecurity risk;
- invalidates test evidence, threat assumptions or security requirements used for the previous assessment.
The result should be a product-specific judgement backed by engineering evidence. The CRA does not provide a generic percentage-change threshold that teams can substitute for that analysis.
Software updates are not automatically substantial modifications
Recital 39 gives particularly useful guidance for software products and software-driven products. It explains that a software change should be considered a substantial modification where an update changes the product's intended purpose and that change was not foreseen in the initial risk assessment, or where the nature of the hazard changes or the level of cybersecurity risk increases because of the update and the updated version is made available on the market.
The same recital also makes clear that a security update designed to reduce cybersecurity risk, without changing the intended purpose, is not considered a substantial modification. That can include a security update that changes functions or performance solely to address a known vulnerability and reduce the cybersecurity risk.
Similarly, minor functionality changes such as a visual improvement or the addition of pictograms or user-interface languages should not generally be treated as substantial modifications merely because they produce a new software build.
The opposite case requires more care. A feature update that changes original functions, product type or performance and also meets the substantial-modification criteria can be substantial. The recital uses the example of adding a new input element to an application: a new input path can broaden the attack surface and require new input-validation controls.
Whether a feature is shipped alone or bundled with a security update does not change the legal test. Teams should assess the total changed product, not classify a release by its packaging label.
Repairs, maintenance and refurbishment do not automatically reset the CRA assessment
Recital 42 addresses physical products and maintenance activity. Refurbishment, maintenance and repair do not necessarily create a substantial modification when the intended purpose and functionality remain unchanged and the cybersecurity risk level is unaffected.
That distinction is important for manufacturers and service organisations that replace components, restore products or perform field maintenance. Replacing a failed component with an equivalent part under the existing design assumptions is different from an upgrade that changes architecture, connectivity, processing capability or security-relevant functions.
A useful repair record therefore identifies:
- what component or software was changed;
- whether the replacement is functionally and security-relevantly equivalent;
- whether interfaces, connectivity or privilege boundaries changed;
- whether the original risk assessment still covers the resulting configuration; and
- whether any security verification needs to be repeated.
If the change expands functionality or changes the product design in a way that affects intended purpose or compliance, the substantial-modification review should be reopened rather than relying on the label "repair" or "maintenance".
A substantial modification can shift manufacturer responsibility
The CRA attaches consequences to who performs the modification and how the changed product is made available on the market.
Article 21 provides that an importer or distributor is considered a manufacturer for CRA purposes where it places a product with digital elements on the market under its own name or trademark or carries out a substantial modification of a product already placed on the market. In that situation, the relevant manufacturer obligations in Articles 13 and 14 apply.
Article 22 covers another natural or legal person that is neither the manufacturer, importer nor distributor. If that person carries out a substantial modification and makes the modified product available on the market, it is considered a manufacturer for CRA purposes. The obligations apply to the part of the product affected by the substantial modification, or to the entire product if the modification affects the cybersecurity of the product as a whole.
This is why supply-chain organisations should not treat modification responsibility as only a contractual question. Product ownership, branding, technical control and market activity need to be mapped before a modified product is released.
Existing products can enter the main CRA regime after 11 December 2027
The transitional rule in Article 69 is particularly relevant for installed product families and long-lived software.
Products with digital elements that were placed on the market before 11 December 2027 are subject to the CRA's requirements only if, from that date, they are subject to a substantial modification. This means a product originally placed on the market before the main application date does not automatically need to be treated as a newly assessed CRA product merely because it remains in use.
However, a substantial modification after that date can bring the changed product into the Regulation's main requirements. The separate Article 14 reporting obligations are an exception to this transition rule: they apply to in-scope products placed on the market before 11 December 2027 as provided by Article 69(3).
For product roadmaps, this creates a practical dependency between legacy-product strategy and change governance. A major post-2027 upgrade to an older product should be reviewed early enough to determine whether the release will trigger the CRA requirements and the associated evidence and conformity work.
Reassess conformity when the modification is substantial
Recital 41 explains the consequence for conformity assessment. Where a substantial modification may affect CRA compliance, or where the intended purpose changes, the product's compliance should be verified and, where applicable, the product should undergo a new conformity assessment.
The exact conformity route depends on the product and the applicable CRA assessment rules. A change-control board should therefore avoid making the substantial-modification decision in isolation from the conformity-assessment owner.
At minimum, the release record should identify:
- which product and version is being changed;
- the previous conformity basis and technical documentation baseline;
- which intended-purpose, risk or security assumptions changed;
- which Annex I requirements and verification evidence may be affected;
- whether the change is classified as substantial and why;
- whether a new or repeated conformity-assessment activity is required;
- who approved the decision and when; and
- which product version and market release the decision applies to.
Where a third party participates in conformity assessment, Recital 41 also indicates that a change that might lead to a substantial modification should be notified to that third party where applicable.
Treat the cybersecurity risk assessment as the comparison baseline
The CRA requires the manufacturer to perform a cybersecurity risk assessment and take its outcome into account during planning, design, development, production, delivery and maintenance. For substantial-modification decisions, that assessment becomes a natural before-and-after baseline.
A practical release review should compare:
| Review area | Before change | After change | | --- | --- | --- | | Intended purpose | Assessed use and product function | New or changed use and function | | Product boundary | Hardware, software and remote processing | Added, removed or changed elements | | Attack surface | Interfaces and trust boundaries | New or changed exposure | | Security risks | Existing hazards and treatment | New hazards or increased risk | | Annex I controls | Implemented requirements | Controls affected by the change | | Verification evidence | Tests and assessment evidence | Evidence that must be repeated or extended | | Market action | Existing product version | Changed version to be made available |
This comparison makes the decision reviewable later. It also prevents a common failure mode in which the release team decides that a change is "minor" without checking whether the security assumptions behind the product have changed.
Build a substantial-modification gate into release governance
The most reliable time to classify a change is before the changed product is made available on the market, while the engineering context and evidence are still available.
A practical gate can be implemented as a short release decision:
- Identify the exact baseline. Record the previously assessed product, variant and release.
- Describe the change. Link the release scope, architecture delta, changed interfaces and user-facing function.
- Check intended purpose. Determine whether the assessed purpose has changed.
- Check cybersecurity impact. Compare hazards, attack surface, Annex I controls and residual risk.
- Classify the modification. Record substantial, not substantial, or escalate because evidence is insufficient.
- Define follow-up actions. Trigger risk reassessment, security verification, technical-documentation updates and conformity work as required.
- Approve and retain evidence. Preserve the reasons, evidence and accountable decision with the exact product version.
The gate should allow a documented negative decision. Not every release needs a full re-assessment, but a team should be able to show why a release did not change intended purpose or affect the relevant cybersecurity requirements.
Examples: what usually deserves a closer review
Examples are useful as triage prompts, not as automatic legal classifications.
- A vulnerability patch that only reduces cybersecurity risk: generally not a substantial modification when it does not change intended purpose.
- A user-interface language or visual change: generally not substantial by itself.
- A new externally reachable input or API: requires review because it may broaden attack surface and change the risk assessment.
- A new cloud-backed product function: requires review of product boundary, intended purpose, remote processing and new security dependencies.
- A replacement of a failed component with an equivalent part: maintenance does not necessarily create a substantial modification if functionality and risk remain unaffected.
- A hardware or software upgrade that adds major capability: requires a full two-gate review because intended purpose, hazard and Annex I compliance may change.
- A change performed by a distributor or another organisation before making the modified product available: requires both the technical classification and an economic-operator role review.
The decision should be based on the facts of the specific product and release, not on the category name used in a change-management system.
Keeping these decisions traceable becomes difficult when the risk assessment, release scope, security evidence and approval history live in separate systems. AA-sec is designed around traceability between requirements, evidence, release decisions and exact product or lifecycle context, which can support the operational record behind a substantial-modification review. AA-sec does not determine whether a change is legally substantial and does not make the manufacturer's conformity decision.
Key takeaway
CRA substantial modification is a controlled change-classification decision, not a synonym for a large release. The legal test asks whether a post-market change affects compliance with Annex I Part I or changes the product's assessed intended purpose. Software security updates that only reduce cybersecurity risk are generally outside the concept, while new functions, interfaces, risk increases and altered purposes need closer assessment.
For manufacturers, importers, distributors and other organisations modifying products, the practical control is straightforward: compare the changed product with its assessed baseline, record the intended-purpose and cybersecurity impact, determine the responsible economic-operator role, and connect the result to risk assessment, technical documentation and conformity-assessment actions before the changed product is made available on the EU market.
Official sources
- Regulation (EU) 2024/2847 — Cyber Resilience Act — EUR-Lex
- Commission publishes new guidance to support timely Cyber Resilience Act implementation — European Commission
- Cyber Resilience Act implementation - Frequently asked questions — European Commission
- The Cyber Resilience Act - Summary of the legislative text — European Commission