When does a substantial modification under the CRA require reassessment?
A change to a product triggers reassessment under the Cyber Resilience Act only if it is a substantial modification. Article 3(30) defines this as a change made after the product is placed on the market that either affects compliance with Annex I Part I or changes the intended purpose for which the product was assessed. Security updates usually do not qualify, even when the engineering work behind them is large. The test is what the change does to the product's risk profile, not how many lines of code it touches, so a product team should start by asking whether the update alters a risk its manufacturer's risk assessment did not consider.
Answering that question requires the product's own risk assessment, which the manufacturer owns and must keep current. The reader should check three things against it: whether the update adds a new externally reachable interface, whether it stores sensitive data or authentication tokens in a new way, and whether it enables functions beyond the intended purpose that was assessed. The Commission's guidance treats a new externally reachable interface not foreseen in the risk assessment as enough to make even a security update substantial. The outcome then depends on the assessment route. Most products follow self-assessment under module A, where the manufacturer's own declaration is the result. A notified body is involved only where the product's class requires one, and the reader should confirm that route before deciding how a modification is handled.
Roles should be settled before the release train runs. The manufacturer makes the substantial-modification decision, records its reasoning, and keeps the documentation that supports it. An implementation partner can help prepare the risk assessment, change-impact checks and evidence, but it does not decide the outcome or issue any declaration. Only a notified body, where one is required, or the manufacturer's own module A declaration applies, depending on class. Teams should ask their partner and their assessor, in writing, which change categories trigger a new assessment for their products, and confirm the answer against the Commission's guidance on the application of the regulation.
Which kinds of change the Commission guidance treats as substantial
The guidance, in section 4.3 and by reference to recital 39, treats a software update as a substantial modification when it changes the cybersecurity risk in a way the original risk assessment did not consider. The test looks at the effect on the risk profile, not at how large or technically complex the change is. The examples below are illustrative and come from the guidance's own discussion of the point.
- New function that changes intended purpose: A monitoring dashboard that gains the ability to control machines is a change of purpose, which generally makes the update substantial.
- Persistent login storing tokens locally: Adding a login that keeps authentication tokens stored on the device introduces a new credential exposure that the assessment did not cover.
- Log export storing sensitive data unencrypted: A feature that writes sensitive data to exported logs without encryption creates a new data risk.
- New externally reachable interfaces: Exposing an interface that the risk assessment did not foresee can make the update substantial, even when the release is labelled as a security update.
Before release, check whether the change adds a new purpose, stores new sensitive data, or opens a new attack surface, and record that finding in the risk assessment.
The guidance, in section 4.3, says security updates are generally not substantial modifications, even when the technical change is significant, provided they do not change the intended purpose or introduce new risks. The reasoning is that such updates reduce risk rather than alter the risk profile the assessment was based on. The examples below are illustrative.
- Fixing an authentication bypass: Closing a flaw that let users skip authentication removes a risk and leaves the intended purpose unchanged.
- Making existing MFA mandatory: Requiring a control the product already supports tightens security without adding a new function.
- Adding group chat: A feature that does not change intended purpose and does not introduce new risk generally falls outside the test, though this should be confirmed against the specific design.
- Enabling control features already covered: Turning on functions that the risk assessment already considered does not alter the assessed risk profile.
For each release, confirm that the change is a fix or an already assessed feature, and record the reasoning so an assessor can follow it.
Many changes cannot be classified without knowing what the manufacturer's risk assessment already covered. The same feature can be routine in one product and substantial in another, because the outcome depends on whether the assessment considered the new behavior, interface or data flow. The guidance treats the risk assessment as the reference point, so the classification is only as sound as that document. The points below are illustrative.
- Assessed versus unassessed features: A control feature that the assessment already analyzed is generally a different case from one it never considered.
- Data flows and trust boundaries: A change that moves data across a boundary the assessment modeled differently may alter the risk profile.
- Interface exposure: Whether a new interface is externally reachable depends on the deployment model, so the same code can be safe in one environment and not in another.
- Mixed releases: A single release that contains a security fix and a new function should be assessed as a whole, because the new function may be the substantial part.
- Documented reasoning: Record the assumptions behind each classification so that a notified body or market surveillance authority can review them.
Check whether the risk assessment describes the change at the level of detail needed to answer the question, and update it before the release if it does not.
What makes a software change count against the risk assessment
Each release can be checked against five parallel tests drawn from the CRA's definition of substantial modification and the Commission's guidance. A change that passes none of them is usually a security update or routine maintenance, while a change that trips any one of them needs a closer look at the risk assessment. Size and complexity of the code change are deliberately left out of every test.
Change to intended purpose
Ask whether the release changes what the product is for, or what it was assessed for. The guidance gives the example of a monitoring dashboard gaining the ability to control machines, which generally makes the update a substantial modification. Compare the release notes and product description against the intended purpose recorded in the risk assessment and technical documentation. If the purpose has moved, update the intended-purpose statement and reopen the conformity assessment before release.
New attack surface
Check whether the release adds an externally reachable interface, such as a new network service, API endpoint or open port, that the risk assessment did not foresee. The guidance notes that such additions can make even a security update a substantial modification. Compare the release against the exposed interfaces listed in the risk assessment and the architecture diagrams. Record any new interface, its authentication model and its hardening in the risk assessment before the release goes out.
New data stored or transmitted
Check whether the release stores or sends data the risk assessment did not cover, such as credentials, tokens, personal data or logs. The guidance's example of log export that writes sensitive data unencrypted shows how a feature can change the risk profile without changing the product's purpose. Review data inventories, storage locations and encryption settings against the release. Update the data flow records and the risk assessment entries for each new data category.
Changed authentication or access control
Check whether the release changes how users, services or administrators authenticate, or what they can access. The guidance cites a persistent login that stores authentication tokens locally as a substantial modification. Making existing MFA mandatory, by contrast, is generally a security improvement that does not change the risk profile. Compare the release against the access control model and identity sections of the risk assessment, and record the new token lifetimes, storage locations and role definitions.
Dependency and third-party changes
Check whether the release adds, removes or replaces a third-party component, library, cloud service or open-source dependency in a way that changes the risk picture. A swapped cryptographic library or a new externally hosted service can alter exposure even when the product code looks similar. Compare the new software bill of materials against the baseline in the technical documentation, and update the component entries and the vulnerability handling records tied to them.
What reassessment means for conformity assessment after a modification
A substantial modification sends the product back into conformity assessment, and the route depends on how the product was first assessed. Under Commission CRA FAQ 6.2, a product assessed under module B with module C needs a new assessment by the same or a different notified body after a substantial modification. The manufacturer decides whether a change is substantial, but the notified body decides whether the new version passes. Before shipping a change that touches authentication, interfaces or data storage, the manufacturer should record the reasoning for its decision and bring the notified body into that conversation early, so a reassessment does not become the release bottleneck.
If the product sits on the self-assessment route under module A, no notified body is involved, but the manufacturer still carries the full load. For each new version that is substantially modified, the manufacturer must update the technical documentation, the cybersecurity risk assessment, the evidence behind each Annex I requirement, and the EU declaration of conformity. The new version must also carry its own support period. Teams often update the code and the release notes but leave the risk assessment at the previous version. Treat the risk assessment as a versioned document tied to each release, and confirm which version of the declaration covers the shipped build.
An implementation partner can help prepare this evidence, run a gap analysis of the modified version against the existing risk assessment, and organize the technical file. The partner cannot decide whether a change is substantial for the manufacturer, and it cannot issue a certificate or declaration on the manufacturer's behalf. Only the notified body issues a new certificate. For borderline changes, such as a new interface that is only partly covered by the risk assessment, ask the notified body or the market surveillance authority in the relevant Member State how they would treat the change, and get that answer in writing before the release date.
How to run each release through a reassessment decision
This sequence gives each significant release a documented decision on whether it is a substantial modification, so the conformity assessment, support period and declaration match the version the customer actually receives.
Record the change and its stated purpose
The product owner, with the engineering lead, opens a change record for every significant release. It describes what changed in code, configuration, interfaces, data handling and functions, and states why the change is being made. Record whether it is a security fix, a feature, or both, because the purpose drives the later decision. The step is done when the record is complete enough that someone outside the release team can read it and understand what the product will do differently.
Identify new interfaces and functions
The security lead and architect check the change record for anything that adds an externally reachable interface, a new function, a new data store, or a change to who can control the product. Guidance in C(2026) 5252 notes that a new externally reachable interface not foreseen in the risk assessment can make even a security update a substantial modification, so this check runs on every release, not only feature releases. The output is a short list of additions, or a statement that none exist.
Compare the change with the risk assessment and intended purpose
The security lead compares the change record with the current risk assessment and the intended purpose recorded in the technical documentation. The question is whether the change alters the cybersecurity risk in a way the assessment did not consider, and whether it changes the purpose for which the product was assessed. The output is a written comparison that cites the specific risk entries and functions examined, with a conclusion for each change.
Decide and record whether the change is substantial
The compliance owner makes the substantial modification decision and signs a decision record. The record states the change, the risk assessment entries it was tested against, the test applied (impact on the risk profile and on intended purpose, not the size of the change), and the conclusion. Where the answer is unclear, the record says so and escalates to legal or compliance review rather than defaulting to no. The decision record is the document an authority or auditor will ask to see first.
Run the required conformity assessment for the new version
If the change is substantial, the manufacturer repeats the conformity assessment for the affected version. Under Commission CRA FAQ 6.2, a product assessed under module B with module C needs a new assessment by the same or a different notified body. For a self-assessed product, the manufacturer repeats its own assessment. The output is a completed assessment record for that exact software version, linked to the decision record. Ask any notified body for its written scope and timing before engagement, since these are set by that body.
Declare a support period for the new version
For each substantially modified software version placed on the market, the manufacturer declares its own support period that complies with Article 13(8), as Commission guidance C(2026) 5252 requires. The declaration should name the version, the start of support and the end date, and be reflected in the product information given to users. The output is a versioned support statement, not a restated support policy for the whole product line.
Update technical documentation and the EU declaration
The compliance owner updates the technical documentation to reflect the new version, including the risk assessment, the list of Annex I requirements applied, the vulnerability handling records and the support period. A new or revised EU declaration of conformity is issued for the version where the conformity assessment requires it. The step is complete when each document carries the same version identifier as the release and the change record. Confirm the required content with your conformity assessment body and the regulation's technical documentation requirements before finalizing.
Retain the release record for the support period
The compliance owner files the full release record in the controlled record system: change record, decision record, risk assessment comparison, assessment record, support statement, updated documentation and declaration. These records are kept with the product for the period the regulation requires, which the compliance owner should confirm against the current text. The output is a retrievable release file that lets the organization show, for any shipped version, why it was or was not reassessed.
Legacy products and the 11 December 2027 cutoff
Products placed on the EU market before 11 December 2027 fall under the Cyber Resilience Act only if they are substantially modified from that date, according to Article 69(2) and (3). Until then, the bulk of the regulation does not reach a product simply because it is still on sale or still in use. The cutoff is a trigger, not a grace period for the product as a whole, so a product that is never substantially modified after that date stays outside the Annex I and conformity assessment obligations. Teams should not read the cutoff as permission to ignore the product's security posture, because the reporting duty below works on a different clock.
The Article 14 reporting obligations are the exception. They apply to all in-scope products whenever they were placed on the market, so an older product can already carry a reporting duty without any substantial modification. In practice, if a product with digital elements is in scope and has an actively exploited vulnerability or severe incident, the manufacturer must report it through the Single Reporting Platform. Confirm with your market surveillance authority or legal adviser how your specific legacy products are treated, including whether a product is in scope for reporting and which manufacturer role applies to it.
A modification made after 11 December 2027 can bring a legacy product fully into scope, which makes the cutoff a planning date for engineering as much as legal. Build an inventory of every product, firmware line and software release that will still be changing after that date, and mark each planned change against the substantial modification test before the work is scheduled. Ask the product owners which changes are on the roadmap through 2027 and beyond, and record the reasoning for each decision so an assessor or authority can follow it.
Who becomes the manufacturer after a modification
This table compares three roles that can arise when software is changed after it reaches the market: the original manufacturer, a third party that substantially modifies another party's product and places it on the market, and an organization that only configures a product for internal use. Read each row from the trigger down, since the trigger decides which obligations follow. The main takeaway is that making a product available on the market after a substantial modification can make the modifier a manufacturer, while internal deployment alone generally does not.
| Role | Trigger | Who carries the obligations | Evidence the role must hold |
|---|---|---|---|
| Original manufacturer updating its own product | The manufacturer releases a new software version of a product it already placed on the market, and the update is assessed against the risk assessment for substantial modification | The original manufacturer, which remains responsible for Annex I compliance, the support period declared for each substantially modified version and the Article 14 reporting duty | Updated risk assessment, technical documentation for the new version, a fresh conformity assessment where the product requires one, and a declared support period for that version |
| Third party that substantially modifies another party's product | A party changes a product placed by someone else so that the change affects compliance with Annex I Part I or alters the intended purpose, then makes the product available on the market under its own name or trademark | Under Article 22, the modifier is treated as the manufacturer for the affected part, or for the whole product if the modification affects its cybersecurity as a whole | Its own risk assessment for the modified product, technical documentation, conformity assessment, EU declaration of conformity, CE marking and the vulnerability handling process for the modified part |
| Organization that configures a product for internal use only | The organization deploys, hardens or configures a product in its own environment and does not make the modified product available on the market | Generally none under Article 22, because no product is made available on the market. The organization should still confirm that it has not changed the intended purpose or distributed the result to others | Internal change records, configuration baselines and a written record showing that the output is used only internally and is not supplied to customers or other parties |
| Who decides the role | Whether the change affects compliance with Annex I Part I, whether the intended purpose changes, and whether the modified product is supplied to others | The role follows from the facts of the change and its distribution, so the decision should be documented before release | A dated assessment record that names the change, the risk analysis and the conclusion on role and obligations |
| Confirm with counsel or an auditor | Edge cases such as a reseller that adds features, or a service provider that delivers a customized build to a single customer | The organization makes the determination and owns the outcome. Independent auditors or notified bodies assess conformity but do not decide roles for the organization | Written opinion or internal sign-off on the role, plus the Commission guidance and Article 22 text used as reference |
Who decides, documents and assesses a substantial modification
The product team or engineering lead owns the facts of the change. Their job is to describe what the update does, why it is being made and which parts of the product it touches, before the release goes out. That record is the starting point for every later decision, so it should be written in terms a compliance lead can test against the existing risk assessment.
- Change record: Log each release with its functional purpose, the components affected and whether it adds, removes or changes any interface.
- Interface changes: Flag any new externally reachable interface, port, API endpoint or remote management function, since these are the changes most likely to alter the risk profile.
- Data handling changes: Record new storage of credentials, tokens, logs or personal data, and whether that data is encrypted at rest.
- Intended purpose: State whether the release changes what the product is designed to do, such as a feature that lets a monitoring tool control equipment.
- Security fixes: Separate pure fixes, such as correcting an authentication bypass, from changes that add capability, so each can be routed correctly.
Check that every release in the change log has a short written purpose statement before it reaches the compliance lead.
The compliance lead owns the substantial modification decision and the documentation that supports it. This person compares the change record against the manufacturer's cybersecurity risk assessment and the intended purpose recorded in the technical documentation, then decides whether the change affects compliance with Annex I Part I or alters the intended purpose. The decision must be recorded, dated and tied to a named owner, because an authority may ask for it during market surveillance.
- Decision record: Document the outcome, the reasoning and the Annex I points considered for each release.
- Risk assessment update: Confirm whether the existing risk assessment already covers the change, and revise it where it does not.
- Support period: Where a substantially modified version is placed on the market, set its own support period in line with the requirements.
- Assessment route: Determine whether a new conformity assessment, including any notified body involvement, is needed for the modified version.
- Escalation rules: Define which changes must go to the compliance lead automatically, such as new interfaces or new data stores.
Confirm that the decision record exists for every release that has been reviewed, including those judged not to be substantial modifications.
An implementation partner can prepare the material that supports the decision when that work is outsourced. The partner may draft the updated risk assessment, revise technical documentation, collect test results and assemble evidence for each release. The partner works on the systems and evidence only. The manufacturer remains responsible for the conclusions and for the declaration it signs.
- Risk assessment drafting: Prepare the updated risk assessment for each modified version, for the manufacturer to review and approve.
- Technical documentation: Update the affected sections and keep version history aligned with each release.
- Evidence collection: Gather test results, configuration records and build outputs that show the change was assessed.
- Security testing inputs: Supply findings from testing of new interfaces or data flows so the compliance lead can judge the risk.
- Boundary: The partner does not decide whether a change is a substantial modification and does not issue any report, attestation or certificate.
Ask the partner to state in the statement of work which documents it drafts and which the manufacturer must approve.
A notified body or independent assessor is the only party that can issue a new certificate or assessment outcome for a substantially modified product where the route requires one. Its role begins after the manufacturer has made the decision and prepared the file. The assessor tests the evidence independently and reaches its own conclusion, so it cannot be the party that designed the change or wrote the risk assessment.
- Route dependency: Under the Commission's FAQ, a substantial modification of a product assessed under module B with module C requires a new assessment by the same or a different notified body.
- Scope of review: Expect the assessor to examine the modified risk assessment, the updated documentation and the test evidence.
- Selection: Confirm the body is notified for the relevant product category and check its listing in the Commission's NANDO system.
- Timing: Ask the body for its process and lead times in writing before the release date is fixed.
- Boundary: Neither the partner nor the manufacturer's internal team can substitute for this independent step.
Before a release that may be a substantial modification, confirm with the assessor whether a new assessment is required.
What causes teams to miss or over-trigger reassessment
Teams go wrong in two directions: they treat ordinary patches as reassessment triggers and delay security fixes, or they ship feature changes as if they were security updates and miss a substantial modification. The cards below pair each pitfall with a control that keeps the decision tied to the manufacturer's risk assessment and release records.
Delaying patches out of fear
Some teams hold security fixes because they assume every change needs a new assessment. The guidance says security updates are generally not substantial modifications, even with significant technical changes, when they leave the intended purpose unchanged and introduce no new risk. Fixing an authentication bypass or making existing MFA mandatory are the kind of changes it describes. Avoid the delay by writing a release checklist with one question: does this change alter the cybersecurity risk the assessment considered? Record the answer in the change log for each release.
Treating feature releases as safe
The opposite error is assuming that a change is harmless because it is labelled as security work or touches only a small part of the code. The test is the impact on the risk profile, not the size of the change. A monitoring dashboard that gains the ability to control machines changes the intended purpose, and adding a persistent login that stores tokens locally can alter the risk. Review each feature against the risk assessment before release, not after.
Adding interfaces without updating the risk assessment
New externally reachable interfaces, data flows and export functions are a common source of unplanned change. The guidance notes that adding an externally reachable interface not foreseen in the risk assessment can make even a security update a substantial modification. Log export that writes sensitive data unencrypted is another example from the guidance. Keep an inventory of interfaces and data flows that the risk assessment references, and block a release until a new entry is either added or confirmed as already covered.
Missing the support period declaration
Each substantially modified software version placed on the market must declare its own support period that complies with Article 13(8). Teams often declare a period once for the product line and then ship new versions without revisiting it. Build the declaration into the release pipeline so that each version carries its own statement, and check that the statement matches the support commitments shown to users and in the technical documentation.
Assuming legacy products stay out of scope
Products placed on the EU market before 11 December 2027 fall under the regulation only if they are substantially modified from that date. Teams sometimes assume that a product released earlier is permanently outside the regulation, then ship a later change that counts as a substantial modification. Track the market placement date and the modification history for each product, and run the substantial modification test on every change made after that date. Article 14 reporting applies to in-scope products regardless of when they were placed on the market.
Questions teams ask about substantial modification
Does a security patch always avoid reassessment under the CRA?
Usually yes, but not automatically. The Commission's guidance says security updates are generally not substantial modifications, even when the technical change is large, provided they do not change the intended purpose or introduce new risks. Fixing an authentication bypass or making existing multi-factor authentication mandatory are the guidance's own examples of this. The test is the effect on the risk profile, not the size of the patch. A patch that adds a new externally reachable interface that the risk assessment did not foresee can still make the update a substantial modification, so check each release against the risk assessment before you ship it.
Does every new feature trigger a new conformity assessment?
No. A feature triggers reassessment when it changes the product's cybersecurity risk in a way the risk assessment did not consider, or when it changes the intended purpose for which the product was assessed. The guidance gives adding a persistent login that stores authentication tokens locally, and adding log export that stores sensitive data unencrypted, as examples of substantial modification. Adding group chat, or enabling control features already covered by the risk assessment, is not. Illustrative example: a monitoring dashboard that gains the ability to control machines changes its intended purpose and would generally fall within the definition.
Who decides whether a change is a substantial modification?
The manufacturer decides first, because it owns the cybersecurity risk assessment and the technical documentation that records it. Under the regulation, a person who substantially modifies a product and places it on the market is treated as a manufacturer for the affected part, or for the whole product if the change affects its cybersecurity as a whole. Market surveillance authorities can challenge that judgment during checks. Record the reasoning for each release, including why a change was judged not substantial, so the decision can be explained to an assessor or authority later.
Does a substantial modification always require a notified body?
It depends on the conformity assessment route the product used. Most products follow self-assessment under module A, so the manufacturer repeats its own assessment for the modified version. The Commission's FAQ states that a product assessed under module B with module C requires a new assessment by the same or a different notified body after a substantial modification. Confirm which module applied to your product before planning a release, because the route determines who must be involved and how long the new assessment takes.
What does a new support period mean for each software version?
Each substantially modified software version placed on the market must declare its own support period that complies with Article 13(8). The support period is therefore not a single date for the product line. Teams should track, for every released version, when it was placed on the market, what it changed, and how long it is supported. Build this into release records and customer communications, because an older version may carry a different declared period from the newest one.
How are legacy products affected after December 2027?
A product placed on the EU market before 11 December 2027 falls under the regulation only if it is substantially modified from that date. Its exposure therefore depends on whether later changes cross the substantial modification threshold. The Article 14 reporting obligations are different: they apply to all in-scope products whenever they were placed on the market. Legacy products that receive changes after the cutoff should be reviewed against the risk assessment, and teams should confirm with counsel or a notified body how the transition applies to their specific products.
What must our team do itself, and what can an implementation partner help with?
Your organization owns the controls, the risk assessment, the release decisions and the declaration of conformity, and only that work should stay internal in the sense of accountability. A partner can help prepare the engineering side: release gating that flags changes touching authentication, interfaces or data storage, traceability between risk assessment entries and code changes, and evidence collection for each release. DeployOpen prepares systems and evidence under a fixed written scope, but it does not issue assessments, declarations or certificates, which only the manufacturer or an independent notified body can do. Ask any partner to show exactly which artifacts it will produce.
How DeployOpen prepares update decisions and evidence
DeployOpen works with your engineering and compliance teams to record each software change, test its effect on the risk assessment, and prepare the evidence that supports a substantial modification decision. The organization keeps ownership of the decision, and an independent notified body or auditor issues any assessment result.
How we scope
- The written scope lists which products, versions and update streams the modification review covers before work starts.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing, and a quote follows from that scope.
- Scope names the existing risk assessment and intended purpose baseline that each proposed change will be compared against.
How we build
- We set up a change log that flags new externally reachable interfaces, new stored data, and new control or monitoring features.
- We test proposed changes against the documented risk assessment to see whether the risk profile moves in a way it did not consider.
- We prepare a decision record for each release, showing the reasoning, the tests run and the evidence reviewed.
How we hand over
- You receive the change classification records, risk assessment updates and decision memos as documented deliverables.
- Technical documentation for each software version is updated so a notified body or market surveillance authority can review it.
- We walk your team through the decision process so future updates can be classified in house with the same records.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers for releases across the support period.
- A retainer can cover classifying each new release and refreshing the risk assessment when a change alters the risk profile.
- Confirm with your legal and conformity assessment advisers which decisions require notified body involvement before you engage.
