he EU Cyber Resilience Act (CRA) will become mandatory in December 2027, with the sole aim of improving cybersecurity. The CRA applies to products being placed on the EU market. It will affect stakeholders such as designers, manufacturers, importers, and distributors of hardware and software products. To better comply with the CRA’s requirements, they all need to understand whether their product falls within the scope of its legal framework. Simply proving a product’s cybersecurity when placing it on the market will no longer be enough. Instead, the cybersecurity risks must be assessed throughout the life cycle of a product, for example ensuring that any vulnerabilities discovered can be addressed via security updates.
The CRA applies to products with ‘digital elements’, which includes both hardware and software. It introduces new binding and comprehensive cybersecurity requirements for connected hardware and software products. The aim is that ‘products with digital elements’ are designed with cybersecurity in mind from the onset and are therefore considered more secure. As manufacturers remain responsible for cybersecurity throughout a product’s life cycle, they must consider not only the operational phase of the digital product but its design, development, and production. The CRA has a proposed classification scheme
that categorises products as non-critical or critical based on their perceived risk levels: • Non-critical products include approximately
90% of products with digital elements, such as hard drives and other connected devices. Manufacturers in this category may perform self-assessments to check if their products meet the CRA’s requirements. • Critical products are categorised further into class I and class II products under CRA: o Class I products include identity management; standalone and embedded browsers; password managers; software that searches for, removes, or quarantines malicious software; products with digital elements and with the function of a virtual private network (VPN); network management systems, etc. o Class II products include hypervisors and container runtime systems that support virtualised execution of operating systems and similar environments; firewalls, intrusion detection and/or prevention systems; tamper-resistant microprocessors; and tamper-resistant microcontrollers.
While the CRA has a large scope, it does not apply to the following: • Non-commercial projects, including open- source software, as long as it is not part of a commercial activity. • Services, such as cloud computing services and Software-as-a-Service (SaaS) business models. • Highly regulated products and industries, especially those that are sufficiently regulated on cybersecurity, such as automotive, medical devices, in vitro diagnostic medical devices, certified aeronautical equipment, and products developed exclusively for
18
national security or military purposes. Compliance with the CRA is demonstrated by satisfying the Essential Requirements as set out in Annex I. The required route to conformity depends on the risk class of a product. For digital products that are not classified as either ‘important’ or ‘critical’, as defined in the CRA, manufacturers can self-declare using harmonised standards. Standards which may be used in support of this self-declaration are being developed by European standards writing organisations. For other higher risk products, manufacturers and distributors may have to go through assessment by a notified body depending on the features of the high-risk product. Annex III and Annex IV of the CRA provide a list of the types of products considered ‘important’ and ‘critical’ respectively. ‘Important’ products are also split into two classes.
A major essential requirement in the CRA is that products with digital elements shall be designed with an appropriate level of cybersecurity. Thus, the CRA will require manufacturers of connected products to essentially adopt the Secure by Design (Default) principles. The concept of Secure by Design can be applied
to many different types of system, including individual sensors or devices, integrated operational technologies, and industrial processes. It is imperative that this is done at the earliest possible point, ideally at the concept stage. If a device is connected to the Internet, it should be assumed that it will be attacked and
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60
