Upcoming IoT Security Legislation: The EU Cyber Resilience Act – Part 1

Introduction

Crypto Quantique have been publishing blogs on upcoming IoT legislation. The previous piece covered was the UK’s PSTI Act, and a subsequent blog examining vulnerability disclosure. This week and next will be discussing the European Union’s Cyber Resilience Act, looking at what it contains and what compliance might look like.

Background

The Cyber Resilience Act (CRA) is a piece of legislation currently in the process of being enacted in the European Union (EU). The purpose of this work is to increase the security of connected devices used by consumers and businesses. When a breach occurs at a company, the company is unlikely to be the only organisation affected, as the impact often ripples down a supply chain, with many stakeholders feeling the repercussions. While manufacturers will likely be the entities most responsible for the majority of these requirements, impact to the supply chain is considered with this piece of legislation and so distributors and importers will also be required to be compliant. The CRA will guarantee a harmonised set of rules for bringing connected devices to market, a framework for cyber security requirements for the whole development and lifecycle for IoT, and an obligation for a duty of care for the entire lifecycle of these products. Compliant products will receive a CE mark to indicate its compliance. The legislation is currently in the late stages and is expected to come into effect in early 2024, following which manufacturers and other defined stakeholders will have up to 36 months to become compliant.

EU Member States will appoint a Market Surveillance Authority in the country who will be the entity responsible for managing enforcement of the CRA. In cases of non-compliance, these bodies will require companies to comply or face their product withdrawn or restricted from entry to the market. Additionally, fines of up to 15,000,000 Euros or 2.5% of worldwide turnover, whichever is higher, can be issues to non-compliant companies.

While much of the industry are thankful governments are taking action in the area of IoT security, this piece of legislation isn’t without its opposition. Some concerns surround the cost of compliance that organisations will have to face. However, the primary concerns were raised by the open-source software (OSS) community. In its original format, the CRA did have an exemption for OSS, but only if the project is developed benevolently. Meaning that if a project were to rely on donations or corporate sponsors, for example, it would not be exempt. The CRA, in its early state, would have negatively impacted the OSS community greatly. In spite of that, the OSS community continued to raise concerns until key stakeholder issues were taken on board by policymakers. The CRA has now broadened its exemptions of OSS and defined another economic actor, “open source stewards”, acknowledging the role that foundations play in open-source development. This late change has eased the OSS community’s concerns but there is still questions surrounding large commercial projects that use OSS elements that will require the CE marking.

Scope

The CRA finds any product with digital elements as in scope. Other than a few exceptions, devices with digital elements with a data connection to another device or network are required to be compliant with this legislation. The majority of these products will fall into the default category for the CRA, meaning manufacturers will be able to self-certify, the remaining products will be defined as critical products and will fall into one of two elevated categories; requiring additional steps for certification.

This will include hardware such as smartphones, smart speakers, and thermostats, but will also include software like password managers and word processing tools. Non-commercial products such as medical or critical national infrastructure are out of scope of these requirements as they are already covered by other pieces of legislation. The entity responsible for compliance is the one who places the product into the market.

What does it require?

At the beginning of a device lifecycle is the design, development and production phase. The CRA requires that security is a addressed throughout all three of those steps; this is a secure by design philosophy. Additionally, a later requirement ensures that products are able to be delivered in a secure default state, a secure by default philosophy.

The product should be protected from unauthorised access using appropriate control mechanisms. This could be authentication, device identities, or other methods. Furthermore there are requirements related to protecting the integrity and confidentiality of data both at rest and in transit, as well as the minimisation of data; processing only what is necessary for the product to function as intended.

The device should be designed, developed and produced in a manner that reduces the exposed attack surfaces and mitigates the impact of cyber incidents. What’s more, devices should protect essential functions by being resilient to attacks such as denial of service attacks. Devices should also minimise their impact to the availability of services provided by other devices or networks.

Beyond the device design requirements, there are requirements related to how vulnerabilities are managed. Firstly products must shipped without any known vulnerabilities. Manufacturers are required to identify and document vulnerabilities and components more generally in what’s known as a software bill of materials (SBOM)

Furthermore, products must be able to address vulnerabilities using security updates, and following a security update users must be notified and information must be publicly disclosed related to the fix. Manufacturers must implement and enforce a Coordinated Vulnerability Disclosure policy – see our previous blog on CVD.

Conclusion

Next week Crypto Quantique will continue the look at the CRA and examine what compliance might look like as well as a deeper dive into some elements of the legislation.