| Scope boundary | Triggered by a vulnerability or security issue. The CRA requires manufacturers to address and remediate vulnerabilities without delay in relation to the risks posed, including by security updates where appropriate. | Triggered by a functional or product change. The key CRA question is whether the change was already covered by the original intended purpose, cybersecurity risk assessment, and mitigation measures. | Do not classify by release label alone. Start with the reason for the change, then test whether the release also changes intended purpose or introduces new cybersecurity risks. |
|---|
|
| Covered actors | New security updates must be provided separately from functionality updates where technically feasible, so users do not have to accept unrelated feature changes to receive security fixes. | A functionality change can be bundled with a security update only when strict separation is not technically feasible or the functionality change is itself the way the vulnerability is remediated. | Record the technical feasibility analysis for every bundled release: what was security-driven, what changed functionality, and why separate delivery was or was not feasible. |
|---|
|
| Trigger | Security updates for identified security issues must be disseminated without delay, free of charge except agreed tailor-made business-user cases, and accompanied by advisory messages with relevant user action. | Functionality updates do not become free security updates just because they ship in the same release, but any user information, technical documentation, and conformity impacts still need to stay accurate. | Keep security advisory text, publication timing, update availability, free-charge treatment, and any user-facing functional release notes distinct enough for users to understand what they are installing. |
|---|
|
| Core obligations | Where automatic security updates are applicable, they must be enabled by default within an appropriate timeframe, with user notification, a clear opt-out, and temporary postponement. | The CRA does not require automatic installation for every feature update, and recital 56 recognises product contexts where automatic updates are not reasonably expected. | Separate "can be delivered over the air" from "must install automatically." Update UI and instructions should show users available security updates and any opt-out or postponement controls where required. |
|---|
|
| Evidence record | Article 13(10) can allow remediation for only the latest substantially modified software version, but only if earlier-version users can access it free of charge and without additional hardware or software environment costs. | Minor security or functionality updates that are not substantial modifications may be provided only for the latest version or sub-version that has not been substantially modified, while hardware unable to run the newest software still needs latest-compatible-version security support during the support period. | Before ending security fixes for an older line, verify that users can actually move to the latest substantially modified version without additional environment costs; otherwise keep the support-period analysis open. |
|---|
|
| Timing and deadlines | A security update is generally not a substantial modification when it only reduces cybersecurity risk and does not change intended purpose or introduce new cybersecurity risks. | A functionality update can be substantial if it changes intended purpose or increases cybersecurity risk outside the original risk assessment, even if the feature looks small. | Keep the risk assessment and technical documentation updated for both categories; non-substantial updates still need accurate documentation and evidence that the product remains secure during the support period. |
|---|
|
| Enforcement | Security-update failures can trigger immediate corrective action, free update duties, user notices, and in serious cases withdrawal or recall if the vulnerability cannot be remediated. | Functionality changes are handled through the substantial-modification test: if the change alters intended purpose or compliance, the new version may need fresh conformity assessment before it is placed on the market. | Treat vulnerability handling and substantial-modification review as separate checks. A release can satisfy one and still fail the other. |
|---|
|
| Overlap and reuse | Some releases are both security updates and functionality updates, especially when a functional change is the only practical way to remove the vulnerability. | Other releases are primarily functionality updates that only become security-relevant because the change alters attack surface, dependencies, or the product's intended purpose. | Use the same release notes, but split the analysis: one part for vulnerability remediation, one part for functional impact, and one part for substantial-modification consequences. |
|---|
|
| Practical decision rule | If the release is only there to reduce risk and does not alter intended purpose, classify it as a security update first and then check whether any bundled feature change needs separate analysis. | If the release adds or changes features, classify the functional effect first and then check whether the change also qualifies as a security update or a substantial modification. | Start with the dominant purpose of the release, then document any secondary CRA consequences instead of forcing everything into one label. |
|---|
|