Friend or Foe? Either Way, the Cyber Resilience Act Is Coming

The European Commission has technology vendors and sellers in its sights. Consumers and businesses have been plagued by poorly designed, engineered and maintained software and hardware for too long. It claims the cybercrime economy is the primary beneficiary of these failings, which the commission says was worth €5.5 trillion (£4.7tr) in 2021. The scale of the challenge is huge. The number of new software vulnerabilities reported by the US government in 2022 increased by a quarter annually to hit 25,096 – yet another record high.

The EU’s response is the Cyber Resilience Act (CRA). Although it’s still being finalised, some have argued that its provisions threaten the open-source community and could even make the digital world less safe.

What’s in the CRA?

The CRA aims to protect consumers and businesses buying products with a “digital component”. It seeks to address two key challenges:

• The poor cybersecurity measures built into many products, including software and connected devices like smart baby monitors, and/or inadequate updates to software and devices
• The lack of an industry-wide “kite mark” which could help technology buyers better understand which products are secure and how to set them up securely

With this in mind, the CRA aims to:

• Harmonise rules across the bloc for manufacturers and retailers developing/selling digital products
• List a strict set of cybersecurity requirements “governing the planning, design, development and maintenance” of these products
• Oblige relevant manufacturers/resellers to provide a duty of care for the entire lifecycle of digital products
• Roll out a new CE mark indicating products are CRA-compliant, thus incentivising manufacturers and retailers to prioritise security and empowering IT buyers to make better-informed decisions

What’s Covered And What’s Required?

As it stands, the legislation will “apply to all products connected directly or indirectly to another device or network except for specified exclusions such as open source software or services that are already covered by existing rules, which is the case for medical devices, aviation and cars.”

These products are split into three categories:

Default: Low-risk products like smart toys and fridges, video games and other commonly used software and devices, which the commission claims cover 90% of the market. Companies will be required to conduct a self-assessment to ensure a product meets the relevant security standards.

Class I: High-risk products, including identity and access management software; browsers; password managers; malicious software detection tools; products using VPNs; network management configuration, monitoring and resource management tools; security information and event management (SIEM) systems; patch management tools; mobile device and app management software; remote access software; microcontrollers; operating systems; firewalls; routers and modems; industrial control equipment; and any industrial IoT not covered in Class II.

Class II: Even higher risk products than Class I. Includes some operating systems; firewalls; microcontrollers; industrial routers and modems; switches; smart cards and readers; secure elements; hardware security modules; smart meters; intrusion detection; robot sensing and actuator components; and IIoT devices used by entities described in NIS 2.

Where the same product types are listed in Class I and II, the correct tier will be decided according to risk factors such as whether a product runs in sensitive NIS 2 environments, runs with privileged access, is used to process personal information, contains a vulnerability which could affect a “plurality” of people; or whether it has already caused adverse effects.

Annex I describes the security requirements for manufacturers of digital products. They should:

• Be designed, developed and produced to ensure an “appropriate” level of security
• Be delivered free of known exploitable vulnerabilities
• Be delivered with secure-by-default configuration
• Ensure protection from unauthorised access
• Protect the confidentiality and integrity of personal and other data
• Process only the minimum amount of data necessary
• Protect the availability of essential functions, such as from DDoS attack
• Be designed, developed and produced to limit attack surfaces and reduce the impact of incidents
• Monitor internal activity to provide relevant security-related information

Annex I also provides a lengthy list of requirements for vulnerability handling, including that manufacturers document and, address and remediate vulnerabilities without delay, regularly test product security, and publicly disclose information on any bugs they fix. The CRA also demands developers enforce vulnerability disclosure policies, share information about bugs, provide a way to distribute security updates, and do so without delay and free of charge.

Reporting And Conformity Requirements

While default class manufacturers can effectively self-assess whether a product is market-ready, those in Class I must undergo third-party conformity assessment or apply harmonised standards. Alternatively, they could apply European cybersecurity certification schemes to their products. Those in Class II must go through a third-party conformity assessment.

The CRA also requires manufacturers to notify the security agency ENISA within 24 hours of becoming aware of an actively exploited vulnerability or security incident. Importers and distributors must similarly inform manufacturers of any new bugs without delay and potentially national market surveillance authorities in the case of serious risks.

Could An ISMS Help Manufacturers?

With non-compliance penalties set at €15 million or 2.5% of annual turnover, all in-scope organisations must consider how they adapt to the new regime. Hunton Andrews Kurth partner, David Dumont, tells ISMS.online that organisations in some sectors, like IoT medical device manufacturers, may already have a head start due to existing regulatory demands. His fellow partner at the law firm, Sarah Pearce, adds that organisations fully compliant with GDPR, which demands “robust security controls and related policies and procedures”, should find compliance with the CRA “achievable with limited adjustment”.

However, it may not all be plain sailing.

“Compliance with stringent conditions for introducing and keeping digital products on the EU market may result in additional costs,” warns Dumont. “Any such additional compliance costs may make it more difficult for small and medium-sized companies to compete on the digital market and may hinder technological advancement.”

This is where an Information Security Management System (ISMS) could help by supporting ISO 27001 compliance and those robust GDPR-mandated controls, policies and procedures cited by Pearce.

“There is an overlap between existing European and international cybersecurity standards such as ISO 27001 and some of the key cybersecurity requirements in the CRA,” explains Dumont. “Companies that adhere to such existing standards will be able to leverage this when tackling CRA compliance.”

What Are The Potential Issues?

Some have welcomed the commission’s attempt to improve baseline security and transparency among tech products. Veracode EMEA CTO John Smith describes it as a “landmark piece of legislation.”

“It not only brings more transparency to an area that is often opaque, but also encourages software vendors, manufacturers, and retailers to increase cybersecurity for the products they sell, as well as helping buyers easily select products that are robust,” he adds. “Hopefully, this will incentivise organisations to go above and beyond the mandatory requirements and put security higher up the agenda.”

However, others have grave concerns. Non-profit rights group the Electronic Frontier Foundation highlights two potentially serious implications if the CRA is passed in its current form:

Open source: Any open source developer soliciting donations or charging for support services for their software is liable for damages if their “product” contains a bug which makes its way into other products. Given the complex, interconnected nature of the open-source software supply chain, this could have a chilling effect on the industry and may force developers to abandon the region altogether.

Vulnerability disclosure: First, the very short (24-hour) timeframe for reporting new vulnerabilities to ENISA could encourage quick but “shallow” fixes which don’t address the root cause of issues. Second, ENISA subsequently reports to member states’ Computer Security Incident Response Teams (CSIRTs) and market surveillance authorities. The EFF is concerned that government hackers could exploit this vulnerability information and/or leak out to the cybercrime community.

Unfortunately, it doesn’t appear that lawmakers will heed these concerns.

“With cyber-attacks undeniably on the rise in recent years, to huge economic and societal impact, the need for some governmental intervention is clear and arguably outweighs such concerns,” concludes Pearce.