Article 69(2) of the Cyber Resilience Act, Regulation (EU) 2024/2847, says that products with digital elements placed on the market before 11 December 2027 "shall be subject to the requirements of this Regulation only if, from that date, they are subject to substantial modifications". The reporting duty of Article 14 applies to them regardless, since 11 September 2026. Everything else, the essential requirements of Annex I, the conformity assessment, the technical file, the CE mark, waits for the first substantial modification. For a software company with a product already on the market, "what is a substantial modification" is therefore the question that decides whether, and when, the Regulation reaches that product at all. And for a product placed on the market after that date, it decides whether a release needs a new conformity assessment.

The Regulation defines the term in Article 3(30) and explains it in Recital 39, and the Commission's guidance of 27 July 2026, C(2026) 5252, section 4.3, paragraphs 103 to 113, applies it to software updates, with eleven worked examples. Sections 4.4.2 and 5 say what follows. This article is those paragraphs, read for a team that ships every week.

The test is the risk assessment, not the size of the change

Paragraph 104 restates Recital 39: a product is substantially modified "where a change alters the level of cybersecurity risk, and where such altered or additional risk has not been considered by the manufacturer in its risk assessment and, consequently, in its implementation of the essential requirements". The manufacturer "should therefore assess, on a case-by-case basis, whether a software update introduces new or increased cybersecurity risks, and whether such risks were already addressed in its risk assessment".

Two consequences follow, and the guidance draws both. First, a change in the product's intended purpose is likely to be one: paragraph 105 says that where new functionalities "result in a change to the product's intended purpose as a whole, it is likely that the manufacturer did not consider such changes in its risk assessment", and example 40 is a monitoring dashboard that gains the ability to control the machines it watches. Second, size is not the test. Paragraph 107: "the assessment of substantial modification should therefore not be based on the scale or complexity of the change, but on its potential adverse impact on the cybersecurity risk profile". Example 44 is the one every product team should read: a "remember me" feature that stores authentication tokens locally "introduces new risks related to token theft, unauthorised access, and session hijacking that were not considered in the risk assessment", and the application "has been substantially modified". Example 45 is a diagnostics feature that exports detailed logs, minor in appearance, that stores sensitive operational data unencrypted: substantially modified.

The other side is paragraph 106. Where the manufacturer "has anticipated the development of those functionalities, has already described and assessed the associated risks, and has implemented appropriate mitigation measures", the update "should therefore not be regarded" as a substantial modification. Example 42 is a messaging app whose original risk assessment covered the later introduction of group chat, "including for example the increased complexity of message routing"; when group chat ships with the foreseen admin and moderation controls, nothing has been substantially modified. Example 43 is a monitoring system shipped with control loops present but disabled and assessed; enabling them is not a substantial modification.

That is the whole mechanism. A risk assessment that names the roadmap absorbs the roadmap. A risk assessment written once, for the product as it was, turns every meaningful feature into a substantial modification.

Security updates: generally not, with two exceptions

Paragraph 108, again from Recital 39: "security updates are generally not to be regarded as substantial modifications, as their primary purpose is to reduce the level of cybersecurity risk". That holds "even where that update may introduce significant technical changes", and it covers functionality that is "modified or constrained solely for the purpose of mitigating identified vulnerabilities". Example 46 is a fix to an input validation error or a session token check. Example 47 is hardening: tightening firewall rules, disabling ports, changing default password policies, making multi-factor authentication mandatory where it already existed. Example 48 is swapping a deprecated algorithm for a stronger one the design already supported.

Paragraph 109 gives the exceptions: a security update that changes the intended purpose beyond what was foreseen, or "materially changes that product's boundaries or dependency structure in a way not foreseen in the risk assessment, e.g. by materially altering data flows, or adding new externally reachable interfaces". Example 49 replaces local file encryption with a remote encryption service run by the manufacturer: the product now does something else, so it is substantially modified despite the security motive. Example 50 replaces an internally managed key lifecycle with a third-party key management service, adding "new external interfaces and reliance on third-party services not considered in the risk assessment": substantially modified.

The four questions to ask of every release

Paragraph 110 lists what a manufacturer "may consider", and it is short enough to put into a pull request template. Does the update:

a. introduce new threat vectors, such as additional interfaces, communication channels, execution environments, or external dependencies through which threats could materialise; b. enable new attack scenarios, including for example new ways in which unauthorised access, manipulation, interference or misuse of the product with digital elements, or of data processed by it, could plausibly occur; c. change the likelihood of previously identified attack scenarios, for example by lowering the effort or expertise required to exploit them, increasing exposure to untrusted actors, or weakening existing safeguards; d. change the potential impact of previously identified attack scenarios, including for example the scope of affected data or functions, the severity of operational, safety or economic consequences, or the ability to detect, contain or recover from an incident.

Paragraph 111: four times no, "provided that the assumptions and mitigation measures relied upon in the risk assessment remain valid and effective", means "it is therefore likely that the update does not qualify". Paragraph 112: any yes means "the manufacturer should reassess the cybersecurity risks" and "determine whether the essential requirements continue to be met". Paragraph 113 adds the duty that does not depend on the answer: "regardless of whether software updates qualify as substantial modifications or not, manufacturers are required to keep the risk assessment and the technical documentation accurate, complete and continuously up to date, in accordance with Articles 13(7) and 31(2)".

What the first substantial modification triggers

Section 4.4.2 is about the original manufacturer, which is the common software case. Paragraph 122: the manufacturer "remains the manufacturer", but "the substantially modified product with digital elements is to be considered as newly placed on the market". Paragraph 123 limits the work: following section 2.1 of the Blue Guide, the manufacturer "may reuse existing documentation and tests for aspects of the product with digital elements that are not impacted by the substantial modification", the conformity assessment "should focus on the substantially modified parts", and a notified body, where one is involved, "should focus its assessment on the substantially modified parts".

For software already on the market before 11 December 2027, paragraph 124 is the sentence to keep. A substantial modification by the original manufacturer "does not, in itself, require the manufacturer to bring the entire product with digital elements placed on the market before that date into full compliance with the CRA, unless the modification negatively affects the cybersecurity of the product with digital elements as a whole. Where the modification does not affect the cybersecurity of the product with digital elements as a whole, the original manufacturer's obligations in respect of the modification should be limited to the substantially modified parts." So the first "remember me" feature after December 2027 puts the login path, not the whole legacy product, under Annex I; a rewrite that changes the product's boundaries puts all of it there.

Section 5 adds the support period. Paragraph 128: "each substantially modified version of a software product with digital elements placed on the market has to have a declared support period that complies with Article 13(8)", at least five years unless the expected use time is demonstrably shorter, and where the modification does not change the factors behind the original expected use time, "the original support period is unaffected". Paragraph 131, for products shipped in short intervals: the manufacturer must declare a support period for each substantially modified version, and may rely on Article 13(10) to stop remediating vulnerabilities in earlier versions "once users are able to upgrade to a later version free of charge and without incurring additional costs", which paragraph 130 reads as excluding "mandatory purchases of new hardware, infrastructure replacement or fundamental changes to the operating environment" but including normal upgrade effort. The support period article covers the rest of Article 13(8).

What this means for a team that ships weekly

Three practices fall out of the paragraphs, none of them new engineering.

Write the roadmap into the risk assessment. Paragraph 106 and examples 42 and 43 reward a risk assessment that names the features you intend to ship and assesses them before they exist. That is cheaper than a new conformity assessment per feature, and it is the difference between example 42 and example 44. The Article 13 risk assessment is where it goes.

Answer paragraph 110 in every release. Four questions, four answers, one sentence each, in the release record. Where all four are no, the record says why the existing assessment still holds. Where any is yes, the release waits for the reassessment paragraph 112 requires, and the risk assessment and technical file are updated under paragraph 113, which is owed anyway.

Decide the legacy question once. For each product on the market before 11 December 2027, record the version as of that date, so that the first substantial modification after it is identifiable, and record with each later release whether it was one and, under paragraph 124, whether it touched the product's security as a whole or only a part.

StandardOS keeps the CRA technical file and the risk assessment as living records rather than documents, so a release can be tied to the four answers and the assessment it relies on. Whether the product is in scope at all comes first.

Sources

  • Regulation (EU) 2024/2847, Article 3(30), Article 13(7), (8) and (10), Article 31(2), Articles 21 and 22, Article 69(2), Recitals 39 to 42 and 60.
  • European Commission, Commission guidance on the application of Regulation (EU) 2024/2847, C(2026) 5252 final of 27 July 2026, Annex, section 4.3 (paragraphs 103 to 113, examples 40 to 50), section 4.4 (paragraphs 114 to 124), section 5 (paragraphs 125 to 131).
  • European Commission, the Blue Guide on the implementation of EU product rules, section 2.1, as the guidance cites it.

This is not legal advice. The eleven examples are two pages and closer to a product team's reality than anything else in the guidance; read them with your last ten releases beside you.