When does a change make it a new product?
Ship an update and the question follows: is this still the product you assessed? The Commission's July 2026 guidance finally answers it, and the answer is narrower than most teams fear.
You assessed a product, signed the declaration, and shipped it. Then you shipped an update. Somewhere between a typo fix and a rewrite, the product stops being the one you assessed and becomes a new one that needs assessing again. Everyone knows that line exists. Until July 2026 nobody could say where it was.
Section 4.3 of the Commission's guidance draws it. The test has two parts, and a carve-out that covers most of what a security team actually ships.
The test
Following recital 39, a product is substantially modified where a change alters the level of cybersecurity risk, and that altered or additional risk was not already considered in your risk assessment. Both halves matter. A change that moves the risk profile is not substantial if you had already thought about that risk when you assessed the product.
Separately, new functionality that changes what the product is for, its intended purpose taken as a whole, generally qualifies on its own. Your risk assessment was written against a purpose; change the purpose and the assessment no longer describes the product.
Security updates are the carve-out
This is the part worth reading twice. Para 108 says security updates are generally not substantial modifications, because their purpose is to reduce risk rather than change it. A security update that does not modify the intended purpose and introduces no new cybersecurity risk is not a substantial modification, and the guidance is explicit that this holds even where the update makes significant technical changes.
It goes further: it covers cases where functionality is modified or constrained specifically to mitigate a vulnerability. Disabling a deprecated protocol to close a hole does not restart your conformity assessment.
The practical read: patching aggressively does not create regulatory work. Teams that were slowing their security releases for fear of triggering reassessment were solving a problem that does not exist.
What happens if it is substantial
A substantial modification is a new placing on the market. Conformity has to be reassessed for the changed product.
The support period is where teams get this wrong. Paras 132 to 134 say a substantial modification requires the support period to be reassessed against the Art. 13(8) criteria, but it does not automatically reset or extend it. The question is whether the modification affects the factors that set the expected use time in the first place. Where it does not, the criteria still point at the same expected use time, and the support period stays aligned with what remains of the original one.
How to decide, in order
- Does the change alter what the product is for, as a whole? If yes, treat it as substantial.
- Is it a security update that leaves the intended purpose alone and adds no new risk? If yes, it is not substantial, however large the diff.
- Does it alter the level of cybersecurity risk? If no, it is not substantial.
- If it does alter risk: was that risk already considered in your risk assessment? If yes, not substantial. If no, substantial.
Write the answer down either way. The reasoning is what an authority will ask for, and reconstructing it two years later from a commit log is miserable.
Vandorisk asks these questions on the product step and records the finding, with the governing paragraph, into the technical file, so the decision is evidence rather than memory.