Find the exact question, open the source answer card, and copy a direct link to the anchored sub-FAQ response.
Yes.
Annex I Part II point (8) requires manufacturers to ensure that available security updates are disseminated without delay.
Annex I Part II point (8) requires available security updates for identified security issues to be disseminated without delay.
Section 4.3.3 applies the dissemination requirement to the manufacturer's update-availability duties.
Yes, unless otherwise agreed between the manufacturer and a business user for a tailor-made product.
Annex I Part II point (8) requires free security updates, except agreed tailor-made business-user arrangements.
Sections 4.2.5 and 4.3.3 explain the tailor-made product exception to free security updates.
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.
Annex I Part II point (8) requires advisory messages with relevant information and potential user actions.
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.
Annex I Part II point (7) requires secure mechanisms to distribute updates and fix or mitigate vulnerabilities in a timely manner.
Section 4.3.3 explains update distribution and user-installation responsibility.
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.
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.
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.
Annex I Part I point (2)(c) requires default enablement, notification, opt-out, and temporary postponement where automatic security updates apply.
Section 4.3.3 ties opt-out and postponement controls to user responsibility for installation.
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.
Section 4.3.3 states that the manufacturer is not responsible under the CRA when a user does not install available security updates.
Annex I Part I point (2)(c) and Annex I Part II points (7)-(8) define the manufacturer's update-availability and notification duties.
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.
Article 13(21) requires corrective measures, withdrawal, or recall where the product or process is not in conformity.
Section 4.3.4 explains that withdrawal or recall may be needed in exceptional cases where serious vulnerabilities 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.
Recital 56 preserves vulnerability information and security-update availability duties even where automatic updates are not applicable.
Section 4.3.3 distinguishes automatic update applicability from the manufacturer's duty to make security updates available.
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.
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.
Article 13(10) and Annex I Part II points (5)-(8) distinguish security-update remediation from other vulnerability-handling duties.
Section 4.3.2 confirms other vulnerability-handling obligations continue during the support period.
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.
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.
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.
Recital 39 frames substantial modification around intended purpose and cybersecurity-risk effects, not release labels.
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.
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.
Point 99 says foreseen later functions covered by the original risk assessment are not substantial merely because they are activated later.
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.
Recital 39 makes the effect on intended purpose or cybersecurity risk the relevant test.
Point 100 explains that a functionality update can be substantial when it changes intended functions or increases cybersecurity risk.