Search every question across sub-FAQs

Automatic security updates are a separate but closely related Annex I requirement. Where applicable, vulnerabilities must be addressable through security updates, including automatic security updates installed within an appropriate timeframe and enabled as a default setting.

That default must come with notification of available updates, a clear and easy-to-use opt-out mechanism, and the option to temporarily postpone updates. Annex II also requires instructions on how the default automatic-installation setting can be turned off.

No. Recital 56 recognises that automatic updates are not appropriate for every product. It says automatic-update expectations do not apply to products primarily intended to be integrated as components into other products, and do not apply where users would not reasonably expect automatic updates, including products intended for use in professional ICT networks and especially critical or industrial environments where automatic updates could interfere with operations.

That does not remove vulnerability-handling duties. Regardless of whether the product receives automatic updates, the manufacturer should inform users about vulnerabilities and make security updates available without delay.

No. The Commission FAQ states that the manufacturer is not responsible under the CRA if the user does not install security updates, including where the user opts out. But the manufacturer still needs compliant update mechanisms, vulnerability handling, advisory messages, user notifications, and instructions.

The product and process design should therefore make the secure path the default while preserving the CRA-required user choice to opt out or temporarily postpone automatic update installation where automatic updates apply.

When a manufacturer places a component on the market separately for integration into another product, the secure-by-default obligation applies to the component as placed on the market. The component manufacturer is not responsible for later configuration or deployment choices made by the integrating manufacturer.

This distinction does not make the default irrelevant. The Commission FAQ uses cryptographic libraries and microcontrollers as examples where the component's own delivery configuration may need secure defaults, while the downstream integrator may later enable or change settings for the integrated product's intended purpose.

Yes, but only with a clear, documented justification. Article 13(4) requires the manufacturer to include the cybersecurity risk assessment in the technical documentation and, where a requirement is not applicable, to include a clear justification.

The Commission FAQ gives two examples: the requirement may be incompatible with the product's nature, or the risk assessment may show no relevant risks requiring mitigation for that requirement. If related cybersecurity risks still exist, the manufacturer should treat them by other means, such as limiting the intended purpose to trusted environments or informing users about the risks.

The tailor-made exception is narrow. Recital 64 and Annex I allow deviation from secure-by-default configuration only for tailor-made products fitted to a particular purpose for a particular business user, where the manufacturer and that business user explicitly agree to different contractual terms.

The Commission FAQ says this may cover custom-developed hardware or software for a specific business user, or products developed for integration into a specific customer's highly controlled environment. It does not cover ordinary enterprise products, minor customisations, CRM platforms sold to multiple businesses, or platforms that remain fundamentally the same product while being customised through plugins or APIs.

No. The Commission FAQ states that the tailor-made deviation concerns two requirements: secure-by-default configuration in Annex I Part I point (2)(b), and free-of-charge security updates in Annex I Part II point (8). It is not a general waiver from Annex I, vulnerability handling, risk assessment, technical documentation, user information, or conformity obligations.

A manufacturer relying on the exception should keep evidence that the product is genuinely fitted to a particular purpose for a particular business user, that different contractual terms were explicitly agreed, and that the remaining applicable CRA requirements are still addressed.

Keep the risk assessment showing which Annex I Part I product-property requirements apply, the threat model and assumptions for intended purpose and reasonably foreseeable use, the default configuration inventory, the rationale for enabled and disabled services or interfaces, authentication and access-control defaults, update-default behavior, logging and monitoring defaults, and data minimisation decisions.

The technical documentation should also include user information and instructions, the design and architecture information needed to assess conformity, descriptions of vulnerability handling and secure update distribution, descriptions of solutions adopted to meet Annex I where harmonised standards or common specifications were not applied, and reports of tests verifying conformity.

The secure-by-default requirement includes the possibility to reset the product to its original state. The CRA does not prescribe one universal reset design, so the implementation must fit the product and its cybersecurity risk assessment.

The reset path should restore the assessed original configuration without creating a new insecure state. Manufacturers should document what the reset changes, how credentials, keys, logs, user data, network settings, and update settings are handled, and how the reset relates to the separate Annex I requirement for users to remove data and settings securely and permanently.

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.

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.

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 when the change is needed to address the vulnerability.