EU Cyber Resilience Act FAQ Security Updates vs Functionality Updates
This CRA FAQ helps classify security updates and functionality updates, decide when separation is required, and understand how update choices affect support-period duties, user notices, automatic updates, and substantial-modification analysis.
Built for product, release, engineering, security, and compliance teams managing update governance for products with digital elements under the EU Cyber Resilience Act.
The EU Cyber Resilience Act treats as part of vulnerability handling, while are assessed by their effect on intended purpose, cybersecurity risk, documentation, and conformity. Security fixes must be separated from functionality changes where technically feasible, but the Commission FAQ explains that a combined release is permitted where the security remedy itself requires a functional change. The Regulation is binding; the Commission FAQ and March 2026 draft guidance cited below explain the Commission services' current, non-binding interpretation.
Classification matrix
CRA security updates vs functionality updates
This matrix helps classify a release without losing the CRA duties that attach to security fixes, vulnerability handling, user notices, support periods, and substantial-modification review.
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 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.
New must be provided separately from 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.
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.
do not become free 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.
Where automatic 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 and any opt-out or postponement controls where required.
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 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.
A security update is generally not a 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.
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.
Some releases are both and , especially when a functional change is the only practical way to remove the vulnerability.
Other releases are primarily 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.
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 .
Start with the dominant purpose of the release, then document any secondary CRA consequences instead of forcing everything into one label.
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 where appropriate.
Functionality update
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.
Operational implication
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.
New must be provided separately from where technically feasible, so users do not have to accept unrelated feature changes to receive security fixes.
Functionality update
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.
Operational implication
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.
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 update
do not become free just because they ship in the same release, but any user information, technical documentation, and conformity impacts still need to stay accurate.
Operational implication
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.
Where automatic are applicable, they must be enabled by default within an appropriate timeframe, with user notification, a clear opt-out, and temporary postponement.
Functionality update
The CRA does not require automatic installation for every feature update, and recital 56 recognises product contexts where automatic updates are not reasonably expected.
Operational implication
Separate "can be delivered over the air" from "must install automatically." Update UI and instructions should show users available and any opt-out or postponement controls where required.
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.
Functionality update
Minor security or 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.
Operational implication
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.
A security update is generally not a when it only reduces cybersecurity risk and does not change intended purpose or introduce new cybersecurity risks.
Functionality update
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.
Operational implication
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.
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 update
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.
Operational implication
Treat vulnerability handling and substantial-modification review as separate checks. A release can satisfy one and still fail the other.
Some releases are both and , especially when a functional change is the only practical way to remove the vulnerability.
Functionality update
Other releases are primarily that only become security-relevant because the change alters attack surface, dependencies, or the product's intended purpose.
Operational implication
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.
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.
Functionality update
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 .
Operational implication
Start with the dominant purpose of the release, then document any secondary CRA consequences instead of forcing everything into one label.
Identify the security driver: vulnerability, exploitable weakness, dependency issue, configuration defect, or other cybersecurity risk.
Identify the functionality effect: changed feature, interface, dependency, data flow, performance characteristic, operating environment, or intended use.
If the release contains both, document whether separate delivery is technically feasible and whether the functional change is necessary to remediate the vulnerability.
Check user obligations separately: advisory message, free security update treatment, automatic-update controls where applicable, opt-out or postponement, and update availability without delay.
Check lifecycle obligations separately: support-period coverage, Article 13(10) latest-version conditions, latest-compatible-version support for affected hardware, and updated risk assessment or technical documentation.
Does the CRA require manufacturers to patch every vulnerability they discover during the support period?
No.
The CRA requires manufacturers to address and remediate vulnerabilities without delay in relation to the risks posed. The Commission FAQ explains that this does not mean every vulnerability must receive a dedicated patch. The response depends on the risk assessment.
Section 4.3.1 confirms the CRA does not require a patch for every discovered vulnerability.
Question 2
If not every vulnerability needs a dedicated patch, what other remedies can satisfy the CRA?
The Commission FAQ says remedies can take different forms depending on the risk. These can include immediate patches, advisories on workarounds, configuration guidance, updates to user manuals, later software updates, or other mitigation measures.
Annex I Part II point (2) and Article 13(21) support remediation, corrective measures, withdrawal, or recall depending on risk and conformity.
Question 3
Must security updates be provided separately from functionality updates?
Yes, where technically feasible.
Annex I Part II point (2) sets this rule. Recital 57 explains that the purpose is to avoid forcing users to install functionality changes just to receive the latest security fix.
Section 4.3.5 explains how to apply the separation rule when a fix also affects functionality.
CRA update governance
Check the release record before shipping a CRA update
For each release, keep the vulnerability-risk assessment, separation rationale, user advisory text, update-distribution evidence, and substantial-modification assessment together so product and security teams can explain why the update was classified as security, functionality, or both.
Section 4.3.5 connects update separation with prompt delivery of security fixes.
Question 5
Can a manufacturer still combine a security update with a functionality change?
Yes, if separation is not technically feasible.
The Commission FAQ gives the example of a vulnerability fix that requires replacing a parser with a safer one that changes some functionality. In that situation, the CRA does not require strict separation.
Annex I Part II point (2) qualifies separation with the words "where technically feasible."
Question 6
Under the CRA, can a functionality change itself be the security fix?
Yes.
The Commission FAQ explains that disabling or changing a vulnerable function can itself be the security update when the change is needed to address the vulnerability.
Sections 4.2.5 and 4.3.3 explain the tailor-made product exception to free security updates.
Question 9
Must CRA security updates come with user-facing guidance?
Yes.
When are available to address identified security issues, they must be accompanied by advisory messages with the relevant information, including potential action users should take.
Annex I Part II point (8) requires advisory messages with relevant information and potential user actions.
Question 10
Does the CRA require secure update-distribution mechanisms?
Yes.
Manufacturers must provide mechanisms to securely distribute updates so that vulnerabilities are fixed or mitigated in a timely manner and, where applicable for , in an automatic manner.
Section 4.3.3 explains update distribution and user-installation responsibility.
Question 11
Are CRA automatic security updates always required for every product?
No.
The CRA requires products, where applicable, to support automatic with default enablement, an opt-out mechanism, notifications, and the option to postpone. Recital 56 and the Commission FAQ explain that automatic updates are not always applicable, especially for components and for products where users would not reasonably expect automatic updates, including some professional and industrial environments.
Annex I Part I point (2)(c) requires automatic security updates only where applicable; recital 56 explains product categories where users may not expect them.
Section 4.3.3 confirms automatic updates are not applicable for every product context.
Question 12
If CRA automatic updates are used, must users still be able to opt out or postpone installation?
Yes.
Annex I Part I point (2)(c) requires a clear and easy-to-use opt-out mechanism and the option to temporarily postpone updates. Recital 56 adds that users should retain the ability to deactivate automatic updates.
Section 4.3.3 ties opt-out and postponement controls to user responsibility for installation.
Question 13
Under the Cyber Resilience Act, is the manufacturer responsible if a user refuses or fails to install a security update?
No.
The Commission FAQ states this directly. The manufacturer must make the update available through the required mechanisms and keep users informed, but is not responsible under the CRA if the user does not install the update.
Annex I Part I point (2)(c) and Annex I Part II points (7)-(8) define the manufacturer's update-availability and notification duties.
Question 14
Under the CRA, if a vulnerability cannot be fixed adequately, can withdrawal or recall become necessary?
Yes, in exceptional cases.
Article 13(21) requires corrective measures to bring the product or the manufacturer's processes into conformity, or withdrawal or recall as appropriate. The Commission FAQ explains that this may become necessary where a serious vulnerability cannot be adequately remediated.
Section 4.3.4 explains that withdrawal or recall may be needed in exceptional cases where serious vulnerabilities cannot be adequately remediated.
Question 15
Even when CRA automatic updates are not applicable, must the manufacturer still inform users about vulnerabilities and make security updates available?
Yes.
Recital 56 states this expressly. Even where a product is not designed to receive automatic updates, the manufacturer should still inform users about vulnerabilities and make available without delay.
Section 4.3.3 distinguishes automatic update applicability from the manufacturer's duty to make security updates available.
Question 16
Under the Cyber Resilience Act, must a manufacturer keep delivering security fixes for every historical version of a software product?
Not always.
Article 13(10) allows the manufacturer, under specific conditions, to ensure compliance with the remediation obligation only for the latest substantially modified version it has placed on the market. The manufacturer may do so only if users of the earlier versions can access that latest version free of charge and without additional costs to adjust their hardware or software environment.
Article 13(10) and recital 40 allow remediation for the latest substantially modified software version only when earlier-version users can move free of charge and without additional environment costs.
Section 4.3.2 explains the Article 13(10) limit for previous software versions.
Question 17
Under the CRA, if earlier versions can move to the latest substantially modified version, does that end all obligations for the older versions?
No.
Recital 40 says the manufacturer may limit remediation to the latest substantially modified version only under the Article 13(10) conditions, but other vulnerability-handling obligations still continue for all subsequent substantially modified versions placed on the market. The same recital also says minor security or that do not amount to a may be provided only for the latest version or sub-version that has not been substantially modified.
Section 4.3.2 confirms other vulnerability-handling obligations continue during the support period.
Question 18
Under the Cyber Resilience Act, what if a hardware product cannot run the latest software version?
The CRA does not let the manufacturer stop there.
Recital 40 says that where a hardware product is not compatible with the latest version of the operating system it was originally delivered with, the manufacturer should continue to provide at least for the latest compatible version for the support period.
Recital 40 says incompatible hardware should continue receiving security updates for at least the latest compatible operating-system version during the support period.
Section 4.3.2 repeats the latest-compatible-version support rule for hardware that cannot run the newest software.
Question 19
Under the CRA, if a release is labelled a security update, does that automatically mean it is not a substantial modification?
No.
Recital 39 and the March 2026 draft guidance say are generally not substantial modifications when they only reduce cybersecurity risk, do not change the product's intended purpose, and do not introduce new cybersecurity risks. But a security-driven change can still be substantial if it changes the intended purpose beyond what was originally foreseen or introduces new interfaces, dependencies, data flows, or other risks that were not covered in the original risk assessment.
Points 101-102 say risk-reducing security updates are generally not substantial modifications, but security-driven changes can still be substantial if they alter purpose or add risks.
Question 20
Under the Cyber Resilience Act, are later functionality updates automatically substantial modifications?
No.
The March 2026 draft guidance says later are not substantial modifications just because they add or activate features. If the original risk assessment already foresaw those later functions, already assessed their risks, and already accounted for the needed mitigation measures, the later rollout should not be treated as a .
Point 99 says foreseen later functions covered by the original risk assessment are not substantial merely because they are activated later.
Question 21
Under the CRA, can a small-looking feature update still become a substantial modification?
Yes.
Recital 39 and the March 2026 draft guidance both make clear that the scale of the feature is not the legal test. Even a limited update can be substantial if it modifies the original intended functions or type or performance of the product in a way that increases cybersecurity risk, or if it introduces new or increased risks that were not covered in the original risk assessment.
Point 100 explains that a functionality update can be substantial when it changes intended functions or increases cybersecurity risk.
Question 22
Under the Cyber Resilience Act, does it matter for substantial-modification analysis whether the feature change was shipped separately or bundled with a security update?
No.
Recital 39 says that when assessing whether a feature update is a , it is not relevant whether the feature update is provided separately or in combination with a security update. What matters is the effect on intended purpose and cybersecurity risk, not the packaging of the release.
Recital 39 says the packaging of a feature update with a security update is not the substantial-modification test.
Question 23
When Article 13(10) says users must not incur additional costs to move to the latest version, what does that cover?
The March 2026 draft guidance says this should be interpreted practically and proportionately.
Reasonable operational effort does not itself count as additional costs. The guidance gives examples such as personnel time, routine testing, configuration adjustments, and upgrades of underlying software dependencies that are necessary to address end-of-life components or known vulnerabilities. By contrast, additional costs mean burdens going beyond normal software maintenance, such as mandatory purchases of new hardware, infrastructure replacement, or fundamental changes to the operating environment.
Points 118-120 distinguish reasonable operational effort from additional costs such as mandatory hardware or infrastructure replacement.
Question 24
If an update is not a substantial modification, can the manufacturer leave the CRA documentation unchanged?
No.
The March 2026 draft guidance says that regardless of whether a software update qualifies as a , manufacturers remain responsible for the security of the update and of the product during the support period. It also says the cybersecurity risk assessment and technical documentation must remain accurate, complete, and continuously up to date. That aligns with Articles 13(7) and 31(2).
Point 106 says manufacturers remain responsible for update security and current documentation during the support period.
Question 25
What should a mixed security-and-functionality release record show?
Record which changes remediate identified security issues, which changes add or alter functionality, and why separating them was or was not technically feasible. The record should link the release to the vulnerability assessment, affected versions and components, user advisory, update-distribution evidence, tests, and the updated cybersecurity risk assessment and technical documentation.
Run the substantial-modification test on the release's actual effects, not its label or packaging. If the functional part changes intended purpose or introduces cybersecurity risks that the original assessment did not cover, the manufacturer may need a new conformity assessment before placing the substantially modified version on the market. This record is practical evidence, not an official CRA form.
Articles 13(7) and 31(2), Recital 39, and Annex I Part II points 2, 7, and 8 support current risk and technical records, separate security updates where technically feasible, secure distribution, and user advisories.