Under the Cyber Resilience Act, what if a hardware product cannot run the latest software version?
The CRA does not let the manufacturer stop there.
Recital 40 says that where a hardware product is not compatible with the latest version of the operating system it was originally delivered with, the manufacturer should continue to provide security updates at least for the latest compatible version for the support period.
Recital 40 says incompatible hardware should continue receiving security updates for at least the latest compatible operating-system version during the support period.
Under the CRA, if a release is labelled a security update, does that automatically mean it is not a substantial modification?
No.
Recital 39 and the March 2026 draft guidance say security updates are generally not substantial modifications when they only reduce cybersecurity risk, do not change the product's intended purpose, and do not introduce new cybersecurity risks. But a security-driven change can still be substantial if it changes the intended purpose beyond what was originally foreseen or introduces new interfaces, dependencies, data flows, or other risks that were not covered in the original risk assessment.
Points 101-102 say risk-reducing security updates are generally not substantial modifications, but security-driven changes can still be substantial if they alter purpose or add risks.
Under the Cyber Resilience Act, are later functionality updates automatically substantial modifications?
No.
The March 2026 draft guidance says later functionality updates are not substantial modifications just because they add or activate features. If the original risk assessment already foresaw those later functions, already assessed their risks, and already accounted for the needed mitigation measures, the later rollout should not be treated as a substantial modification.
Under the CRA, can a small-looking feature update still become a substantial modification?
Yes.
Recital 39 and the March 2026 draft guidance both make clear that the scale of the feature is not the legal test. Even a limited update can be substantial if it modifies the original intended functions or type or performance of the product in a way that increases cybersecurity risk, or if it introduces new or increased risks that were not covered in the original risk assessment.
Under the Cyber Resilience Act, does it matter for substantial-modification analysis whether the feature change was shipped separately or bundled with a security update?
No.
Recital 39 says that when assessing whether a feature update is a substantial modification, it is not relevant whether the feature update is provided separately or in combination with a security update. What matters is the effect on intended purpose and cybersecurity risk, not the packaging of the release.
When Article 13(10) says users must not incur additional costs to move to the latest version, what does that cover?
The March 2026 draft guidance says this should be interpreted practically and proportionately.
Reasonable operational effort does not itself count as additional costs. The guidance gives examples such as personnel time, routine testing, configuration adjustments, and upgrades of underlying software dependencies that are necessary to address end-of-life components or known vulnerabilities. By contrast, additional costs mean burdens going beyond normal software maintenance, such as mandatory purchases of new hardware, infrastructure replacement, or fundamental changes to the operating environment.
If an update is not a substantial modification, can the manufacturer leave the CRA documentation unchanged?
No.
The March 2026 draft guidance says that regardless of whether a software update qualifies as a substantial modification, manufacturers remain responsible for the security of the update and of the product during the support period. It also says the cybersecurity risk assessment and technical documentation must remain accurate, complete, and continuously up to date. That aligns with Articles 13(7) and 31(2).
What is a substantial modification under the Cyber Resilience Act?
A CRA substantial modification is a change made after a product with digital elements has been placed on the market that affects the product's compliance with Annex I Part I essential cybersecurity requirements or changes the intended purpose for which the product was assessed.
The test is about the change's cybersecurity and intended-purpose effect. A release note label such as patch, upgrade, repair, maintenance, hotfix, or feature update does not decide the answer by itself.
Does every post-market software update become a CRA substantial modification?
No. Software development is iterative, and the CRA guidance expects a case-by-case assessment.
A later software iteration is not substantial merely because the code changed. The key question is whether the update introduces new or increased cybersecurity risks that were not already covered in the original risk assessment, affects compliance with the essential requirements, or changes the product's assessed intended purpose.
Recital 39 distinguishes security updates and minor functionality updates from feature updates that change intended functions, type, performance, or risk.
Are CRA security updates usually substantial modifications?
Usually no. A security update whose purpose is to reduce cybersecurity risk, and that does not change the product's intended purpose or introduce new cybersecurity risks, should generally not be treated as a substantial modification.
That remains true even if the update changes internal implementation or constrains an existing feature solely to mitigate a vulnerability.
Recital 39 says security updates designed to decrease cybersecurity risk are not considered substantial modifications when intended purpose is not modified.
Can a security update still become a CRA substantial modification?
Yes. A security-driven change can still be substantial if it moves the product beyond the intended purpose originally assessed or introduces new risks that were not foreseen in the original cybersecurity risk assessment.
Examples from the draft guidance include security updates that move local processing to a remote service, change the trust model, add new external dependencies, or materially change data flows.
What practical risk factors should a CRA software-change review check?
Start with the original intended purpose, architecture, threat model, risk assessment, technical documentation, and release scope. Then check whether the update changes the cybersecurity risk profile in a way the original assessment did not cover.
New threat vectors: interfaces, communication channels, execution environments, remote processing, third-party services, or external dependencies.
New attack scenarios: new ways to gain unauthorised access, manipulate the product, interfere with functions, or misuse processed data.
Changed likelihood: lower exploitation effort, increased exposure to untrusted actors, weakened safeguards, or wider reachable attack surface.
Changed impact: broader data exposure, more severe operational or safety consequences, harder detection, or reduced containment and recovery.
If a manufacturer adds new functionality, when is it likely to be substantial?
New functionality is more likely to be substantial when it changes the product's intended purpose as a whole or introduces cybersecurity risks that were not considered and mitigated in the original risk assessment.
A large feature is not required. A small-looking addition can be substantial if it changes the attack surface or risk profile in a way that affects compliance with the essential requirements.
Can planned feature activations avoid substantial-modification treatment?
Yes, if the later functionality and its risks were already included in the original intended purpose, cybersecurity risk assessment, mitigations, and technical documentation.
The practical evidence should show that the update implements a foreseen design path rather than expanding the product into a new intended use or unassessed risk profile.
Do repairs, maintenance, or refurbishment automatically create a CRA substantial modification?
No. Repairs, maintenance, and refurbishment do not necessarily lead to a substantial modification when the product's intended purpose, functionality, and cybersecurity risk level remain unaffected.
The repair becomes more sensitive when it changes how core functions operate, changes intended purpose, or affects compliance with Annex I Part I requirements.
Does replacing a defective part with a better-performing part automatically count as substantial?
No. Replacing a defective or worn item with a better-performing part does not itself trigger substantial modification.
It becomes substantial only if the performance change or changed operation affects compliance with essential cybersecurity requirements or changes the intended purpose that was covered by the original risk assessment.
How should CRA teams treat spare parts that are not identical to the original component?
A non-identical spare part may itself be a CRA product because it does not fall within the identical-spare-parts exemption. That does not automatically mean the host product has been substantially modified.
For the host product, assess whether the replacement changes intended purpose, functions, interoperability assumptions, cybersecurity risk profile, or compliance with Annex I Part I. For the spare part itself, assess CRA compliance in light of its own intended purpose and any compatibility or interoperability constraints.
When does a substantial modification create new CRA manufacturer obligations?
When a product is substantially modified and the modified product is made available on the market, the modified product is treated as a new CRA product event. The person carrying out the substantial modification, or having it carried out, is treated as the manufacturer for the modified product.
If the original manufacturer makes the substantial modification, it remains the manufacturer. If another party makes the substantial modification and makes the modified product available on the market, that party can become responsible for the relevant CRA manufacturer obligations.
Do importers, distributors, and other third parties become manufacturers under the same CRA rule?
No. The CRA separates the provisions.
Article 21 covers importers and distributors that carry out a substantial modification of a product already placed on the market. Article 22 covers other natural or legal persons where they carry out a substantial modification and make the modified product available on the market.
If only one part is affected, do CRA obligations apply only to that part?
Article 22 narrows the obligation to the part affected by the substantial modification, unless the modification affects the cybersecurity of the product as a whole.
In practice, the evidence should explain the affected boundary. If the changed part alters shared authentication, update mechanisms, communications, data flows, remote processing, or other whole-product security assumptions, teams should expect the whole-product assessment to be relevant.