Let’s talk about substantial modifications—one of the trickier concepts in the CRA.
According to Article 3(30) of the Cyber Resilience Act, a “substantial modification” is a change to a product with digital elements after it’s placed on the market that either:
- affects compliance with Annex I (essential cybersecurity requirements), or
- changes the intended purpose for which the product was assessed.
Why does it matter? Because if your application update, base OS swap, or hardware rev triggers this definition, you might need to go through conformity assessment again before shipping it out again.
What is a substantial modification?
- You change your fleet’s OS base image and drop security hardening configs from the original setup.
- A software update introduces a new feature that handles sensitive user data, requiring new access controls.
- A new hardware revision swaps out a networking chip with a different security posture or firmware behavior.
These changes could affect Annex I Part I points 1-3 (security by design, protection from known vulnerabilities, etc.).
What’s not substantial?
- You update a container to patch a CVE with no functional changes.
- You fix a UI bug in your dashboard app.
- You change the branding (logos, colors) but don’t touch functionality or data flows.
- You modify non-critical hardware like LEDs or mechanical casing.
In these cases, the core security posture and intended use remain unchanged, so you’re not triggering the “substantial” flag.
Grey areas?
What about tweaking a feature that’s optional but security-relevant? Or swapping cloud providers where data handling changes subtly?
If you’re unsure, document your risk assessment (as required in Art. 13.3), and consider consulting with your notified body or a CRA-savvy peer (that’s what this forum is for ;).
Would love to hear from others—what changes have you made that raised questions internally to reassess for CRA?