The European Commission has adopted C(2026) 5252, the guidance on applying the Cyber Resilience Act that Article 26(1) requires it to publish. Across 84 pages it works through scope, free and open-source software, substantial modification, support periods, classification, risk assessment, remote data processing and reporting, illustrated by 67 examples.
The guidance is not binding, and the Commission says so in point 8. Only the Court of Justice of the European Union can give an authoritative interpretation. What it represents is the Commission's own view, and it is what market surveillance authorities, notifying authorities and notified bodies will work from.
Two sections repay close reading, because they resolve questions that manufacturers have been answering by guesswork. Section 4 gives an operational test for substantial modification. Section 5 corrects a widespread misreading of the support period.
Substantial Modification: A Test You Can Actually Apply
Article 3(30) defines a substantial modification as a change to a product after its placing on the market which either affects compliance with the essential requirements in Annex I Part I, or results in a modification to the intended purpose the product was assessed against.
That definition is circular in practice. To know whether compliance is affected, you need to know what would affect it. Point 110 breaks the circle with four questions.
Does the update introduce new threat vectors, such as additional interfaces, communication channels, execution environments or external dependencies? Does it enable new attack scenarios, meaning new ways in which unauthorised access, manipulation, interference or misuse could plausibly occur? Does it change the likelihood of previously identified attack scenarios, for instance by lowering the effort or expertise required to exploit them, increasing exposure to untrusted actors, or weakening existing safeguards? Does it change the potential impact of previously identified attack scenarios, including the scope of affected data or functions, the severity of consequences, or the ability to detect, contain or recover from an incident?
Point 111 sets the negative branch, and it is cumulative. Where the update introduces no new threat vectors, enables no new attack scenarios, and does not materially alter the likelihood or impact of known ones, the update likely is not a substantial modification, provided the assumptions and mitigation measures relied upon in the risk assessment remain valid and effective. That last clause does real work. Four negatives are not enough on their own.
Scale Is Not a Factor
Point 107 makes the most useful statement in the section. The assessment should not be based on the scale or complexity of the change, but on its potential adverse impact on the cybersecurity risk profile.
Example 44 shows the small-but-substantial case. A manufacturer adds a "remember me" persistent login feature that stores authentication tokens locally. The functionality is limited in scope. It nonetheless introduces risks of token theft, unauthorised access and session hijacking that the risk assessment never considered, so the application has been substantially modified.
Example 45 makes the same point differently. A new logging and diagnostics feature exports detailed system logs for troubleshooting. It looks minor. It results in sensitive operational data being collected and stored unencrypted, introducing exposure risks that were never assessed or mitigated.
Now the reverse. Example 43 describes a production monitoring system placed on the market with read-only dashboards enabled, while automated control features sit in the architecture but remain disabled. The risk assessment explicitly covers their future activation, including the risks of closed-loop control and safeguards such as operator override and fail-safe states. When the manufacturer later enables those features and activates the assessed safeguards, the system has not been substantially modified. Example 42 does the same for a messaging application whose risk assessment anticipated the later addition of group messaging.
The pattern is clear enough to act on. What decides the question is whether your risk assessment saw it coming.
The Security Update Carve-Out and Where It Stops
Recital 39 says security updates are generally not substantial modifications, because their purpose is to reduce risk. Point 108 confirms this and extends it further than many manufacturers expect. A security update that does not modify intended purpose and does not introduce new risks is not a substantial modification even where it introduces significant technical changes.
Examples 46 to 48 populate the safe zone. Correcting an input validation error that could cause a buffer overflow. Fixing a logic flaw allowing authentication bypass through improper session token validation. Tightening firewall rules, disabling unused network ports, changing default administrator password policies, making multi-factor authentication mandatory where the functionality already existed. Disabling a deprecated cryptographic algorithm and activating a stronger alternative the product already supported, where the risk assessment anticipated the deprecation and included cryptographic agility as a mitigation.
Point 109 then closes the escape hatch. A security update qualifies as a substantial modification where, notwithstanding its security objective, it modifies the intended purpose beyond what was originally foreseen, or introduces new or increased risks. The guidance names the mechanism: materially changing the product's boundaries or dependency structure, altering data flows, or adding new externally reachable interfaces.
Example 49 is the clearest illustration. A product provides local file encryption on the user's device. After a vulnerability is found in the encryption workflow, the manufacturer removes local encryption and requires all files to be uploaded to and processed by a remote service it operates. The motive is security. The product now does something different from what it was assessed to do, so this is a substantial modification.
Example 50 is subtler and more common. A manufacturer replaces an encryption protocol and its internally managed key lifecycle with a different protocol requiring an external key management service run by a third party. Dependencies and data flows are materially altered, new external interfaces appear, and reliance on a third-party service enters the picture. Security-driven, and still substantial.
If you take one operational rule from section 4, take this. A security update that adds an external dependency is not covered by the carve-out.
What Follows From a Substantial Verdict
Point 116 states the consequence. A substantially modified product made available on the market is treated as a new product, and making it available constitutes a new placing on the market.
The obligations that follow are proportionate rather than total. Point 123 confirms that an original manufacturer may reuse existing documentation and tests for aspects the modification did not touch, and that a conformity assessment should focus on the substantially modified parts. Where a third-party body is involved, it too should focus on those parts.
Where someone other than the original manufacturer carries out the modification, Articles 21 and 22 make them the manufacturer of the modified product. Point 118 limits that: their Article 13 and 14 obligations extend only to the part affected, provided the modification does not harm the cybersecurity of the product as a whole. Point 121 removes the limit where the modification is no longer targeted at a specific component and the overall risk profile has changed.
Point 120 draws a distinction worth internalising. Integration is not modification. A company that buys off-the-shelf microcontrollers and connectivity components, writes its own firmware, and assembles them into a connected agricultural monitor is not modifying a product already on the market. It is placing a new product on the market, and it owns compliance for that product as a whole.
The Support Period: Five Years Is a Floor
Article 13(8) requires manufacturers to determine a support period reflecting the time the product is expected to be in use, and says it must be at least five years unless the product is expected to be in use for less.
A great many manufacturers have read that as "declare five years." Point 126 says the opposite. The minimum operates only as a safeguard. Recital 60 clarifies that products reasonably expected to be in use for longer than five years should have correspondingly longer support periods. The guidance states plainly that a support period of five years is not to be considered the default for all products.
The determination runs the other way around from how it is usually done. Establish the expected time in use from reasonable user expectations, the nature of the product and its intended purpose, and any Union law setting a lifetime. Article 13(8) then lists further matters a manufacturer may weigh, and they sit in the Regulation itself rather than in the guidance. The support periods of similar products placed on the market by other manufacturers, the availability of the operating environment, the support periods of integrated third-party components that provide core functions, and relevant guidance from the dedicated administrative cooperation group. Article 13(8) also requires those matters to be considered in a way that ensures proportionality. The support period then follows from that figure, with five years catching only the short tail.
Iterative Software and Article 13(10)
Point 128 addresses continuously released software. Each substantially modified version placed on the market must have a declared support period complying with Article 13(8), including the five-year minimum, unless that version's expected use time is demonstrably shorter.
Read alone, that is punishing for a product shipping a substantial modification every quarter. Article 13(10) is the relief valve. A manufacturer may address and remediate vulnerabilities only for the version last placed on the market, provided users of earlier versions can upgrade free of charge and without incurring additional costs.
Point 130 defines "additional costs" in a way that favours manufacturers. It does not cover reasonable operational effort inherent in applying updates, such as personnel time, routine testing, configuration adjustments, or upgrades of underlying software dependencies needed to address end-of-life components. It does cover mandatory purchases of new hardware, infrastructure replacement, or fundamental changes to the operating environment.
So the practical position for enterprise software is workable. Ship substantially modified versions regularly, declare a compliant support period for each, and rely on Article 13(10) to concentrate remediation on the current release, as long as upgrading is free and does not force customers to buy new infrastructure.
Two obligations survive regardless. Point 131 confirms that the other Part II Annex I requirements continue for all subsequent substantially modified versions, notably the coordinated vulnerability disclosure policy and measures to facilitate information sharing about potential vulnerabilities. Footnote 18 adds that where remediation for earlier versions is discontinued, users who have not upgraded should be informed where technically feasible, under Article 13(19).
A Substantial Modification Does Not Reset the Clock
Section 5.1 corrects an assumption that sounds reasonable and is wrong. Point 133 states that a substantial modification requires a reassessment against the Article 13(8) criteria, but does not automatically result in the support period being reset, or even extended.
The question is whether the modification affects the factors that originally determined the expected use time.
Example 54 gives the negative case. A robot vacuum has an expected use time set by the physical durability and wear characteristics of its hardware. Years later a software update adds new cleaning modes and navigation features, qualifying as a substantial modification. The update does not affect hardware durability or reasonable user expectations about the product's lifetime, so the Article 13(8) criteria still indicate the same expected use time. The support period aligns with the remaining expected use time as originally determined.
Example 55 makes the same point for a cloud back-end. An industrial machinery product has an expected use time driven by the durability of the machinery. The manufacturer rearchitects the cloud back-end, introducing new APIs and data flows in a way that qualifies as a substantial modification. The nature of the product and user expectations are unaffected, so the period does not move.
Example 56 gives the positive case. A programmable logic controller has an expected use time set primarily by the durability of its hardware. The manufacturer replaces the embedded computing platform, including processor, memory and runtime environment, with components designed for a significantly longer operational lifetime. Reasonable user expectations and the nature of the product both change, the criteria now indicate a longer expected use time, and the manufacturer recalculates accordingly.
The rule to encode in your process is "re-derive," never "reset" or "extend."
What This Means for Your Process
Three changes are worth making now.
Record a support period basis alongside the number. If your technical file contains "60 months" with no reasoning, you have documented a conclusion without its premise, and point 126 means the number itself is now the thing a market surveillance authority will question. Capture the expected time in use, the evidence behind it, and the criteria you applied.
Make the four-factor test a step in your release process rather than a judgement someone makes afterwards. Four yes-or-no answers with evidence, plus a check that the risk assessment's assumptions still hold, produces a defensible determination in minutes. Guessing produces a position you cannot reconstruct two years later when it matters.
Stop treating change size as a signal. The instinct that a small diff means a small compliance question is exactly what points 107, 110 and Example 44 exist to correct. A twenty-line change that stores tokens locally is substantial. A large refactor that touches no interface, no dependency and no data flow is not.
The nearer deadline has not moved. Article 14 reporting obligations apply from 11 September 2026 to every product in scope, including products placed on the market before 11 December 2027, and they continue after a product's support period ends.