FAQ 4.1.1
What does the CRA require of the manufacturer’s cybersecurity risk assessment?
Union harmonisation legislation related to products made available on the internal market and based on the New Legislative Framework (NLF)5 typically requires manufacturers to carry out a risk assessment, on the basis of which they need to implement the relevant essential requirements defined in the relevant legislation (see for instance section 4.1.1 of the Blue Guide). Those risk assessments are important documentation for the manufacturers to demonstrate (i.e. to market surveillance authorities) that they have implemented adequate requirements. Manufacturers may carry out a single risk assessment covering the needs of different legislations, or they may carry out individual risk assessments for each legislation separately. While it is up to the manufacturer to structure their risk assessment activities, they must be in a position to demonstrate compliance with each individual legislation. In accordance with the definition of product with digital elements (Article 3(1)), the manufacturer’s cybersecurity risk assessment needs to cover the entire product with digital elements, including remote data processing when in scope and any supporting functions that may form part of the product with digital elements to be placed on the market. Article 13(2) requires manufacturers to undertake an assessment of the cybersecurity risks associated with a product with digital elements and take the outcome of that assessment into account during the planning, design, development, production, delivery and maintenance phases of the product with digital elements with a view to minimising cybersecurity risks, preventing incidents and minimising their impact, including in relation to the health and safety of users. Thus, it is important to note that the cybersecurity risk assessment covers not only the initial stages of risk identification, risk analysis and risk evaluation during the design and development phases, but also the risk treatment measures implemented through the production, delivery and maintenance phases. Furthermore, this obligation applies to manufacturers of all products with digital elements within the meaning of the CRA, irrespective of whether the product with digital elements is in the “default category”, an important or a critical product. The New Legislative Framework consists of Regulation (EC) 765/2008 setting out the requirements for accreditation and the market surveillance of products; Decision 768/2008 on a common framework for the marketing of products; and Regulation (EU) 2019/1020 on market surveillance and compliance of products. In accordance with Article 13(3), the cybersecurity risk assessment shall indicate whether and, if so in what manner, the security requirements relating to the properties of products (set out in Part I, point (2), of Annex I) are applicable to the relevant product with digital elements, and how those requirements are implemented as informed by the cybersecurity risk assessment. It shall also indicate how the manufacturer has planned, designed, developed, produced, delivered and maintained the product with digital elements in such a way that they ensure an appropriate level of cybersecurity based on the risks (Part I, point (1), of Annex I) and the vulnerability handling requirements (set out in Part II of Annex I).
FAQ 4.1.2
Does the CRA mandate a specific risk assessment methodology?
The CRA does not mandate a specific cybersecurity risk assessment methodology. The manufacturers can decide on the methodology they use to identify and treat the relevant risks. Manufacturers need to address all relevant risks emerging from the cybersecurity risk assessment, and the risk assessment methodology should therefore support manufacturers in documenting that this has been done (in accordance with Article 13(3)), allowing market surveillance authorities to verify how risks have been identified, evaluated and mitigated. When modelling threat scenarios, manufacturers should ensure the use of a threat modelling methodology that appropriately reflects the threats and resulting risks associated to the product’s intended purpose and reasonably foreseeable use. For instance, whereas products intended for use in critical infrastructure may be required to treat risks related to nation-state actors and advanced persistent threats, products intended for private consumer use typically have a lower risk profile and may use a different threat model. In this way, manufacturers can cover all relevant risks to a product in their risk assessment.
FAQ 4.1.3
Does a manufacturer need to implement all the essential requirements?
Manufacturers need to comply with all essential cybersecurity requirements related to vulnerability handling (set out in Part II of Annex I) throughout the product’s support period. However, with regards to essential cybersecurity requirements related to the product properties (set out in Part I of Annex I), manufacturers need to determine on the basis of the cybersecurity risk assessment which of those requirements are relevant for the type of product with digital elements concerned. In accordance with Article 13(4), where certain essential cybersecurity requirements are not applicable to a product with digital elements, the manufacturer should include a clear justification in the cybersecurity risk assessment included in the technical documentation. This could be the case where an essential cybersecurity requirement is incompatible with the nature of a product with digital elements (see recital 55), or where no risks exist that require a mitigation in relation to that essential requirement. For example, a product might not need to incorporate any specific mitigation measures related to the protection of personal data if the product’s intended purpose and reasonably foreseeable use do not include the processing of any kind of personal data. In such cases, the product might still have the technical capability to process some kinds of personal data, but such use would not be included in the intended purpose and reasonably foreseeable use declared by the manufacturer. Where the product’s technical capability to process personal data may lead to significant cybersecurity risks in the case of reasonably foreseeable misuse, the information and instructions to the user may need to include this information, in accordance with point 5 of Annex II of the CRA. For example, as stated in recital 55, the intended purpose of a product with digital elements may require the manufacturer to follow widely recognised interoperability standards even if its security features are no longer considered to be state of the art. Similarly, other Union law requires manufacturers to apply specific interoperability requirements. Where this is the case, having the effect that an essential cybersecurity requirement is not applicable to a product with digital elements, but the manufacturer has identified cybersecurity risks in relation to that essential cybersecurity requirement, it should take measures to address those risks by other means, for instance by limiting the intended purpose of the product to trusted environments and/or by informing the users about those risks.
FAQ 4.1.4
What are intended purpose and reasonably foreseeable use, and how do they affect the cybersecurity risk assessment?
In accordance with Article 13(2), the assessment of cybersecurity risks shall be carried out with a view to minimising such risks, preventing incidents and minimising their impact, including in relation to the health and safety of users. Furthermore, Article 13(3) clarifies that the analysis of cybersecurity risks shall consider at least the intended purpose and reasonably foreseeable use, as well as the conditions of use of the product with digital elements, such as the operational environment or the assets to be protected, taking into account the length of time the product is expected to be in use. As an example, manufacturers of hardware or software components used by many other products downstream may consider when the intended purpose and reasonably foreseeable use includes integration of those components. In those cases, the manufacturer must ensure relevant risks are duly treated (Article 13(1) and (2)), and communicate to the users clear, understandable, intelligible and legible instructions that allow for the secure installation, operation and use of the product with digital elements (as per Article 13(8)). Article 3(23) defines ‘intended purpose’ as the use for which a product with digital elements is intended by the manufacturer, including the specific context and conditions of use, as specified in the information supplied by the manufacturer in the instructions for use, promotional or sales materials and statements, as well as in the technical documentation. Furthermore, ‘reasonably foreseeable use’ is defined in Article 3(24) as use that is not necessarily the intended purpose supplied by the manufacturer in the instructions for use, promotional or sales materials and statements, as well as in the technical documentation, but which is likely to result from reasonably foreseeable human behaviour or technical operations or interactions. Where relevant to the intended purpose and reasonably foreseeable use, the manufacturer should also consider how downstream integration and end-use can affect the cybersecurity risk assessment (i.e. the specific context and conditions of use). Furthermore, manufacturers should inform their users, be they integrators, professional owners, or operators, consumers or others, through the information and instructions to the user about any assumptions or requirements that are needed for the secure installation, operation and use of the product with digital elements, in accordance with Article 13(18). As stated in section 2.8 of the Blue Guide, manufacturers have to consider the conditions of use which can be reasonably foreseen prior to placing a product on the market, notably when such use could result from lawful and readily predictable human behaviour. This means manufacturers have to look beyond what they consider the intended use of a product and place themselves in the position of the average user of a particular product and envisage in what way they would reasonably consider using the product. For instance, as stated in section 3.1 of the Blue Guide, a tool designed and intended to be used by professionals only (such as an industrial IoT sensor or virtual private network), might eventually also be used by non-professionals; consequently, the design and instructions accompanied must take this possibility into account. Similarly, information necessary for the secure installation should still be provided in a way which is clear, understandable, intelligible and legible given the intended audience who is expected to carry out the installation, in accordance with Article 13(18). If the product can be easily accessible and is likely to be used by consumers, the manufacturer should consider the needs and risks of those consumers, such as through appropriate information and instructions to the users, including instructions for the secure installation, operation and use of the product with digital elements). However, as set out in section 2.8 of the Blue Guide, not all risks can be prevented by product design, so intended or foreseeable deployment conditions should also be considered. Where relevant, the cybersecurity risk assessment should take into account other measures that may be put in place by intended or foreseeable category of user (e.g. professional). For instance, the supervision and assistance of the intended users should be considered as part of the conditions which can be reasonably foreseen for products to be installed and used within certain professional settings, such as an industrial plant. As another example, some professional machine tools are intended for use by averagely skilled and trained workers under the supervision of their employer; the responsibility of the manufacturer cannot be engaged if such machine tools are rented by a distributor or third-party service-provider for use by unskilled and untrained consumers. Furthermore, it may in some cases be reasonable for the manufacturer to allow through the design of the product that the user can alter the product’s configurations, removing security functionality or downgrading security measures to ensure legacy compatibility. In such cases, the manufacturer should include the relevant cybersecurity risks in their cybersecurity risk assessment, implement specific treatment measures covering those risks, and accompany those usage possibilities with appropriate information and instructions to the user to ensure secure deployment and that required security outcomes can be achieved. In addition, where this circumstance may lead to significant cybersecurity risks, the manufacturer should explicitly mention those risks in accordance with point 5 of Annex II of the CRA.
FAQ 4.1.5
What is reasonably foreseeable misuse, and how does it affect the cybersecurity risk assessment?
In accordance with Article 13(18), the manufacturer should provide information to the users regarding the expected conditions for secure deployment and integration of the product. On their part, user should take into consideration the lawful conditions of use of the product defined by the manufacturer, provided these are reasonable and appropriate to the intended purpose and reasonably foreseeable use, in particular where low-skilled or vulnerable users are concerned. Article 3(24) defines ‘reasonably foreseeable misuse’ as the use of a product with digital elements in a way that is not in accordance with its intended purpose, but which may result from reasonably foreseeable human behaviour or interaction with other systems. For instance, if the information and instructions to the user mentions that the product must be deployed on a secure network, deploying it on an insecure network might constitute a reasonably foreseeable misuse. Similarly, although some users might be hacking their devices for fun (or for security research), this use is not necessarily in line with the manufacturer’s stated intended purpose and reasonably foreseeable use, and therefore would constitute a form of misuse.6 Furthermore, manufacturers shall ensure that products with digital elements are accompanied by the information and instructions to the user set out in Annex II, including any known or foreseeable circumstance, related to the use of the product with digital elements in accordance with its intended purpose or under conditions of reasonably foreseeable misuse, which may lead to significant cybersecurity risks. Risks concerning reasonably foreseeable misuse must also be communicated in the information and instructions to the user. For instance, where the information and instructions to the user mentions that the product must be deployed on a secure network, this implies that the manufacturer may not have covered certain risks emerging from use on insecure networks. The manufacturer should therefore inform the user wherever such reasonably foreseeable misuse may still lead to significant cybersecurity risks.
FAQ 4.1.6
How does the length of time the product is expected to be in use affect the manufacturer’s cybersecurity risk assessment?
For the purpose of ensuring the security of products with digital elements after their placing on the market, manufacturers should determine the support period, which should reflect the time the product with digital elements is expected to be in use. Thus, in accordance with Article 13(3), the analysis of cybersecurity risks by the manufacturer shall take into account the length of time the product is expected to be in use (Article 13(8)). The manufacturer should also consider the product’s lifetime in the design and development stage, and in particular should prepare the product to ensure that throughout the support period vulnerabilities of that product, including its components, are handled effectively and in accordance with the essential cybersecurity requirements set out in Part II of Annex I. Furthermore, according to Article 13(7) the risk assessment shall be documented and updated as appropriate during the product’s support period. Where the risk assessment relies on the information and instructions to the users to address certain risks, such information and instructions to the users should be updated accordingly. As stated in Recital 75, Member States should aim to address, to the extent possible, the challenges faced by vulnerability researchers, including their potential exposure to criminal liability, in accordance with national law. Given that natural and legal persons researching vulnerabilities could in some Member States be exposed to criminal and civil liability, Member States are encouraged to adopt guidelines as regards the non-prosecution of information security researchers and an exemption from civil liability for their activities. As an example, the manufacturer may consider reasonable projections about changes in the threat landscape and how these might impact the risk assessment throughout the product lifetime.
FAQ 4.1.7
What is the relationship between harmonised standards and the manufacturer’s cybersecurity risk assessment?
As stated in the Blue Guide, harmonised standards do not replace legally binding essential requirements. A technical specification given in a harmonised standard is not an alternative to a relevant essential or other legal requirement but only a possible technical means to comply with it. In risk-related harmonisation legislation this means in particular that manufacturers always, even when using harmonised standards the references of which are published in the Official Journal of the European Union (“OJ”), remain fully responsible for assessing all the risks of their product in order to determine which essential (or other) requirements are relevant. After this assessment a manufacturer may then choose to apply technical specifications given in harmonised standards the references of which are published in the OJ to implement ‘risk reduction measures’ which are specified by harmonised standards. In risk-related harmonisation legislation, harmonised standards the references of which are published in the OJ most commonly provide certain means to reduce or remove risks, while manufacturers remain fully responsible for the risk assessment to identify relevant risks and to identify relevant essential requirements, in order to select suitable harmonised standards the references of which are published in the OJ or other specifications. Thus, even where the manufacturer uses a harmonised standard (where its reference is published in the OJ and which aims to cover certain risks) to satisfy essential requirements, the cybersecurity risk assessment has to be carried out and they must check whether the harmonised standard covers all risks of the product. In accordance with Article 27, where a manufacturer correctly applies a harmonised standard the reference of which is published in the OJEU which covers all the risks relevant to the product with digital elements, the product benefits from the presumption of conformity.7 As stated in Article 27(1) of CRA and section 4.1.2.2 of the Blue Guide, where a harmonised standard covers only part of the essential requirements identified as relevant by manufacturers or only certain aspects thereof, they additionally have to use other relevant technical specifications or develop solutions in accordance with general engineering or scientific knowledge laid down in engineering and scientific literature in order to meet the essential requirements of the CRA. In a similar way when manufacturers choose not to apply all the provisions given in a harmonised standard, As stated in footnote 179 of the Blue Guide. and which normally would provide presumption of conformity, they need, on the basis of their own cybersecurity risk assessment, to indicate in their technical documentation how the compliance is reached or that relevant essential requirements are not relevant for the product. The CRA standardisation request requests the development of a set of harmonised standards that are intended to provide either horizontal or product-specific information to manufacturers to support their compliance with the CRA. See also 6.10 When will harmonised standards to support CRA compliance be ready?
FAQ 4.1.8
What does a manufacturer need to include regarding the cybersecurity risk assessment in the technical documentation to be kept at the disposal of market surveillance authorities?
Article 13(12) and Article 31 require the manufacturer to draw up technical documentation containing information to demonstrate the conformity of the product to the applicable requirements, regardless of the conformity assessment procedure. This documentation may be part of the quality system documentation where the manufacturer chooses a conformity assessment procedure based on a quality system, in line with article 32. This is the case for conformity based on full quality assurance based on module H (part IV of CRA Annex VIII). The technical documentation must be available when the product is placed on the market, whatever its geographical origin or location. In accordance with Article 13(4), when placing a product with digital elements on the market, the manufacturer shall include the cybersecurity risk assessment in the technical documentation required pursuant to Article 31 and Annex VII. After placement on the market the manufacturer shall systematically document, in a manner that is proportionate to the nature and the cybersecurity risks, relevant cybersecurity aspects concerning the products with digital elements, including vulnerabilities of which they become aware and any relevant information provided by third parties, and shall, where applicable, update the cybersecurity risk assessment of the products. In particular, as part of the vulnerability handling requirement in Annex I, part 2(3), the manufacturer must update the risk assessment after the application of regular tests and reviews, wherever relevant information pertaining to the cybersecurity of the product emerges from such tests and reviews. According to section 4.3 of the Blue Guide, in the case where a product has been subject to re-designs and re-assessments of the conformity, the technical documentation must reflect all versions of the product; describing the changes made, how the various versions of the product can be identified and information on the various conformity assessment. In accordance with Article 53, where necessary to assess the conformity of products with digital elements and the processes put in place by their manufacturers with the essential cybersecurity requirements set out in Annex I, the market surveillance authorities shall, upon a reasoned request, be granted access to the data, in a language easily understood by them, required to assess the design, development, production and vulnerability handling of such products, including related internal documentation of the relevant economic operator. 4.2 Product-related essential requirements (Annex I, Part I)
FAQ 4.2.1
Which technical measures does a manufacturer need to implement?
The CRA establishes a set of essential cybersecurity requirements relating to the properties of products with digital elements. Such requirements are objective-oriented and technology-neutral and apply horizontally to all products with digital elements. The specific technical implementation of the essential requirements is dependent on the cybersecurity risk assessment that each manufacturer is required to undertake and take into account during the planning, design, development, production, delivery and maintenance phases of the product with digital elements, in accordance with Article 13(12). For further information on the risk assessment, see the section 4.1 Risk-based approach and risk-assessment. The manufacturer is required to detail in its technical documentation the means used to ensure that the product complies with the essential cybersecurity requirements, including instances where certain essential cybersecurity requirements are not applicable to the product with digital elements, in accordance with Article 13(4). In order to facilitate the assessment of conformity with the essential requirements, the Commission adopted a standardisation request addressed to CEN, CENELEC and ETSI (the European Standardisation Organisations), requesting the development of harmonised standards in the technical areas covered by the CRA. The CRA Standardisation Request requests, inter alia, the development of horizontal harmonised standards covering the product-related essential requirements laid down in Annex I, Part I of the CRA, with a view to support “(i) the development of further, granular vertical harmonised standards for specific products or product types, and (ii) [to] support manufacturers in defining and implementing the security requirements applicable to their respective products, including particularly for products not covered by existing or planned vertical standards” (Annex II, section 2.1 of CRA SR). For more information, see 6.10 When will harmonised standards to support CRA compliance be ready? It should be noted that the use of harmonised standards is voluntary. Manufacturers may demonstrate conformity with the essential requirements via other technical means and are required to document them in their technical documentation.
FAQ 4.2.2
How can a manufacturer ensure that a product is free from all vulnerabilities?
On the basis of the cybersecurity risk assessment referred to in Article 13(2) and where applicable, products with digital elements shall […] be made available on the market without known exploitable vulnerabilities (Annex I, Essential requirement (2)(a)) ‘vulnerability’ means a weakness, susceptibility or flaw of a product with digital elements that can be exploited by a cyber threat (Article 3(40) ‘exploitable vulnerability’ means a vulnerability that has the potential to be effectively used by an adversary under practical operational conditions (Article 3(41) The CRA does not require manufacturers to ensure that a product is free from all vulnerabilities. The CRA requires manufacturers, at the moment of placement on the market, to ensure that, on the basis of their cybersecurity risk assessment and where applicable, the product does not contain known exploitable vulnerabilities. In fact, not all vulnerabilities are exploitable under practical operational conditions. Some vulnerabilities can only be exploited in theoretical conditions (e.g. in a lab or in a simulation) and/or not under conditions which would occur in the operational environment of a given product with digital elements. Whether a vulnerability is exploitable needs to be addressed on a case-by-case basis, depending on the specific operational and technical conditions, including for example the extent to which the vulnerable code is invoked or loaded when the product is in use; the level and type of access required to carry out the exploit; whether compensating controls are already in place to mitigate exploitation. For example, a smartphone may have a vulnerability that would enable an attacker to bypass security (e.g. skipping password checks); but in order to achieve this, the attacker needs physical access to the device and invasive physical tampering (e.g. using of a laser to cause a glitch) to make use of the exploit. On the basis of its risk assessment, the manufacturer may conclude that this would not be considered an exploitable vulnerability because it could not reasonably be exploited in practical operational conditions.
FAQ 4.2.3
How should manufacturers deal with known exploitable vulnerabilities discovered after a product has been placed on the market but before reaching its final user?
Products with digital elements may be placed on the market and enter the distribution chain some time before they reach their final user. This is often the case, for example, when a product is sent to the distribution branch of a manufacturer; or it is offered for sale online or through other means of distance selling and is transferred to fulfilment service providers for delivery, reaching its final user days or months after placement on the market. For example, a laptop may stay on the shelf of an electronics shop for some time before being reaching its user. In the period between placement on the market and transaction to the intended final user, known exploitable vulnerabilities affecting that product may be discovered. However, the obligation to deliver, on the basis of the risk assessment, products without known exploitable vulnerabilities applies at the moment of placement on the market (Article 13(1)). As the product has already been placed on the market, manufacturers are therefore not expected to fix newly discovered vulnerabilities while their products have not yet reached their user. Nonetheless, as the CRA also establishes vulnerability handling requirements that apply during a product’s support period, manufacturers shall, in relation to the risks posed to products with digital elements, address and remediate vulnerabilities without delay, in accordance with Annex I, Part II, point (2). For example, given the risks posed by the newly discovered exploitable vulnerabilities, the laptop manufacturer establishes that a security update is necessary to address those vulnerabilities. The manufacturer may be required to provide a security update for the laptop, as soon as it is put into operation by its user.
FAQ 4.2.4
How does the secure-by-default requirement work?
On the basis of the cybersecurity risk assessment referred to in Article 13(2) and where applicable, products with digital elements shall: […] be made available on the market with a secure by default configuration, unless otherwise agreed between manufacturer and business user in relation to a tailor-made product with digital elements, including the possibility to reset the product to its original state (Annex I, Part I, point 2(b)). Manufacturers are required to place products with digital elements on the market with a secure by default configuration, in light of that product’s intended purpose and reasonably foreseeable use, and on the basis of the manufacturer’s cybersecurity risk assessment. Where manufacturers place on the market a component for integration into another product with digital elements, they do not retain control on how the integrating manufacturer adjusts the component’s configuration. The obligation to ensure a secureby-default configuration, therefore, only applies to the component when it is placed on the market separately, and not to how it is later configured or deployed by integrating manufacturers. For example, the manufacturer of a cryptographic library may be required, on the basis of its risk assessment, to place that library on the market with insecure or deprecated algorithms disabled by default, or certificate validation enabled by default. The integrating manufacturer may decide to change some of those settings when developing its own product with digital elements. The manufacturer of the cryptographic library is only responsible for the configuration that the library is delivered with, and not for subsequent modifications that its integrator makes. Similarly, the manufacturer of a microcontroller with a built-in network stack may be required, on the basis of its risk assessment, to place the microcontroller on the market with the network interfaces disabled by default. The integrating manufacturer may then decide to enable them to meet its own product’s intended purpose. The manufacturer of the microcontroller is only responsible for the configuration that the microcontroller is delivered with, and not for subsequent modifications that its integrator makes. For further information on exceptions to the secure-by-default configuration, see entry 4.2.5 When is a product “tailor-made”? What documentation is required in these cases? Finally, it is possible that this essential requirement is not applicable to some products with digital elements. Entry 4.1.3 Does a manufacturer need to implement all the essential requirements? provides further guidance on this.
FAQ 4.2.5
When is a product “tailor-made”? What documentation is required in these cases?
Manufacturers should make their products with digital elements available on the market with a secure by default configuration and provide security updates to users free of charge. Manufacturers should only be able to deviate from the essential cybersecurity requirements in relation to tailor-made products that are fitted to a particular purpose for a particular business user and where both the manufacturer and the user have explicitly agreed to a different set of contractual terms (Recital 64). The CRA establishes that manufacturers may deviate from two essential requirements (namely, secure by default configuration in point (2.b) of Annex I, Part I and providing security updates to users free of charge in point (8) of Annex I, Part II) in relation to tailormade products that are fitted to a particular purpose for a particular business user and where both the manufacturer and the user have explicitly agreed to a different set of contractual terms, as stated in the aforementioned points of Annex I, Part I. This could be the case, for example, for custom-developed hardware or software designed to meet the needs of a specific business user, or products that are developed for integration into a specific customer’s highly controlled environments (e.g. closed networks or air-gapped environments) and are subject to specific contractual terms. A product is not tailor-made, on the other hand, when it undergoes minor customisations before being sold to a customer, without specific sets of contractual terms or arrangements. This is the case, for example, for a customer relationship management (CRM) platform sold to multiple businesses, even if the manufacturer enables some minor customisations; or platforms that use plugins or APIs to be customised, but are fundamentally the same product for every customer. In accordance with Article 31, the manufacturer is expected to include in its technical documentation all relevant data or details to show that its product complies with the relevant essential cybersecurity requirements, including appropriate evidence to demonstrate that the product is tailor-made. 4.3 Vulnerability handling obligations (Annex I, Part II)
FAQ 4.3.1
Are manufacturers required to patch all vulnerabilities that are discovered during the support period?
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. 4.3.2 Does the manufacturer need to address and remediate vulnerabilities for all versions of a software product? 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 vulnerabilityhandling 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).
FAQ 4.3.3
Is the manufacturer responsible for the installation of security updates by the product’s users?
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.
FAQ 4.3.4
Does the manufacturer need to recall the product if it cannot fix a vulnerability?
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.
FAQ 4.3.5
How should manufacturers ensure a separation between security and functionality updates, particularly where updates serve both purposes?
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.
FAQ 4.3.6
How should vulnerabilities in integrated components be addressed and remediated?
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.
FAQ 4.3.7
How does the end of the support period in an integrated component impact a product’s compliance with the CRA?
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. 4.4 Due diligence requirements for integrating components
FAQ 4.4.1
What does the CRA prescribe when integrating components?
When placing a product with digital elements on the market, manufacturers shall ensure that it has been designed, developed and produced in accordance with the essential cybersecurity requirements set out in Part I of Annex I (Article 13(1)) For the purpose of complying with paragraph 1, manufacturers shall exercise due diligence when integrating components sourced from third parties so that those components do not compromise the cybersecurity of the product with digital elements, including when integrating components of free and open-source software that have not been made available on the market in the course of a commercial activity (Article 13(5)) When integrating components sourced from third parties in products with digital elements during the design and development phase, manufacturers should, in order to ensure that the products are designed, developed and produced in accordance with the essential cybersecurity requirements set out in this Regulation, exercise due diligence with regard to those components, including free and open-source software components that have not been made available on the market. The appropriate level of due diligence depends on the nature and the level of cybersecurity risk associated with a given component, and should, for that purpose, take into account one or more of the following actions: verifying, as applicable, that the manufacturer of a component has demonstrated conformity with this Regulation, including by checking if the component already bears the CE marking; verifying that a component receives regular security updates, such as by checking its security updates history; verifying that a component is free from vulnerabilities registered in the European vulnerability database established pursuant to Article 12(2) of Directive (EU) 2022/2555 or other publicly accessible vulnerability databases; or carrying out additional security tests […] (Recital 34) Immediately after the transitional period for the application of this Regulation, a manufacturer of a product with digital elements that integrates one or several components sourced from third parties which are also subject to this Regulation may not be able to verify, as part of its due diligence obligation, that the manufacturers of those components have demonstrated conformity with this Regulation by checking, for instance, if the components already bear the CE marking. This may be the case where the components have been integrated before this Regulation becomes applicable to the manufacturers of those components. In such a case, a manufacturer integrating such components should exercise due diligence through other means (Recital 35) In order to ensure that their product with digital elements meets the essential requirements of the CRA, manufacturers are to exercise due diligence when they integrate third-party components in their products. Manufacturers can integrate different types of components, including those that do not bear the CE marking (e.g. free and open-source components that do not fall in the scope of the CRA, components placed on the market before the CRA applies, or components that have not been placed on the market), but they must ensure that such components do not compromise the cybersecurity of their products with digital elements. When integrating components that bear the CE marking, manufacturers are able to rely on the component’s EU declaration of conformity and accompanying documentation to support their own compliance with the CRA. The appropriate level of due diligence depends on the nature and level of cybersecurity risk of a given component – see also entry on 4.4.2 What is the appropriate level of due diligence?
FAQ 4.4.2
What is the appropriate level of due diligence?
The appropriate level of due diligence depends on the nature and level of cybersecurity risk of a given component and is aimed at ensuring that the components that are integrated do not compromise the cybersecurity of the manufacturer’s product with digital elements. The risk assessment of the product with digital elements also informs the appropriate level of due diligence. Where a component or a product is associated with more risks, the actions that a manufacturer should put in place while exercising due diligence should be more extensive than for a component or product associated with fewer risks. In line with Recital 34, examples of one or more actions that manufacturers may undertake include: checking if the component already bears the CE marking; verifying that a component receives regular security updates, such as by checking its security updates history; verifying in the European vulnerability database established pursuant to Article 12(2) of Directive (EU) 2022/2555 or other publicly accessible vulnerability databases the vulnerabilities applicable to a component and designing, developing and manufacturing the product with digital elements integrating the component in such a way that these vulnerabilities do not compromise the cybersecurity of the product with digital elements; carrying out additional security tests, such as fuzz testing, penetration testing, firmware analysis, side-channel analysis, red-team exercises, network traffic analysis, sensor spoofing. Additional examples of actions that manufacturers may undertake include: performing software composition analysis on components; sandboxing or isolating highly-critical components; when available, reviewing the SBOM of that component; checking the support period of the component; verifying that the intended purpose of the component fits the integrating manufacturer’s use; assessing the security posture of the component’s manufacturer.
FAQ 4.4.3
In order to exercise due diligence, should a manufacturer only integrate components that bear the CE marking?
In line with Article 13(5), manufacturers can integrate various types of components, including components that have not been placed on the market or that have been placed on the market before the CRA applies, provided that it exercises due diligence to ensure that the component does not compromise the cybersecurity of its own product with digital elements. The manufacturer does not need to bring such components into compliance with the essential requirements set out in Annex I, part I, before integrating them.8 Nonetheless, the manufacturer needs to ensure that its own products with digital elements are secure and meet the CRA essential requirements, and due diligence is a key obligation to meet those requirements. The manufacturer is also required to comply with the vulnerability handling obligations of Annex I, Part II, for the duration of the support period, for their products in their entirety. Manufacturers of such components are required to ensure they are compliant with the CRA, if they place them on the market. Integration of components that bear the CE marking may simplify certain obligations (e.g. see entry 4.3.6 How should vulnerabilities in integrated components be addressed and remediated?) but is not required by the CRA.
FAQ 4.4.4
How should manufacturers exercise due diligence with regards to opensource components that are not subject to the CRA?
Manufacturers are allowed to integrate open-source components that are not in scope of the CRA (i.e. because they are not made available on the market in the course of a commercial activity), as well as open-source components that are published by an opensource software steward. As explained in 4.4.2 What is the appropriate level of due diligence?, the appropriate level of due diligence is dependent on the nature and level of cybersecurity risk of a given opensource component. The Commission is empowered to establish voluntary security attestations programmes that can be used to assess the conformity of free and open-source components with the CRA. Where available, such attestation programmes would facilitate manufacturers’ due diligence obligation. 4.5 Support period 4.5.1 Which criteria should the manufacturer take into account when determining a product’s support period? Manufacturers shall determine the support period so that it reflects the length of time during which the product is expected to be in use, taking into account, in particular, reasonable user expectations, the nature of the product, including its intended purpose, as well as relevant Union law determining the lifetime of products with digital elements. 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 as well as relevant guidance provided by the dedicated administrative cooperation group (ADCO) established pursuant to Article 52(15) and the Commission. The matters to be taken into account in order to determine the support period shall be considered in a manner that ensures proportionality (Article 13(8), second subparagraph). Manufacturers are required to determine the support period so that it reflects the length of time during which it is expected to be in use, taking into account, in particular: reasonable user expectations; the nature of the product, including its intended purpose; other Union law determining the lifetime of products with digital elements. Other relevant factors that manufacturers may take into account include: the support period of similar products placed on the market by other manufactures; the availability of the operating environment; the support period of third-party integrated components providing core functions; relevant guidance provided by the CRA ADCO. All these factors should be taken into account in a manner that ensures proportionality in the determination of the support period. Therefore, manufacturers are not expected to simply set support periods that correspond to the expected use time (unless the expected use time is less than five years, as discussed in entry 4.5.2 Is there a minimum support period?). In accordance with Article 13(8), a manufacturer should include in its technical documentation the information that was taken into account to determine the support period of a product with digital elements.
FAQ 4.5.2
Is there a minimum support period?
Without prejudice to the second subparagraph, the support period shall be at least five years. Where the product with digital elements is expected to be in use for less than five years, the support period shall correspond to the expected use time (Article 13(8), third subparagraph). The support period for which the manufacturer ensures the effective handling of vulnerabilities should be no less than five years, unless the lifetime of the product with digital elements is less than five years, in which case the manufacturer should ensure the vulnerability handling for that lifetime. Where the time the product with digital elements is reasonably expected to be in use is longer than five years, as is often the case for hardware components such as motherboards or microprocessors, network devices such as routers, modems or switches, as well as software, such as operating systems or videoediting tools, manufacturers should accordingly ensure longer support periods. In particular, products with digital elements intended for use in industrial settings, such as industrial control systems, are often in use for significantly longer periods of time. A manufacturer should be able to define a support period of less than five years only where this is justified by the nature of the product with digital elements concerned and where that product is expected to be in use for less than five years, in which case the support period should correspond to the expected use time. For instance, the lifetime of a contact tracing application intended for use during a pandemic could be limited to the duration of the pandemic. Moreover, some software applications can by nature only be made available on the basis of a subscription model, in particular where the application becomes unavailable to the user and is consequently not in use anymore once the subscription expires (Recital 60) The support period needs to be set to at least five years, but that is not sufficient where products with digital elements are reasonably expected to be in use for longer than five years. In such circumstances, manufacturers should consider all relevant factors (see entry 4.5.1 Which criteria should the manufacturer take into account when determining a product’s support period?) which may result in a need to provide for a support period longer than five years. A support period of less than five years is only justified in situations where the lifetime of the product with digital elements is less than five years. In these cases, the support period shall correspond to the expected use time, without further consideration for the other criteria listed in Article 13(8). This is the case for products that fulfil a very specific purpose (e.g. a contact tracing app to be used during a pandemic), but also for some software applications that can, by nature, only be made available on the basis of a subscription model, particularly where the application becomes unavailable to the user once the subscription expires. For example, some enterprise antivirus software only works for users with an active subscription, as users rely on the availability of up-to-date antivirus definitions, and is no longer accessible when that subscription expires. Similarly, some free and open-source software that is placed on the market can be monetised by its manufacturer only through the sale of paid support services offered on a subscription basis. Therefore, due to its nature of being free and open-source, that software may remain in use after its user stops paying for the support services; in such circumstance, the manufacturer is required to ensure a support period that is equal to the duration of the active subscription. 4.5.3 Can a manufacturer continue to sell products without a support period? Manufacturers need to set the support period for all products with digital elements that have been placed on the market after 11 December 2027. Those products can continue to be made available on the market after their support period expires. However, for units of that product that are newly placed on the market, manufacturers are required to set the support period. For example, a manufacturer produces 10 000 identical units of the same hardware product model or series and places them on the market in January 2028, with a support period of five years (i.e. until January 2033). A distributor manages to sell only a part of those units before the end of the support period. The distributor can continue to make those units available even after January 2033. On 1 January 2030, the same manufacturer produces an additional 5 000 identical units of that same hardware product model or series and places them on the market. The manufacturer is required to set a support period for those units, in accordance with Article 13(8) of the CRA. 5 Reporting obligations of manufacturers
