Whitepaper - Cyber Resilience Act: Developer’s Guide
- Capy B.
- Jul 29
- 5 min read
Updated: Jul 31
Table of Сontents
1. Introduction
3. Summary
1 Introduction
There are two directives and one act that regulate IoT market, these are
EU Radio Equipment Directive — RED (2014),
EU NIS2 Directive (2023), and recent
EU Cyber resilience act — CRA (2024).
In this paper we explain how these regulations affect software engineers working with embedded systems and IoT devices. This short paper serves as a reference and does not constitute legal advice.
2 Implications for Software Engineers
2.1 Radio Equipment Directive
This regulation applies to the electronic equipment that uses radio waves for communication with the goal of improving equipment’s safety in relation to people’s health, but also to make sure it safely integrates with other equipment (see Article 3).
RED lists the following as essential requirements for the equipment.
Radio equipment shall be constructed so as to ensure:
the protection of health and safety of persons and of domestic animals and the protection of property, including the objectives with respect to safety requirements set out in Directive 2014/35/EU, but with no voltage limit applying;
an adequate level of electromagnetic compatibility as set out in Directive 2014/30/EU.
Radio equipment shall be so constructed that it both effectively uses and supports the efficient use of radio spectrum in order to avoid harmful interference.
Radio equipment within certain categories or classes shall be so constructed that it complies with the following essential requirements:
radio equipment interworks with accessories, in particular with common chargers;
radio equipment interworks via networks with other radio equipment;
radio equipment can be connected to interfaces of the appropriate type throughout the Union;
radio equipment does not harm the network or its functioning nor misuse network resources, thereby causing an unacceptable degradation of service;
radio equipment incorporates safeguards to ensure that the personal data and privacy of the user and of the subscriber are protected;
radio equipment supports certain features ensuring protection from fraud;
radio equipment supports certain features ensuring access to emergency services;
radio equipment supports certain features in order to facilitate its use by users with a disability;
radio equipment supports certain features in order to ensure that software can only be loaded into the radio equipment where the compliance of the combination of the radio equipment and software has been demonstrated.
Only the software that is embedded into the devices is affected by this directive: firmware, operating systems and applications that are installed on the device at the time of placing it to the market.
The last requirement — «radio equipment supports certain features in order to ensure that software can only be loaded into the radio equipment where the compliance of the combination of the radio equipment and software has been demonstrated» — can be interpreted as «whatever software is installed on the devices should not affect its safety». Since safety is understood in terms of people’s health and compatibility with other devices, this means that on e.g. a network router any software can be installed on top of its operating system because there is no way for this software to affect the safety. It is the responsibility of the manufacturer to ensure compatibility with the software, and in practice this means that if you successfully installed the software on the equipment, then they are compatible.
RED requires certification of the product to be able to sell it on the European market. Software does not play a major role in the certification.
To summarize, RED affects only embedded software engineers that develop firmware for radio equipment. If you bundle a third-party device with your software in a product, then you are not affected by RED: it is the responsibility of the manufacturer to ensure compatibility with the software.
2.2 NIS2 Directive
This regulation applies to software service providers and especially to DNS, trust and cloud service providers with the goal of improving the baseline level of security of services offered by such providers (see Article 21:2). In addition to that, any critical security-related incidents shall be reported within 24 hours to one of the CSIRTs (Computer Security Incident Response Team) of a member state.
The directive mandates to use at least the following measures to reduce security-related risks (see Article 21:2):
policies on risk analysis and information system security;
incident handling;
business continuity, such as backup management and disaster recovery, and crisis management;
supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers;
security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure;
policies and procedures to assess the effectiveness of cybersecurity risk-management measures;
basic cyber hygiene practices and cybersecurity training;
policies and procedures regarding the use of cryptography and, where appropriate, encryption;
human resources security, access control policies and asset management;
the use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate.
The directive does not mandate any certification scheme yet, however, this scheme might emerge by October 17, 2024.
2.3 Cyber Resilience Act
This act aims to improve baseline security level in «products with digital elements» — essentially hardware and software. It is similar to RED but explicitly targeted towards software-only products including open-source software. Even if you sell support for the open-source software package as a product, this act applies to your product. This act will enter into force in early 2024, and manufacturers will have three years to implement the rules (see CRA Factsheet).
The major requirement is to have a certificate of conformance. The act splits products into non-critical and critical class I and II (see Annex III). For non-critical products the certificate is signed by the manufacturer itself, for class I and II the certificate needs to be signed by a third party called «notified body» — an organization designated by an EU country to assess the conformity of certain products before being placed on the market.
Other requirements include providing technical documentation that includes software bill of materials, vulnerability reporting process, software update process etc.
There are many requirements in the act (see Annex I and II) that can be summarized as follows.
Periodically scan your software and its dependencies for vulnerabilities (automatically or manually).
Provide free-of-charge security updates for every vulnerability that you have found.
Provide a way to report potential vulnerabilities to you by third parties.
Provide software bill of materials.
The product has to be secure by default, limit the attack surface, and reduce the impact of a security incident.
Certify your product with a notified body if it is class I or II, otherwise write a certificate of conformity yourself.
Most of these requirements can be (and should be) met in an automated way, however, you still need to write the documentation and obtain the certificate of conformity.
3 Summary
There are two directives and one act that regulates hardware and software products on the European market. All of them aim to raise baseline standards for cybersecurity, however, only RED and CRA require certification of the products. Out of these two only CRA requires software engineers to align their software development practices with the baseline requirements defined in the act. Besides that software engineers are obliged to provide software bills of materials and set up vulnerability handling processes. The most important part, however, is to obtain a certificate of conformance for the product: either write one yourself (if the software is non-critical) or get one from authorized notified bodies.
Contact us for more information:
Comments