A software release does not trigger a fresh Cyber Resilience Act assessment simply because the version number changes. Nor is every security patch automatically outside review. Under Regulation (EU) 2024/2847, the practical question is whether a post-market change alters the product’s assessed intended purpose or affects conformity with the essential cybersecurity requirements in Annex I Part I.
The CRA’s main obligations generally apply from 11 December 2027. The Commission’s non-binding guidance of July 2026 gives manufacturers a usable framework for assessing software updates now, before release engineering, cybersecurity and conformity documentation become disconnected.
The legal test has two branches
Article 3(30) defines a substantial modification as a change made after a product with digital elements has been placed on the market that either:
- affects conformity with the essential cybersecurity requirements in Annex I Part I; or
- changes the intended purpose for which the product was assessed.
Code volume, development effort and semantic versioning are not separate legal tests. The Commission guidance instead calls for a case-by-case assessment of whether an update creates new or increased cybersecurity risks and whether the original risk assessment already addressed them.
A security update is usually not substantial – but purpose and exposure still matter
A security update whose purpose is to reduce cybersecurity risk, without changing intended purpose or introducing new risks, should generally not be treated as a substantial modification. This can remain true even where the technical implementation changes significantly.
The Commission examples include correcting input-validation or authentication logic, tightening firewall rules, disabling unused ports, strengthening administrator-password policies, and making an already available or anticipated multi-factor authentication function mandatory. These changes share a defensible risk-reduction objective and do not create a new product use or exposure path.
Security motivation does not provide a blanket exemption. Moving a local encryption function to a mandatory remote service, or replacing an internal key lifecycle with a previously unassessed third-party key-management service, can change product boundaries, data flows, dependencies and external interfaces. A security-driven release may therefore still be substantial.
Four release questions expose the real change
The Commission’s non-exhaustive factors can be translated into four questions for a change-impact review:
- Does the update introduce a new threat vector? Consider interfaces, communication channels, execution environments, remote connectivity and external dependencies.
- Does it enable a new attack scenario? Look for new routes to unauthorised access, manipulation, interference or misuse of the product or its data.
- Does it change the likelihood of an existing scenario? The release may reduce exploitation effort, expose the product to more untrusted actors or weaken a safeguard.
- Does it change the potential impact? Review affected data and functions, operational or safety consequences, and the ability to detect, contain and recover.
If these factors remain unchanged and the assumptions and controls in the existing risk assessment stay valid, a substantial modification is less likely. A material change in any factor requires the manufacturer to revisit the cybersecurity risk assessment and confirm whether the essential requirements are still met.
Planned functionality and minor-looking features need different treatment
A new feature is not automatically a substantial modification. Functionality that was explicitly included in the original intended purpose, architecture and risk assessment, with appropriate safeguards already designed and verified, may be activated later without moving beyond the assessed boundary. The Commission guidance uses pre-assessed group messaging and automated control functions to illustrate staged deployment within an existing risk model.
Conversely, a limited feature can introduce a significant risk. A persistent-login option may create token-theft and session-hijacking scenarios. A diagnostics export may expose sensitive operational data if the new storage path is not protected. Story points, release labels and lines of code cannot replace a cybersecurity impact analysis.
What follows when the modification is substantial
Commission guidance explains that a substantially modified product made available on the market is treated as a new product for CRA purposes, creating a new placing on the market. The original manufacturer should verify conformity of the modified release and, where applicable, perform a new conformity assessment. Existing documentation and tests may be reused for unaffected aspects, provided the manufacturer can demonstrate why those aspects remain valid.
Articles 21 and 22 also matter to importers, distributors and other parties. A party that substantially modifies an already marketed product and makes the modified product available may assume manufacturer obligations. Those obligations can be limited to the affected part where the rest of the product’s cybersecurity is unchanged, but they extend to the entire product when the modification has system-wide impact.
Legacy products still need a documented decision after 2027
Under Article 69(2), products placed on the market before 11 December 2027 are generally subject to CRA requirements only if they undergo a substantial modification from that date. The Commission FAQ contrasts a smart-TV bug fix, which does not qualify, with a later release that adds control of smart-home systems and changes the product’s original function.
This transition must be kept separate from Article 14 reporting. Reporting obligations apply from 11 September 2026 to products within scope, including products placed on the market earlier. A finding that an update is not substantial does not decide whether an actively exploited vulnerability or severe incident must be reported.
A practical release gate for manufacturers
- Freeze the before-and-after baseline: product version, intended purpose, enabled functions, interfaces, privileges, data flows, remote processing and third-party dependencies.
- Map every change to the existing risk assessment and record whether the use and associated risks were already covered.
- Document the decision against threat vectors, attack scenarios, likelihood and impact; avoid relying on “minor version” as a conclusion.
- Update the risk assessment, technical documentation, SBOM, test configuration and release records regardless of the substantial-modification outcome.
- If the release is substantial, define the affected scope, plan necessary testing and conformity assessment, and review the EU declaration of conformity, CE-related information and support period.
- Where third-party conformity assessment is involved, discuss a change that may become substantial early enough to agree the evidence and assessment scope.
Articles 13(7) and 31(2) require risk and technical documentation to remain accurate, complete and continuously up to date. “Not substantial” should therefore be a documented engineering and compliance conclusion, not an absence of records.
How Qianxin can support change-impact readiness
For a defined product, destination market and written scope, Qianxin can support version-baseline checks, standards and testing-needs identification, sample-to-release consistency reviews, and traceability checks linking risks, requirements and test evidence. The responsible economic operator must retain ownership of the substantial-modification conclusion, manufacturer responsibilities, final conformity-assessment route and legal interpretation.
This article reflects public legislation, Commission guidance and FAQs available on 6 September 2026. It provides general information and is not a substitute for product-specific legal advice or a final conformity assessment.
