EU Cyber Resilience Act FAQ Security Updates vs Functionality Updates

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.

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.

Yes, where technically feasible.

That is the rule in Annex I Part II point (2). Recital 57 explains that the purpose is to avoid forcing users to install functionality changes just to receive the latest security fix.

To improve transparency and to ensure users are not required to install new functionality updates for the sole purpose of receiving the latest security updates.

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.

Yes.

The Commission FAQ explains that disabling or changing a vulnerable function can itself be the security update. The key point is whether the change is needed to address the vulnerability.

Yes.

Annex I Part II point (8) requires manufacturers to ensure that available security updates are disseminated without delay.

Yes, unless otherwise agreed between the manufacturer and a business user for a tailor-made product.

Yes.

When security updates are available to address identified security issues, they must be accompanied by advisory messages with the relevant information, including potential action users should take.

Yes.

Manufacturers must provide mechanisms to securely distribute updates so that vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security updates, in an automatic manner.

No.

The CRA requires products, where applicable, to support automatic security updates 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.

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.

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.

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.

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 security updates available without delay.

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. That is allowed 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.

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 functionality updates that do not amount to a substantial modification may be provided only for the latest version or sub-version that has not been substantially modified.

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 security updates at least for the latest compatible version for the support period.

No.

Recital 39 and the March 2026 draft guidance say security updates 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.

No.

The March 2026 draft guidance says later functionality updates 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 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.

No.

Recital 39 says that when assessing whether a feature update is a substantial modification, 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.

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.

No.

The March 2026 draft guidance says that regardless of whether a software update qualifies as a substantial modification, 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).