CRA FAQ

Manufacturers of products with digital elements shall […] in relation to the risks posed to products with digital elements, address and remediate vulnerabilities without delay, including by providing security updates (Annex I, Part II, point 2).

The CRA does not require manufacturers to provide a patch for all vulnerabilities that are discovered during a product’s support period. When discovering a vulnerability, manufacturers are expected to determine its relevance for their product, and assess the resulting risk, in the framework of the manufacturer’s risk assessment. On the basis of the risk that the vulnerability poses, manufacturers need to ensure that remedies are put in place without delay. The CRA does not therefore prescribe that manufacturers must provide a patch for all vulnerabilities that are discovered during a product’s support period.

Depending on the risk, remedies may take different forms, including but not limited to immediate patches, advisories on workarounds to be later complemented by a software updates, updates to user manuals, configuration guidance to disable the affected features.

For example, a manufacturer of a smart home hub finds a vulnerability in its product which allows remote attackers to execute arbitrary code on the hub; the manufacturer’s risk assessment shows that there is a high risk of compromise, as the attacker could control other connected devices. The manufacturer may be expected, for example, to provide an immediate patch and appropriate guidance to its users.

On the other hand, a manufacturer of a Wi-Fi router finds a buffer overflow vulnerability in one of the software libraries contained in the router’s firmware; the manufacturer’s risk assessment, however, shows that the vulnerability cannot be exploited, as the library functions are never called in the firmware. The manufacturer may be expected, for example, to document the vulnerability, but may decide not to fix it with a dedicated update. The manufacturer may also be expected, for example, to remove the unused library in its next regular firmware release.

Finally, a manufacturer of an office laser printer discovers that the printer’s motherboard has a debugging interface that remains enabled. While the vulnerability could theoretically be exploited to bypass authentication and inject malicious code, exploiting the vulnerability requires physical access to the printer, breaking its tamper-evident seal, disassembling internal components and soldering to the motherboard. The manufacturer’s risk assessment shows that the vulnerability presents a very low risk and has no exploitability in its operational environment. The manufacturer may be expected, for example, to document the vulnerability, update its technical documentation and provide appropriate recommendations to its users.

Where a manufacturer has placed subsequent substantially modified versions of a software product on the market, that manufacturer may ensure compliance with the essential cybersecurity requirement set out in Part II, point (2), of Annex I only for the version that it has last placed on the market, provided that the users of the versions that were previously placed on the market have access to the version last placed on the market free of charge and do not incur additional costs to adjust the hardware and software environment in which they use the original version of that product (Article 13.10).

Recital 40 explains in detail the provision of Article 13.10, clarifying that manufacturers are not required to address and remediate vulnerabilities for all versions of a software product, if certain criteria are met.

Specifically, “taking into account the iterative nature of software development, manufacturers that have placed subsequent versions of a software product on the market as a result of a subsequent substantial modification of that product should be able to provide security updates for the support period only for the version of the software product that they have last placed on the market. They should be able to do so only if the users of the relevant previous product versions have access to the product version last placed on the market free of charge and do not incur additional costs to adjust the hardware or software environment in which they operate the product. This could, for instance, be the case where a desktop operating system upgrade does not require new hardware, such as a faster central processing unit or more memory. Nonetheless, the manufacturer should continue to comply, for the support period, with other vulnerability-handling requirements, such as having a policy on coordinated vulnerability disclosure or measures in place to facilitate the sharing of information about potential vulnerabilities for all subsequent substantially modified versions of the software product placed on the market. Manufacturers should be able to provide minor security or functionality updates that do not constitute a substantial modification only for the latest version or sub-version of a software product that has not been substantially modified. At the same time, where a hardware product, such as a smartphone, 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 of the operating system for the support period” (Recital 40).

One of the most important measures for users to take in order to protect their products with digital elements from cyberattacks is to install the latest available security updates as soon as possible. Manufacturers should therefore design their products and put in place processes to ensure that products with digital elements include functions that enable the notification, distribution, download and installation of security updates automatically, in particular in the case of consumer products. They should also provide the possibility to approve the download and installation of the security updates as a final step. Users should retain the ability to deactivate automatic updates, with a clear and easy-to-use mechanism, supported by clear instructions on how users can opt out. The requirements relating to automatic updates as set out in an annex to this Regulation are not applicable to products with digital elements primarily intended to be integrated as components into other products. They also do not apply to products with digital elements for which users would not reasonably expect automatic updates, including products with digital elements intended to be used in professional ICT networks, and especially in critical and industrial environments where an automatic update could cause interference with operations. Irrespective of whether a product with digital elements is designed to receive automatic updates or not, its manufacturer should inform users about vulnerabilities and make security updates available without delay (Recital 56)

Products with digital elements shall be made available on the market only where: (a) they meet the essential cybersecurity requirements set out in Part I of Annex I, provided that they are properly installed, maintained, used for their intended purpose or under conditions which can reasonably be foreseen, and, where applicable, the necessary security updates have been installed; and (b) the processes put in place by the manufacturer comply with the essential cybersecurity requirements set out in Part II of Annex I (Article 6)

On the basis of the cybersecurity risk assessment referred to in Article 13(2) and where applicable, products with digital elements shall: (c) ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic security updates that are installed within an appropriate timeframe enabled as a default setting, with a clear and easy-to-use opt-out mechanism, through the notification of available updates to users, and the option to temporarily postpone them (Annex I, Part I, point (2)(c)).

Manufacturers of products with digital elements shall: (7) provide for mechanisms to securely distribute updates for products with digital elements to ensure 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)).

Manufacturers of products with digital elements shall: (8) ensure that, where security updates are available to address identified security issues, they are disseminated without delay and, unless otherwise agreed between a manufacturer and a business user in relation to a tailor-made product with digital elements, free of charge, accompanied by advisory messages providing users with the relevant information, including on potential action to be taken. (Annex I, Part II, point (8)).

The CRA establishes a series of mechanisms that require manufacturers to ensure that security updates are disseminated without delay, that such updates are installed automatically where possible, and that users of products with digital elements are kept duly informed. The CRA also recognises that automatic updates are not always applicable, and users should also have the possibility to postpone the installation of such updates.

The manufacturer is not responsible under the CRA if the user does not install security updates, e.g. where updates are not installed either because automatic updates are not applicable or because the user opts out.

From the placing on the market and for the support period, manufacturers who know or have reason to believe that the product with digital elements or the processes put in place by the manufacturer are not in conformity with the essential cybersecurity requirements set out in Annex I shall immediately take the corrective measures necessary to bring that product with digital elements or the manufacturer’s processes into conformity, or to withdraw or recall the product, as appropriate (Article 13(21)).

As explained in 4.3.1 Are manufacturers required to patch all vulnerabilities that are discovered during the support period?, the manufacturer is required, in relation to the risks posed, to address and remediate vulnerabilities during the support period. Appropriate remedies can take different forms, including mitigation measures.

In some circumstances, however, it is possible that a vulnerability that presents a very significant risk of compromise, particularly in a hardware product with digital elements, cannot be addressed and remediated adequately and the product cannot be brought back into conformity. In such cases, which are likely to be exceptional cases, the manufacturer may be required to withdraw or recall the product, as appropriate.

It is likely that, in such circumstances, the relevant market surveillance authorities are involved and that the relevant procedures laid down in Articles 54-58 of the CRA are activated.

Manufacturers of products with digital elements shall: (2) in relation to the risks posed to products with digital elements, address and remediate vulnerabilities without delay, including by providing security updates; where technically feasible, new security updates shall be provided separately from functionality updates (Annex I, Part II, point (2)).

To improve the transparency of vulnerability handling processes and to ensure that users are not required to install new functionality updates for the sole purpose of receiving the latest security updates, manufacturers should ensure, where technically feasible, that new security updates are provided separately from functionality updates (Recital 57).

The CRA establishes that manufacturers should, where technically feasible, provide new security updates separately from functionality updates, in order to ensure that updates can be delivered in a prompt manner and that users are not required to install functionality updates to be able to receive the latest security updates.

Manufacturers that release a security update to address a vulnerability are not to bundle that update with other functionality updates. For example, a smart home device has a vulnerability in the SSL certificate validation process that enables an attacker to perform a man-in-the-middle attack. To fix the vulnerability, it is sufficient for the manufacturer to update the SSL certificate validation routine. The manufacturer should deliver that update separately, without bundling the security fix with other functionality-related updates.

Nonetheless, where a functionality update is necessary to deliver a security update, the essential requirements do not prevent the manufacturer to deliver an update that combines both security and functionality modifications. For example, a PDF reader has a vulnerability that is contained in an outdated file format parser and which triggers buffer overflows. The fix requires replacing the file format parser with a new, safer parser that supports a slightly different behaviour (e.g. stricter format checking), and which may lead to some functionality changes, because some files that worked before may now be rejected. As it would not be technically feasible, the manufacturer is not required to ensure a separation between these types of software modifications.

Similarly, in certain situations, the functionality update can itself correspond to the security update. For example, a product with digital elements accesses the same feature via different interfaces (e.g. web interface, mobile app interface, command-line interface, API endpoint). If one of those interfaces contains a vulnerability, the manufacturer may determine that it is necessary to disable that vulnerable interface – thereby delivering a functionality update that is also a security update.

The vulnerability handling obligations set out in this Regulation, which manufacturers have to comply with when placing a product with digital elements on the market and for the support period, apply to products with digital elements in their entirety, including to all integrated components. Where, in the exercise of due diligence, the manufacturer of the product with digital elements identifies a vulnerability in a component, including in a free and open-source component, it should inform the person or entity manufacturing or maintaining the component, address and remediate the vulnerability, and, where applicable, provide the person or entity with the applied security fix (Recital 34).

Manufacturers need to comply with the vulnerability handling obligations for the duration of the support period, for their products in their entirety, including by handling vulnerabilities affecting their products that are contained in integrated components. See also 4.3.1 Are manufacturers required to patch all vulnerabilities that are discovered during the support period?

Where the manufacturer of a product has integrated a component that has been placed on the market after CRA applies (i.e. the component is itself a product under the CRA), that manufacturer is able to rely on the actions that the component manufacturer is required to undertake to comply with its own vulnerability handling obligations. For example, the component manufacturer may be required to develop a security update to fix a vulnerability in the component. The integrating manufacturer is still required to fulfil its vulnerability handling obligations for its product, for example by keeping users informed, providing mitigating measures, updating documentation; but its vulnerability handling obligations are facilitated by the corresponding obligations of the component manufacturer.

Where the manufacturer has integrated a component that has not been placed on the market (or that has been placed on the market before the CRA applies), the person or entity that has developed the component is not subject to the CRA vulnerability handling obligations. The integrating manufacturer is nonetheless required to ensure that its product complies in its entirety with the vulnerability handling requirements. Where the person or entity that has developed the component is not supporting the manufacturer in addressing and remediating vulnerabilities, the integrating manufacturer is expected to address the vulnerability via other means, for example by disabling compromised functions; switching out the affected component; developing by itself a patch (for example, where the component is open source component).

In accordance with Article 13(6), where the integrating manufacturer develops a patch for a component, it is required to share it with the person or entity maintaining the component.

When determining the support period, manufacturers may also take into account the support periods of products with digital elements offering a similar functionality placed on the market by other manufacturers, the availability of the operating environment, the support periods of integrated components that provide core functions and are sourced from third parties […] (Article 13.8)

Manufacturers need to comply with the vulnerability handling obligations for the duration of the support period, for their products in their entirety, including all integrated components, but are able to rely on the vulnerability handling obligations to which component manufacturers are also subject, as discussed in entry 4.3.6 How should vulnerabilities in integrated components be addressed and remediated?

The support period of integrated components is a consideration that manufacturers may take into account when determining their product’s support period, to ensure that they are able to leverage the support period of key components to address and remediate the product’s vulnerabilities. See also section 4.5 Support period.

Nonetheless, it can occur that a product with an active support period contains a vulnerability in an integrated component that is no longer covered by that component’s support period, and that vulnerability cannot be addressed and remediated adequately via various forms of mitigation measures (see also entry 4.3.1 Are manufacturers required to patch all vulnerabilities that are discovered during the support period?). In that case, the manufacturer of the product is required to remediate the vulnerability via other means, for example by switching out the integrated component or developing a patch autonomously.