Cyber Resilience Act The end of carefree software development
The Cyber Resilience Act (also known as the "EU Cyber Resilience Act" or "Cybersecurity Act") is part of the EU's New Legislative Framework with a risk-based regulatory approach and part of the EU's "Cybersecurity Strategy" from 2020.
According to the EU Commission, the Cyber Resilience Act was prompted by the realization that there is currently a low level of cybersecurity and an insufficient understanding of cybersecurity risks in the market. In this respect, entire supply chains are affected and not only could there be serious disruptions to economic and social activities, but even life-threatening situations.
The Cyber Resilience Act is therefore intended to reduce vulnerabilities in digital products. In addition, manufacturers are to guarantee cyber security throughout the entire product life cycle (but for a maximum period of five years after the product is placed on the market). Overall, the aim is to increase the transparency of the security of software and hardware products.
Below is an overview of the Cyber Resilience Act:
Personal scope
The Cyber Resilience Act primarily imposes obligations on manufacturers. However, obligations are also imposed on importers and retailers; this is important for white label products, for example.
Material scope of application
From a material point of view, various requirements are relevant:
Product with digital elements
From a material point of view, the Cyber Resilience Act covers "products with digital elements". These "products with digital elements" are defined very broadly, namely as follows
"a software or hardware product and its remote computing solutions, including software or hardware components, intended to be marketed separately".
Only "networked" products
An additional requirement for the application of the Cyber Resilience Act is that the product is "networked". This is currently regulated in the Cyber Resilience Act as follows:
"This regulation applies to products with digital elements whose intended or reasonably foreseeable use involves a direct or indirect logical or physical data connection to a device or network."
The general understanding derived from this wording is that only "connected" products are to be covered. However, the term "networked" may be somewhat misleading, as an indirect data connection to a device or network and the foreseeable use of the product are also sufficient for the application of the Cyber Resilience Act. Products that are not network-enabled will therefore also be covered by the Cyber Resilience Act. For example, it should be sufficient for software to be installed in a machine as intended, which in turn communicates or "interacts" with other devices (e.g. in a production line).
The question of the exact scope of regulation of this additional requirement for networking is certainly a contentious issue. However, a number of products are likely to fall under the Cyber Resilience Act, even if they are not network-enabled themselves. Stand-alone software, for example, is likely to be regularly covered. This can be seen, for example, in the examples of covered products expressly mentioned in the Cyber Resilience Act, namely, among others: Browsers, password managers and antivirus software.
Exemptions for SaaS, services and certain sectors
SaaS offerings are exempt from the Cyber Resilience Act. Services are also not covered by the Cyber Resilience Act. So-called "remote data transmission solutions" are not covered by the exemption (and therefore fall under the Cyber Resilience Act). This is intended, among other things, to prevent circumvention of the scope of the Cyber Resilience Act by redesigning traditional products with digital elements in such a way that parts are now designed as SaaS. However, the NIS2 Directive (EU Directive 2022/2555) or the law transposing the NIS2 Directive into national law ("NIS-2 Implementation and Cyber Security Strengthening Act" or the BSIG adapted as a result) may apply to SaaS offerings.
Certain products to which sector-specific regulations apply are also excluded from the scope of application, in particular medical devices covered by the MDR (Regulation 2017/745) and IVDR (Regulation 2017/746), Regulation 2018/1139 in the area of aviation safety and Regulation 2019/2144 in the area of motor vehicles.
However, the sector-specific exemptions must be examined carefully. There are often other products in addition to those covered by the sector-specific regulations. So far, this has been a desirable outcome, as it has avoided regulatory requirements and saved time and effort. However, this may now change with the Cyber Resilience Act. Example: Until now, the threshold for a medical device under the MDR was sometimes deliberately not exceeded, meaning that there was only a mere "wellness product" for which the numerous regulatory requirements of the MDR did not have to be complied with. However, such a "wellness product" can now be "certified" via the Cyber Resilience Act. Accordingly, an accessory product not previously covered by the sector-specific regulations may now fall under the Cyber Resilience Act.
Risk classes
The Cyber Resilience Act is part of the New Legislative Framework with a risk-based approach. Accordingly, four risk classes are distinguished for products with digital elements. Products in all risk classes must comply with so-called essential requirements , which are set out in more detail in Annex I of the Cyber Resilience Act. Depending on the exact risk class into which a product with digital elements falls, further requirements must be observed.
The following four risk classes are distinguished:
Normal / non-critical "products with digital elements"
Class I "Critical products with digital elements"
Class II "Critical products with digital elements"
"Highly critical products with digital elements"
"Simple products with digital elements"
The lowest risk class is a "catch-all class". All products with digital elements that do not fall into one of the other risk classes must be assigned to this lowest risk class. According to the EU Commission's calculations, around 90% of products should fall into this risk class.
"Critical products with Class I digital elements"
The Annex to the Cyber Resilience Act defines in more detail which products fall under Class I critical products. These include, among others: Password managers, standalone and embedded browsers, VPN systems, remote access and data sharing software, and update and patch management.
"Critical products with Class II digital elements"
Class II critical products are also listed in the Annex to the Cyber Resilience Act. These include operating systems for servers, desktops and mobile devices, security elements, container runtime systems that support virtualized execution of operating systems and similar environments, public key infrastructures and issuers of digital certificates, smart cards and IIoT devices (Internet of Things).
"Highly critical products with digital elements"
Which products fall under highly critical products with digital elements will be determined by the EU Commission via delegated acts. The decisive factor here is whether the products are important for the resilience of an entire supply chain and whether they are used by essential facilities within the meaning of the NIS2 Directive (i.e. critical infrastructures).
Conformity assessment procedure
The CE mark may only be affixed after successful completion of the conformity assessment procedure, which is regulated in more detail in the Cyber Resilience Act and its annexes.
In the lowest risk class, manufacturers can carry out the conformity assessment procedure themselves and issue or sign the EU declaration of conformity from the Annex to the Cyber Resilience Act.
In cases of the medium and highest risk class, the options for conformity assessment are limited. The so-called EU type examination procedure and "conformity assessment based on full quality assurance" are then available. In particular, the involvement of an external body, namely a so-called Notified Body, may be required. This notified body can then confirm conformity - or subsequently suspend, restrict or revoke it, which would restrict or completely remove the marketability of the product.
Presumption of conformity under the Cyber Security Act
The Cyber Resilience Act is embedded in a broad-based legislative initiative. In addition to the Cyber Resilience Act, the Cyber Security Act, for example, must also be taken into account.
On the basis of the Cyber Security Act, which has been in force since 2019, it will be possible to issue or obtain cyber security certificates. If such a cybersecurity certificate is available for a specific product with digital elements, a presumption of conformity applies in accordance with the Cyber Resilience Act. The conformity assessment procedure then no longer has to be carried out in full, which saves a considerable amount of time and effort.
Under the Cyber Security Act, so-called schemes are "adopted". These schemes in turn serve as the basis for security certifications to be carried out by companies that specialize in such certifications.
So far, the development of three schemes has been initiated:
European Union Common Criteria Scheme (EUCC)
European Union Cybersecurity Certification Scheme on Cloud Services (EUCS)
Cyber security of 5G networks (EU5G)
However, none of these schemes have been finalized or adopted.
Obligation to provide information and instructions for users
Every product with digital elements must be accompanied by nine pieces of information. This information includes "simple" details such as the name of the manufacturer and their e-mail address.
However, all known or foreseeable circumstances in connection with the intended use of the product with digital elements or its reasonably foreseeable misuse that could lead to significant cybersecurity risks must also be provided. It will be necessary to consider very carefully what information can reasonably be provided here without additional risk.
SBOM / software bill of materials
The new obligation "whether and, if so, where the software bill of materials can be retrieved" will also be of considerable importance. This implicitly includes the obligation to prepare a software bill of materials, i.e. the so-called SBOM (Software Bill of Material). This software bill of material is defined as follows:
"Software Bill of Material" a formal record of the details and supply chain relationships of the components included in the software elements of a product with digital elements;
This ultimately means that all third-party components must also be represented. The reason for this is understandable: If a security vulnerability becomes known in a third-party component (e.g. a common software library from the open source sector, such as recently with regard to glibc), every company must be able to determine whether this software library is contained in its own product - and, if possible, every user. In practice, however, creating and maintaining such a list involves considerable effort. Contracts with suppliers often have to be adapted and internal processes adjusted. Even for the simplest software products, this list can take on a considerable size.
Exception for open source software?
Only recently, due to further negotiations on the Cyber Resilience Act, a regulation on open source software (OSS) was included in a compromise paper as follows:
"This Regulation applies to free and open-source software only when made available on the market in the course of a commercial activity."
(Art. 2 No. 3a Compromise Draft)
According to this, the decisive factor is whether a "commercial activity exists" with regard to the open source software. The recitals, which can only be used to interpret the Cyber Resilience Act but are not legally binding, contain the following guidelines for answering the question of whether a commercial activity exists:
"For example, a fully decentralized development model, where no single commercial entity exercises control over what is accepted into the project's code base, should be taken as an indication that the product has been developed in a non-commercial setting.
On the other hand, where free and open source software is developed by a single organization or an asymmetric community, where a single organization is generating revenues from related use in business relationships, this should be considered to be a commercial activity.
Similarly, where the main contributors to free and open-source projects are developers employed by commercial entities and when such developers or the employer can exercise control as to which modifications are accepted in the code base, the project should generally be considered to be of a commercial nature."
These exceptions are likely to be insufficient or lead to considerable collateral damage in the open source sector if the regulations and "guidelines" remain as they are. Questions of demarcation arise, for example, when non-profit organizations accept donations or when commercial enterprises employ staff to program open source software for the general benefit.
Exceptions for trade fairs and testing purposes
The Cyber Resilience Act provides that software can continue to be used for trade fairs, exhibitions and presentations even without a full conformity assessment.
In addition, the unregulated provision of software for testing purposes is to remain possible if this is only done for a manageable period of time.
New reporting obligations
The Cyber Resilience Act also provides for reporting obligations. According to this, the manufacturer must notify ENISA( the EU'scyber security agency ) immediately, and in any case within 24 hours of becoming aware of actively exploited vulnerabilities.
In addition, a manufacturer must report an incident that affects the security of the product immediately, but in any case within 24 hours of becoming aware of it.
In addition, the manufacturer may not only have to notify ENISA, but may even have to inform the various users of the product (i.e. the end users). In addition to aspects of the manner of such communication, this can - depending on the exact product - entail considerable effort.
Long-term maintenance obligation
In contrast to previous German law (with recent exceptions in the area of consumer products), there is a significant change with regard to ensuring freedom from defects - at least insofar as this relates to IT security vulnerabilities.
Under the Cyber Resilience Act, the manufacturer is obliged to effectively "address" vulnerabilities for the expected lifetime of the product or for a period of five years after the product is placed on the market (whichever is shorter). This will usually mean the provision of security updates.
What is remarkable about this regulation is that this obligation falls on the manufacturer, not the seller. However, depending on the exact nature of the product concerned, this may mean that contractual provisions must be included in the supply chain in order to provide information about updates and to be able to deploy them.
Link with other current acts
The Cyber Resilience Act is to be "linked" with various other EU regulations that are currently at the draft stage.
With regard to various basic requirements, the upcoming EU regulation on general product safety, for example, must be observed in parallel.
If the product is also subject to the EU Machinery Regulation, certain presumptions of conformity with regard to protection and corruption as well as the safety and reliability of control systems also apply to the Cyber Resilience Act.
To the extent that a high-risk AI system exists under the forthcoming AI Regulation and its accuracy and robustness is confirmed under the AI Regulation, this aspect is also deemed to be compliant under the Cyber Resilience Act. It is also pleasing to note that the same Notified Body that is responsible for conformity assessment under the AI Regulation may also test under the Cyber Resilience Act. This enables a "one-stop store" procedure for conformity assessment. The prerequisite for this is, of course, that the notified body is designated accordingly so that it can also carry out the conformity assessment in accordance with the Cyber Resilience Act.
EHR systems are also covered by the EU Regulation on the European Health Data Space (EHDS).
Technical documentation
The time and effort required to prepare the technical documentation should not be underestimated.
Individual aspects may also result in particular difficulties or even the impossibility of preparing technical documentation. For example, if there is a high-risk AI system or an EHR system, the technical documentation must be prepared as "single technical documentation". This means that reference cannot be made to "modular" technical documentation from suppliers. Rather, the regulation should be understood to mean that the technical documentation of the various suppliers must also be available from the manufacturer in a uniform manner, although the details of this have not yet been regulated. As experience with the EU Medical Device Regulation (MDR) has already shown, the compilation of such technical documentation can lead to considerable difficulties. In particular, the interests of suppliers with regard to business and trade secrets must be taken into account.
Obligation to affix a CE mark
All products with digital elements must bear a CE mark from the date on which the Cyber Resilience Act comes into force. By affixing the CE mark and signing the EU Declaration of Conformity beforehand, the manufacturer assumes responsibility for the product.
In view of the very broad definition of a product with digital elements, the days in which a new product can be placed on the market "just like that" are probably numbered. This is certainly the declared aim of the Cyber Resilience Act, which is intended to achieve "security by design".
Legal consequences
Certain violations of the Cyber Resilience Act are subject to fines. A fine of up to EUR 15 million or 2.5% of annual global turnover can be imposed - whichever is greater.