EU Cyber Resilience Act FAQ Security Updates vs Functionality Updates
This CRA FAQ helps classify and , 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 July 2026 Commission 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.
Annex I Part II point (2) and recital 57 require separation where technically feasible and explain why users should not be forced into feature 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.
The CRA sets no general free-of-charge rule for unrelated feature work. A functionality change that is necessary to deliver a security remedy remains part of the security-update obligation, including free provision unless the qualifying tailor-made business-user exception applies.
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.
Annex I Part I point (2)(c) and recital 56 support default automatic security updates where applicable and the opt-out, notification, and postponement controls.
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.
Article 13(21), Annex I Part II point (8), and recital 41 support corrective action for security failures and reassessment after substantial modification.
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.
Points 103–113 support release-by-release analysis of functionality changes, security fixes, and documentation updates.
Scope boundary
Security update
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.
Points 103–109 explain when later software functionality and security changes are or are not substantial modifications.
Separation of changes
Security update
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.
Annex I Part II point (2) and recital 57 require separation where technically feasible and explain why users should not be forced into feature updates.
Section 4.3.5 explains combined security and functionality updates when separation is not technically feasible.
Distribution, cost, and advice
Security update
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
The CRA sets no general free-of-charge rule for unrelated feature work. A functionality change that is necessary to deliver a security remedy remains part of the security-update obligation, including free provision unless the qualifying tailor-made business-user exception applies.
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.
Sections 4.2.5 and 4.3.3 explain free security updates and user-installation responsibility.
Automatic update controls
Security update
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.
Annex I Part I point (2)(c) and recital 56 support default automatic security updates where applicable and the opt-out, notification, and postponement controls.
Section 4.3.3 confirms the manufacturer is not responsible under the CRA if a user does not install available security updates.
Support for earlier versions
Security update
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.
Points 129–131 explain what counts as additional costs for moving to the latest version.
Substantial-modification review
Security update
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.
Points 104–113 explain security updates, functionality updates, changed risk, and current documentation duties.
Enforcement
Security update
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.
Article 13(21), Annex I Part II point (8), and recital 41 support corrective action for security failures and reassessment after substantial modification.
Section 4.3.4 explains withdrawal or recall, while section 4.3.5 covers combined security and functionality updates.
Overlap and reuse
Security update
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.
Section 4.3.5 explains when a security fix and functionality change are combined or overlap.
Practical decision rule
Security update
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.
Points 103–113 support release-by-release analysis of functionality changes, security fixes, and documentation updates.
Practical decision rule
How to classify a CRA update release
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.
Sections 4.3 and 5, points 103–113 and 129–131 support functionality-update and additional-cost analysis.
Search this module
Find a question or answer quickly
25 of 25 questions
Question 1
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 July 2026 Commission 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.
Commission guidance sections 2, 4, 5, 7 and 8 provide the non-binding interpretation relevant to this answer; apply the product-specific conditions described above.
Question 20
Under the Cyber Resilience Act, are later functionality updates automatically substantial modifications?
No.
The July 2026 Commission 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 .
Commission guidance sections 2, 4, 5, 7 and 8 provide the non-binding interpretation relevant to this answer; apply the product-specific conditions described above.
Question 21
Under the CRA, can a small-looking feature update still become a substantial modification?
Yes.
Recital 39 and the July 2026 Commission 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.
Commission guidance sections 2, 4, 5, 7 and 8 provide the non-binding interpretation relevant to this answer; apply the product-specific conditions described above.
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 July 2026 Commission 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.
Commission guidance sections 2, 4, 5, 7 and 8 provide the non-binding interpretation relevant to this answer; apply the product-specific conditions described above.
Question 24
If an update is not a substantial modification, can the manufacturer leave the CRA documentation unchanged?
No.
The July 2026 Commission 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).
Commission guidance sections 2, 4, 5, 7 and 8 provide the non-binding interpretation relevant to this answer; apply the product-specific conditions described above.
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.
Commission guidance sections 2, 4, 5, 7 and 8 provide the non-binding interpretation relevant to this answer; apply the product-specific conditions described above.
Official Cyber Resilience Act legal text supporting this FAQ and its article-level compliance conclusions.
Annex I Part II point (2) requires risk-based vulnerability remediation without delay, including security updates where needed.
Annex I Part II point (2) and Article 13(21) support remediation, corrective measures, withdrawal, or recall depending on risk and conformity.
Show 31 more
Annex I Part II point (2) sets the separate-security-update rule where technically feasible; recital 57 explains the user-protection purpose.
Recital 57 explains that separation improves transparency and avoids forcing feature updates just to receive security fixes.
Annex I Part II point (2) qualifies separation with the words "where technically feasible."
Annex I Part II point (8) requires available security updates for identified security issues to be disseminated without delay.
Annex I Part II point (8) requires free security updates, except agreed tailor-made business-user arrangements.
Annex I Part II point (8) requires advisory messages with relevant information and potential user actions.
Annex I Part II point (7) requires secure mechanisms to distribute updates and fix or mitigate vulnerabilities in a timely manner.
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.
Annex I Part I point (2)(c) requires default enablement, notification, opt-out, and temporary postponement where automatic security updates apply.
Annex I Part I point (2)(c) and Annex I Part II points (7)-(8) define the manufacturer's update-availability and notification duties.
Article 13(21) requires corrective measures, withdrawal, or recall where the product or process is not in conformity.
Recital 56 preserves vulnerability information and security-update availability duties even where automatic updates are not applicable.
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.
Article 13(10) and Annex I Part II points (5)-(8) distinguish security-update remediation from other vulnerability-handling duties.
Recital 40 says incompatible hardware should continue receiving security updates for at least the latest compatible operating-system version during the support period.
Recital 39 frames substantial modification around intended purpose and cybersecurity-risk effects, not release labels.
Recital 39 makes the effect on intended purpose or cybersecurity risk the relevant test.
Recital 39 says the packaging of a feature update with a security update is not the substantial-modification test.
Article 13(10) sets the free-access and no-additional-environment-cost condition for limiting remediation to the latest software version.
Articles 13(7) and 31(2) require ongoing security, risk-assessment, and technical-documentation maintenance.
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.
Annex I Part II point (2) supports the security-update trigger; recital 39 supports the substantial-modification test for feature changes.
Annex I Part II point (2) and recital 57 require separation where technically feasible and explain why users should not be forced into feature updates.
Annex I Part II point (8) supports without-delay dissemination, free security updates, and advisory messages.
Annex I Part I point (2)(c) and recital 56 support default automatic security updates where applicable and the opt-out, notification, and postponement controls.
Article 13(10) and recital 40 support the latest-version rule, the no-additional-cost condition, and the latest-compatible-version rule for hardware.
Recital 39 supports the substantial-modification test; Articles 13(7) and 31(2) support ongoing security and documentation maintenance.
Article 13(21), Annex I Part II point (8), and recital 41 support corrective action for security failures and reassessment after substantial modification.
Recital 39 and Annex I Part II point (2) show that a release may have both security and functionality aspects.
Recital 39 and Article 13(21) support distinguishing risk-reducing security changes from changes that affect intended purpose or conformity.
Annex I Part I point (2)(c), Annex I Part II points (2), (7), and (8), Article 13(10), and recital 39 support the classification checks.
Commission guidance sections 2, 4, 5, 7 and 8 provide the non-binding interpretation relevant to this answer; apply the product-specific conditions described above.
Points 103–109 explain when later software functionality and security changes are or are not substantial modifications.
Points 129–131 explain what counts as additional costs for moving to the latest version.
Show 3 more
Points 104–113 explain security updates, functionality updates, changed risk, and current documentation duties.
Points 103–113 support release-by-release analysis of functionality changes, security fixes, and documentation updates.
Sections 4.3 and 5, points 103–113 and 129–131 support functionality-update and additional-cost analysis.