On 30 November 2023, the EU reached political agreement on the Cyber Resilience Act (“CRA”), the first legislation globally to regulate cybersecurity for digital and connected products that are designed, developed, produced and made available on the EU market. The CRA was originally proposed by the European Commission in September 2022. Alongside the recently adopted Data Act, Digital Operational Resilience Act (“DORA”), Critical Entities Resilience Act (“CER”), Network and Information Systems Security 2 Directive (“NISD2”) and Data Governance Act, the CRA builds on the EU Data and Cyber Strategies, and complements upcoming certification schemes, such as the EU Cloud Services Scheme (“EUCS”) and the EU ICT Products Scheme (“EUCC”). It responds to an increase in cyber-attacks in the EU over the last few years – in particular the rise in software supply chain attacks which have tripled over the last year –as well as the significant rise in digital and connected products in daily life which magnifies the risk of such attacks.
We set out below 6 key takeaways on the CRA based on the final compromise text published on 20 December 2023:
- Who and What Does the CRA Apply to?
The CRA applies to all economic operators involved in (and throughout) the lifecycle chain of “products with digital elements” i.e. (i) manufacturers (and their authorised representatives), (ii) importers, and (iii) distributors (together “Economic Operators”) with most of the obligations imposed on manufacturers. The CRA has extraterritorial application, and applies to both entities inside and outside the EU – to the extent they import, distribute or place on the EU market products in scope of the CRA.
The CRA applies to (i) “products with digital elements” (“PDEs”) which means any software or hardware product which is intended to be used, or has a reasonably foreseeable use, to connect to a device or network (e.g. a smart camera, smart fridge, etc.); (ii) the PDE’s remote data processing solutions which are processing solutions at a distance which are necessary for the PDE to function (e.g. a cloud service that allows the user to control and monitor his smart doorbell using a mobile application); and (iii) any software or hardware components of such products that are placed on the EU market separately (with the exception of spare parts).
The CRA carves out from its application a number of PDEs used in specific industries, in particular those which are already regulated on the basis of sectoral EU legislation such as the medical device and in-vitro diagnostic medical device, automotive, civil aviation, and marine equipment industry – and further PDEs may be carved out by the EU Commission through delegated acts.
- What Are the Requirements?
The CRA essentially requires all hardware and software PDEs to implement appropriate cybersecurity measures across the entire lifecycle of the product – from the design and development stage and throughout their commercialization in the EU. Although requirements are imposed on all Economic Operators indicated above, the onus of the requirements are placed on PDE manufacturers and can be summarized as follows:
- Conformity of PDEs with CRA standards begins at the design process, and therefore one of the key obligations under the CRA is for the manufacturer to design and develop the PDE in line with the “essential cybersecurity requirements” (“ECRs”) set out in Annex I to the CRA and to carry out a cybersecurity assessment to determine the cyber risk associated with each PDE (which must be documented and maintained throughout the lifecycle of the PDE). The ECRs are not described in technical detail, and include requirements to ensure that the PDE (i) enables a level of cybersecurity in accordance with the risks presented by the product; (ii) is not placed on the EU market with any known exploitable vulnerabilities and without adequate security-by-default configurations (i.e., default settings for security updates to be installed automatically); (iii) is protected from unauthorized access using appropriate control mechanisms; and (iv) provides users the option to securely and easily remove all data and settings and allow for the secure transfer of all user data to other products or systems.
- The ECRs also include specific vulnerability and incident handling requirements – which address how manufacturers must address vulnerabilities and severe incidents detected in PDEs to ensure the PDE is secure throughout its commercial lifecycle on the EU market – and include the adequate identification and documentation of vulnerabilities, regular testing of the security of the PDE and putting in place and enforcing a policy on coordinated vulnerability disclosure. Manufacturers are required to notify any actively exploited vulnerability contained in the PDE, and any severe incident having an impact on the security of the PDE, within 24 hours to the competent Cyber Security Incident Response Team (“CSIRT”) and the EU Agency for Cybersecurity (“ENISA”) and also to the users of the PDE in a timely manner. ENISA will be setting up a single reporting platform for this purpose.
- Manufacturers are also required to perform conformity assessments of the PDE and the processes put in place by the manufacturer to determine whether the ECRs are met. The CRA provides for various types of conformity assessment procedures, in line with the risk level of the PDE and the “Class” the PDE is accordingly ranked in, and other EU laws the PDE may be subject to. For instance, a PDE that is also subject to the EU Health Data Space Regulation (“EHDS”) can follow the conformity assessment procedure provided for in the EHDS.
- Once compliance with CRA requirements has been demonstrated through the conformity assessment, manufacturers will need to draw up the EU declaration of conformity and affix the “CE” marking to the PDE in line with CRA requirements. They will also need to draw up technical documentation and user instructions in accordance with CRA requirements prior to placing a product on the EU market. PDEs will be subject to market surveillance by competent EU market surveillance authorities throughout the product lifecycle.
- What is the Overlap with Other EU Laws?
There is significant overlap of the CRA with other EU laws, including the NISD2, EHDS, AI Act , DORA, CER, GDPR etc. Generally, the CRA, as a horizontal piece of EU legislation, will apply only where more specific EU legislation (the lex specialis, such as the AI Act and EHDS) do not provide for more specific cybersecurity requirements. Although, in relation to high-risk AI systems, the CRA explicitly provides that PDEs which also qualify as high-risk AI systems under the AI Act, will be deemed in compliance with the AI Act’s cybersecurity requirements where they fulfil the corresponding requirements of the CRA.
- How Will the CRA Be Enforced?
EU Member States are competent to enforce and lay down the level of penalties for non-compliance with the CRA – but in relation to infringements against the ECRs, the CRA provides that administrative fines of up to the higher of €15m or, if the offender is an undertaking, 2.5% of total worldwide turnover can be imposed.
- When Will the CRA Apply?
With the publication of the final compromise text on 20 December 2023, the Council has communicated to the Parliament that it is willing to move quickly, and therefore final adoption of the text is expected soon during Q1 2024. Obligations under the CRA will enter into application on different transition timelines. As the bulk of the obligations may involve a (re-)design of products from the cybersecurity perspective, the majority of the obligations are subject to a 36-month transition period (meaning that during 36 months following entry into force, no enforcement will take place to allow Economic Operators to adapt their PDEs to comply with CRA requirements). The vulnerability and incident reporting obligations imposed on manufacturers, however, will be subject to a 21-month transition period.
- What Should Companies Do?
Organizations whose products are potentially subject to the CRA should consider how the CRA may apply to and impact their products, and take action accordingly including by integrating CRA security requirements into the design cycle of their products and implementing policies and processes as required by the CRA, including with respect to vulnerability handling and notifications.
This post is as of the posting date stated above. Sidley Austin LLP assumes no duty to update this post or post about any subsequent developments having a bearing on this post.