The EU Cyber Resilience Act

1. The Cyber Resilience Act (CRA)[1] is a new EU Regulation that introduces mandatory baseline cybersecurity requirements for manufacturers and suppliers of a wide range of software and hardware with a digital element in the EU, ranging from smart TVs to baby monitors.

Key points

• Suppliers of software, hardware or digital devices that connect (either directly or indirectly) to a network or the internet will likely need to ensure that their products are compliant with the CRA. This captures many forms of software and hardware routinely used by businesses and consumers.
• The CRA applies to relevant products supplied into the EU, with duties placed upon those in the supply chain. It applies to suppliers based both inside and outside the EU.
• The CRA requires relevant products to meet minimum cyber security requirements, and be CE marked and certified as meeting those requirements. This includes ensuring that the product is designed to be resistant against cyber-attacks, as well as requiring vulnerabilities to be identified, documented, disclosed and patched.
• Products that are important to ensuring the security of a network or device (like password managers, anti-virus software, SIEMs, and patch management systems) or carry a significant risk to the safety of users will need to be tested and certified by an approved third party (known as a notified body).
• Any actively exploited vulnerability in a product must be notified to national and EU-level cyber agencies within 24 hours, and also to users in a timely manner.
• Failure to comply with the CRA can result in fines of up to €15m or 2.5% of global turnover (whichever is higher) as well as being required to recall non-compliant products.

The role of the CRA within the EU cyber security regime

2. The EU has a number of laws that set requirements for minimum levels of cyber security. Most of those address the challenge of cyber risk from the perspective of the users of technology or the type of information involved. For example, the General Data Protection Regulation (GDPR) imposes minimum cyber security requirements, but only in respect of protecting personal data[2]; NIS laws[3] place requirements on large organisations operating in critical sectors like healthcare, transportation and energy, but not on organisations in non-critical sectors; there are also product specific cyber security requirements e.g. for medical devices, cars, and planes. These laws sometimes apply directly to technology suppliers, or result in organisations flowing down these requirements to suppliers through contracts.[4] 
3. The patchwork nature of the existing EU cyber laws means that not all software and digital devices are falling under these regimes. The EU believes that this gap in the EU cyber security regime is leading to technology being used within the EU that is not secure. It is particularly concerned about minor pieces of software with a vulnerability that can then be exploited as a point of initial compromise, enabling malicious actors to gain access to wider networks and systems. The goal behind the CRA is to ensure that all software and digital devices – no matter their importance – are secure at the point of being made available within the EU so to mitigate the risk that one single point of failure can bring down a whole IT system or network.[5] The CRA therefore imposes minimum cyber security requirements directly on to the manufacturers, importers and distributors of software, hardware and other digital devices.

What products are caught by the CRA?

4. The CRA covers ‘products with digital elements’ which is defined to mean:
   • "A software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately"[6]; and where
   • "The intended purpose or reasonably foreseeable use of which includes a direct or indirect logical or physical data connection to a device or network".[7]
5. This is a very broad definition[8] that will capture most forms of software and hardware that are capable of connecting to a network. This includes both standalone software that might later be installed on to a device that connects to a network and devices that come with pre-loaded software. For example, this would include the operating system of a server and the server itself, the apps on a phone, industrial control systems, internet-connected children's toys, and smart consumer devices. 
6. The CRA applies to both business and consumer products, and regardless of whether the product is supplied for payment or free of charge.[9]
7. There are a few exceptions:
   • Products that are already covered by existing cyber security laws for prescribed areas such as for medical devices, cars and planes[10]
   • Spare parts[11]
   • Any product developed exclusively for national security or military purposes[12]
   • Open-source software that is provided for free and outside of commercial activity. Commercial activity is widely interpreted and means more than payment of money. Free products that generate revenue through advertising or monetising personal data, or which have a later paid-for support service or bolt-on extras (freemium products) are products involving commercial activity and therefore caught by the CRA[13]
   • Software made available for testing, so long as only made available for a limited period and clearly marked as being only for test purposes[14]
   • Software-as-a-service (SaaS) solutions are not caught unless they form part of a "remote data processing solution" to a product. So, if a device only functions with a connection to the cloud, then both the device and the cloud infrastructure of that product are caught by the CRA. The logic behind excluding pure SaaS solutions is that any medium-sized cloud service provider is likely already caught under NIS2.[15] 
8. The CRA only applies to products placed on the EU market[16] This applies whether the product was developed and sold inside the EU, or developed outside the EU and then sold into the EU. The CRA therefore has exterritorial effect on organisations outside the EU who are part of the supply chain of products into the EU.
9. In this briefing, references to a "product" means a product falling under the CRA.

Who does the CRA apply to?

10. The CRA regime is built around the blueprint used across EU product safety laws and so might appear odd to those in the technology, cyber security and privacy fields who are more accustom to laws being built around the GDPR / NIS blueprint. The starting point is that the CRA will (in general terms) apply to anyone seeking to supply products into the EU market. The CRA applies regardless of the size of the supplying organisation or the number of products supplied, save that for small businesses some of the documentation requirements will be simplified and there will be additional support made available to them.[17]
11. The CRA places duties upon the whole supply chain, specifically:
    • Manufacturers: (i) anyone, wherever in the world they are based, who manufactures a product, or (ii) anyone who has a product manufactured for them under their own brand. So, where Person A manufactures a white-labelled product on behalf of Person B and affixes Person B's brand to the product, then it will be Person B who is classed as the manufacturer.[18] 
    • Importers: anyone based in the EU who places on the EU market products made/branded by others outside of the EU. If an EU business brings a product into the EU under someone else's brand, they are an importer. But, if they substantially modify or re-brand the product under their own brand, then they are regarded as the manufacturer.[19]
    • Distributors: anyone who supplies a product within the EU, and is not a manufacturer or importer. A manufacturer or importer is the first person who places the product onto the EU market. A distributor is anyone who then supplies the product in the EU without modification.[20]
12. Where a product is substantially modified by a distributor or importer (or any other person), then they will become the manufacturer.[21] This is a real possibility where a vendor might take a piece of software and then customise for a particular audience or incorporate it into a digital device. A good example would be taking some generic database software and then using it to build a stock management system or using generic automation software in a smart home device. It is not yet clear what would amount to a substantial modification as opposed to a configuration change, and there is scope for argument about how far a piece of software has to change before it become a new product. Hopefully, further guidance will be provided on this by the EU in due course.
13. It is not clear where software intermediaries like re-sellers sit under the CRA. In traditional product liability laws it is easier to identify the point where a physical product crosses the EU border and who, at that point, had ownership, or at least de facto control, of that product. With software this is much harder as it is fungible and rarely supplied on physical media. In the case of software re-sellers they may not be supplying the software themselves; the customer may download the software directly from the software developer. The re-seller's role may be only to negotiate the scope and price of the licence to use that software. It is conceptually hard to say whether agreeing the terms of a licence amounts to placing the software on the market.[22] It may be that the EU will in due course publish guidance on how the CRA will apply in practice in these types of scenarios.
14. Depending on a person's designation as a manufacturer, importer or distributor they will have different levels of responsibility for the product being compliant with the CRA. In broad terms:
    • Manufacturers have responsibility for ensuring that any product they place on the EU market meets the minimum security requirements under the CRA, is properly certified as meeting those requirements, includes the required technical documentation with the product and has other record keeping responsibilities.[23]
    • Importers have an obligation to ensure that the manufacturer has met the above requirements before importing a product, and must include the importer's own name and contact details with the imported product.[24]
    • Distributors have to ensure that the product includes the correct certification paperwork and markings.[25]

What standards does a product need to meet?

15. Every product[26] is required to comply with a list of requirements set out in Annex 1, CRA. Part 1 of Annex 1 looks to ensure that a product is secure at the point of first supply:
    • There is a general obligation to ensure that products are "designed, developed and produced in such a way that they ensure an appropriate level of cyber security based on the risks".
    • Depending on the risks presented by the product, there are then 13 prescribed cyber security controls that should be implemented (as appropriate) including measures that protect against unauthorised access, protect the storage and transmission of data through encryption, limit attack surfaces, make the product resilient to DDOS attacks, and minimise the use of personal data.
16. Part 2 of Annex 1 requires that manufacturers have in place processes for managing and remediating vulnerabilities in their products during their full lifecycle.[27] It is not sufficient for the product to only be secure at the point of being supplied, the manufacturer must also ensure the product remains secure. This includes:
    • Regular vulnerability testing and security reviews.
    • Documenting known vulnerabilities in a product, including drawing up a 'software bill of materials'[28] which is a description of the different components of the product, including where the product has made use of other pieces of software licensed from other vendors.
    • Mechanisms for communicating and distributing security updates without delay.[29]
17. The above obligations for the continuous handling for future vulnerabilities last for at least five years (unless the expected lifetime of the product is less than five years).[30] Where technically feasible, the product must notify users when its support period has expired.[31]
18. For vendors supplying enterprise grade software solutions, the requirements of Annex 1 may largely reflect best practice that is already being followed. However, the CRA places this best practice onto a legal footing and imposes penalties for non-compliance. This is going to greatly increase the need to ensure that all the requirements of the CRA are followed for every piece of software and, importantly, document how that is being done so that compliance can be demonstrated to a regulator.
19. For other vendors, especially smaller businesses or manufacturers of devices where the digital component is not central to the product, the obligations of the CRA could be burdensome, especially the requirements for continuous review of vulnerabilities and the need to provide rolling security updates which must be provided free of charge.[32]

Testing and compliance

20. The CRA prescribes how a manufacturer must go about complying with the above security obligations and then documenting that compliance. The key elements are as follows:
    • The manufacturer must undertake a risk assessment for each product. The risk assessment shall then inform how the product is designed, developed and maintained. This risk assessment is the foundation for all other parts of the CRA and informs whether and how the security requirements in Annex 1 are implemented[33]
    • The manufacturer must exercise due diligence when integrating components from third parties into a product[34]
    • The manufacturer must draw up technical documentation for each product that includes a prescribed list of required information such as a description of the product, its cyber security risk assessment, and user instructions[35]
    • The manufacturer must ensure the product has an identification number and the manufacturer's contact details[36]
    • The manufacturer must have in place appropriate policies and procedures for managing future vulnerabilities, including having a designated single point of contact for users[37] and potentially having a "bug-bounty" policy.[38]
21. The product must also be put through a conformity assessment procedure.[39] These procedures are common in EU product safety laws in the context of CE marked products, and are a testing process designed to check that the requirements of the CRA have been met, including that all the above risk assessments and documentation have been prepared. Crucially, the conformity assessment must be undertaken before the product is placed on the market – this is a cornerstone requirement of the CRA. It is more than an administrative or paperwork exercise; failure to undertake a conformity assessment is a ground for regulatory enforcement action and a product cannot be CE marked without it.
22. There are two levels of conformity assessment under the CRA. For most products, a manufacturer can self-assess the conformity but can only do so by following a prescribed assessment procedure.[40] However, for 'important' products, these will either need to comply with a harmonised standard or need to be submitted to a third-party testing body who will undertake the conformity assessment.[41] Important products are listed in Annex III and include operating systems, web browsers, anti-virus software, firewalls, routers, SIEMs, and encryption certificates. Annex III currently only has a high-level description of each critical product and it is expected that the EU will pass delegated legislation setting out more precise definitions in due course.[42] Once a product has passed its conformity assessment, the manufacturer must draw up a Declaration of Conformity and the product itself must be given a CE marking.[43]
23. The need for conformity assessment, and potentially the third-party testing, of products before they are supplied is a major change to the regulatory landscape for pure software, though it may be familiar to those manufacturing tangible devices that may already be caught by other product safety regulations.

Regulatory reporting

24. The CRA introduces a new cyber risk reporting regime that is designed to ensure that cyber security agencies are made aware promptly of serious security risks so that they may then consider whether EU wide action is required. This seeks to address a primary concern of the EU around the systemic risks posed across the EU from a failure in a single product.
25. The primary obligation is that a manufacturer is required to notify the applicable national Computer Security Incident Response Team (CSIRT) and the European Union Agency for Cybersecurity (ENISA) within 24 hours of (i) any "actively exploited vulnerability" or (ii) any "severeincident having an impact on the security of the product".[44] The latter refers to situations where a cybersecurity incident affects the development, production or maintenance processes of the manufacturer in such a way that it could result in an increased cybersecurity risk in a product. Such a severe incident could include a situation where an attacker has successfully introduced malicious code into the release channel via which the manufacturer releases security updates to users.[45]
26. Further, the manufacturer must also inform "in a timely manner" the users of any product about any actively exploited vulnerability or severe incident, and also provide details of any corrective measures that the user can deploy to mitigate the impact on them.[46]
27. The above reporting obligations somewhat reflect existing best practice, where many technology vendors routinely publicise vulnerabilities and then supply patches or instructions to their customers on how to fix them. However, the need for a technology vendor to report direct to a regulator is a new requirement. This also goes beyond existing data breach notification obligations under the GDPR which require there to be at least a low risk of harm to individuals before the notification obligation is engaged. Under the CRA, there is no severity threshold for reporting a cyber-incident: all active exploits must be reported within 24 hours, even if there is no harm caused or expected. This is an onerous obligation and one that will require manufacturers to have in place streamlined decision-making processes in order to make required notifications on time. 
28. Importers and distributors also have reporting obligations. If they become aware of a vulnerability in a product, they are required to inform the manufacturer without undue delay. Where the vulnerability presents a "significant cybersecurity risk", they must also notify the relevant regulatory authority.[47]

Enforcement, penalties and compensation

29. The CRA is principally enforced through the imposition of penalties for non-compliance, though members states are expected to enact further enforcement measures. This will include powers to compel manufacturers to make a product secure, to withdraw a product from sale or to issue a recall for the product. In terms of penalties:
    • Where there is a breach of the core cybersecurity requirements by a manufacturer: a penalty of up to €15,000,000 or 2.5% of total worldwide annual turnover, whichever is higher.[48]
    • For other infringements, including by importers and distributors: a penalty of up to €10,000,000 or 2.5% of total worldwide annual turnover, whichever is higher.[49] 
30. The CRA does not include a regime for compensation for customers who buy a product that is non-compliant, however liability to customers could come through various different routes.
    • It may be the contract for the supply of the product or the software licence terms state (either expressly or by implication) that the product complies with all applicable laws and so non-compliance with the CRA would amount to a breach of contract.
    • For tangible goods, sale of goods laws require a product to be of satisfactory quality and it could be argued that a product not compliant with the CRA is not of satisfactory quality.[50] A similar analysis may be possible under various consumer protection laws where a manufacturer is deemed to have misstated the security of their product.
    • The CRA is linked to another piece of EU legislation, the Product Liability Directive, and envisages the possibility of compensation where a lack of security updates amounts to a safety failure that causes harm to individuals.[51]
31. Product liability is also a fertile area for class actions. The CRA could therefore indirectly open up a new avenue for class action litigation arising from information security breaches.

Implementation dates

32. Save for some of the reporting obligations (see below), the CRA will apply from 11 December 2027 (the implementation date) and it does not have retrospective effect, so products placed on the market before this date are not caught by the CRA.[52] However, if a previously supplied product is modified or more of the same product supplied after the implementation date, then the product is caught.
33. The manufacturer's obligations to report actively exploited vulnerabilities and severe security incidents apply earlier and do have retrospective application. The reporting obligation applies from 11 September 2026[53] and it applies to all products placed on the EU market, whether supplied before or after the implementation date.[54]
34. Although the implementation date is some way off, it is possible to foresee the following steps taking a long time to complete or being a cause of delay in becoming compliant:
    • Risk assessments might reveal the need to change or re-develop a product.
    • Technical documentation, internal policies and conformity assessments may take some time to prepare.
    • For legacy products, it may be more cost-effective to withdraw them from sale rather than make them compliant, which could then cause complaints from customers still reliant on that technology.
    • For critical products that require third-party testing, there could be bottlenecks in capacity at testing houses to cope with the volume of products that will need assessment, especially given the complexity of some of those products (e.g. operating systems). This could lead to delays in assessments being ready on time.
    • For tangible products like smart devices they will need to be physically CE marked and have the correct documentation enclosed. Having to re-work already built and packaged products can be expensive and time consuming.
35. There are also several provisions in the CRA that give the EU the power to pass delegated legislation that might expand the CRA or set down more prescriptive rules. It is also expected, as is common with other product safety laws, that the EU will publish guidance on how the CRA is interpreted and enforced, however such guidance often only comes out late in the day. These developments may shift the focus and requirements of the CRA. Nevertheless, it is recommended that work starts early to ensure products are compliant, which can be done by asking the following key questions:
    • Which products might be caught by the CRA?
    • Are any of them "important products" that may require a higher level of conformity assessment?
    • Are there cyber risk assessments in place for these products?
    • What documentation is available for each product and what is missing?
    • What policies and procedures are in place for vulnerability management?

Sources

^{[1] Regulation 2024/2847 https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847}

^{[2] Article 32, GDPR.}

^{[3] Directive on Security of Network and Information Systems ("NIS1"), which applies in the UK by virtue of the Network and Information Security Regulations 2018. In the EU, NIS1 has been revised and replaced with updated legislation known as "NIS2".}

^{[4] For example Article 32 GDPR would apply directly to a software-as-a-service vendor who is hosting and processing personal data, but it would not apply directly to a vendor that sold the same software under licence with no hosting or support service.}

^{[5] Recital 9 and 10}

^{[6] Article 3(1)}

^{[7] Article 2(1)}

^{[8] See section 3 of the Explanatory Memorandum to the original proposal for the CRA that records that the EU's intention was for the legislation to cover "a broad scope of tangible and intangible products with digital elements, including non-embedded software"}

^{[9] See the definition of 'making available on the market' at Article 3(22)}

^{[10] Article 2(2) and (3)}

^{[11] Article 2(6)}

^{[12] Article 2(7)}

^{[13] Recital 18}

^{[14] Recital 37 and Article 4(3)}

^{[15] Recital 12}

^{[16] Article 3(21)}

^{[17] Recital 94 and Articles 26(1), 31(5), 32(6), 33 and 64(10).}

^{[18] Article 3(13)}

^{[19] Article 3(16)}

^{[20] Article 3(17)}

^{[21] Articles 21 and 22}

^{[22] This is especially so in light of other EU case-law which has previously found that "the downloading of a copy of a computer program and the conclusion of a user licence agreement for that copy form an indivisible whole. Downloading a copy of such a program is pointless if the copy cannot be used by its possessor. Those two operations must therefore be examined as a whole for the purposes of their legal classification. Computer Associates UK Ltd v The Software Incubator Ltd (Case C-410/19) [2021] at para 41.}

^{[23] Article 13}

^{[24] Articles 19(2) and 19(4)}

^{[25] Article 20(2)}

^{[26] There is a narrow exception for "tailor-made" products for business users – recital 64}

^{[27] See also Articles 13(6) and 13(8)}

^{[28] Articles 3(39) and 13(24)}

^{[29] Once a security update has been issued, it must remain available for the life of the product or 10 years (whichever is longer) – Article 13(9)}

^{[30] Article 13(8)}

^{[31] Article 13(19)}

^{[32] Paragraph (8), Part 2, Annex 1 (save for tailor-made products for business users where support fees may still be charged)}

^{[33] Article 13(2)}

^{[34] Article 13(5)}

^{[35] Articles 13(12), 13(13), 13(18) and 31, and Annex VII}

^{[36] Article 13(15) and 13(16)}

^{[37] Article 13(17)}

^{[38] Article 13(8) and recital 76.}

^{[39] Article 13(12), as then further described in Article 32 and Annex VIII}

^{[40] Article 32(1)}

^{[41] Article 32(2) and (3)}

^{[42] See Article 7(3). The CRA also gives the EU the power to designate a third category of product – critical products – that will require an EU cyber security certificate – see Article 8.}

^{[43] Articles 28 – 30}

^{[44] Article 14(2) and 14(3), and see the definitions of these terms at 3(42) – (44)}

^{[45] Recital 68}

^{[46] Article 14(8)}

^{[47] Article 19(5) and Article 20(4)}

^{[48] Article 64(2)}

^{[49] Article 64(3)}

^{[50] Under other EU legislation, the grant of a perpetual software licence (regardless of whether supplied on tangible media or by digital download) has been found to be a sale of goods, but limited term licences are not. Computer Associates UK Ltd v The Software Incubator Ltd (Case C-410/19) [2021].}

^{[51] Recital 31}

^{[52] Article 69(2) and 71(2)}

^{[53] Article 71(2)}

^{[54] Article 69(3)}