EU Cyber Resilience Act
The Cyber Resilience Act (CRA) exists to bolster cyber security for the EU. But it has not been without controversy. Many open-source organisations have criticised the act for creating ‘a chilling effect on open-source development.’
The proposal spells out defence and resilience on several fronts. One is to protect consumers from vulnerabilities on the Internet of Things (i.e. ‘smart’) devices. It also covers developing protection from supply chain vulnerabilities, and resilience from hacking attacks, putting the responsibility for cyber security by design squarely on manufacturers. The proposal states that it intends to make the EU a cyber security leader and ‘change the rules of the game globally.’ So far, so ambitious.
Compliance and Consequences
The failure of organisations to comply with the Act will result in fines of up to $15 million, or 2.5% of the offending organisation’s worldwide turnover. The act has just passed so it’s crucial for organisations to understand their responsibilities.
Understanding the EU Cyber Resilience Act
The first point of call in the regulation is about the context of the proposal. It sets out the size of the problem we face as cyber security professionals: the cost of cybercrime in Europe, per year rises exponentially. There are two reasons for this: a low level of cyber security for hardware and software products, which is reflected by widespread vulnerabilities and the insufficient, inconsistent provision of security updates to address these vulnerabilities. The second problem is stated as insufficient understanding and access to information by users. What information? The information that would allow users to choose products with adequate cyber security properties, or the information to use the products securely.
The reason to take this seriously, it goes on, is because a cyber security incident in one product can affect an entire organisation or a whole supply chain. It’s this cascade of one problem, affecting everything downstream from it, that the regulation seeks to stem. Ultimately, it’s about preventing severe disruption of economic and social activities, and in the worst cases, resulting in life-threatening outcomes. We are all increasingly connected, across borders and markets – but without diligent protections, an incident can spread, with dangerous rapidity, across these boundaries.
To achieve its aim, the regulation identifies two main objectives: Primarily, to create conditions for the development of secure products with digital elements by ensuring that hardware and software products are placed on the market with fewer vulnerabilities and ensure manufacturers take security seriously across a product’s lifecycle. The second objective is to create conditions allowing users to take cyber security into account when selecting and using products with digital elements.
It sets out specific objectives: 1) To create conditions for the development of secure products with digital elements by ensuring that hardware and software products are placed on the market with fewer vulnerabilities and ensure manufacturers take security seriously throughout the lifecycle of a product and 2) Create conditions allowing users to take cyber security into account when selecting and using products with digital elements. The point is to make the manufacturers accountable for the security of their products over the whole lifecycle. To get there, the proposal prescribes a coherent cybersecurity framework that facilitates compliance for hardware and software producers. Ultimately, the aim is to enhance the transparency of the security properties of products with digital elements to enable businesses and consumers to use these products securely.
Due to the cross-border nature of cyber security, all member states must act together to raise collective defences. Unless more accountability and mitigations are taken by all member states, the protective outcomes will be minimal. The cyber security of the entire supply chain is ensured only if all its components are cyber-secure.
Key Components of the Cyber Resilience Act – Legal Basis
The legal basis for the proposal is Article 114 of the Treaty on the Functioning of the European Union (TFEU) which provides for the adoption of measures to ensure the establishment and functioning of the internal market.
The point is to prevent issues occurring from diverging national laws and create greater legal certainty for operators and users across the Union, as well as better harmonization of the European single market, creating more viable conditions for operators aiming at entering the EU market.
Proportionality
The regulation aims to implement measures, but those measures do not go beyond what is needed to achieve its objectives, and it does not impose disproportionate costs.
Stakeholder Engagement
The Commission has consulted a broad range of stakeholders. Member States and stakeholders were invited to participate in the open public consultation, surveys and workshops.
The consulted stakeholders included national market surveillance authorities, union bodies dealing with cyber security, hardware and software manufacturers, importers and distributors of hardware and software, trade associations, consumer organisations and users of products with digital elements and citizens, researchers, and academia, notified bodies and accreditation bodies, and cyber security industry professionals.
Anticipated Benefits
For Europe, it is estimated that the initiative could lead to a cost reduction from incidents — affecting companies by roughly EUR 180 to 290 billion annually. It would lead to an increased turnover due to the uptake of products with digital elements demand.
It would also improve the companies’ global reputation leading to a demand uptake outside the EU.
Product Classification
Annex 3 of the proposal spells out the two classes of critical products with digital elements.
Class one products are considered lower risk than those in Class two.
Class I
- Identity management systems software and privileged access management software.
- Standalone and embedded browsers.
- Password managers.
- Software that searches for, removes, or quarantines malicious software.
- Products with digital elements with the function of a virtual private network (VPN).
- Network management systems.
- Network configuration management tools.
- Network traffic monitoring systems.
- Management of network resources.
- Security information and event management (SIEM) systems.
- Update/patch management, including boot managers.
- Application configuration management systems.
- Remote access/sharing software.
- Mobile device management software.
- Physical network interfaces.
- Operating systems not covered by class II.
- Firewalls, intrusion detection and/or prevention systems not covered by class II.
- Routers, modems intended for the connection to the internet, and switches, are not covered by class II.
- Microprocessors not covered by class II.
- Microcontrollers.
- Application-specific integrated circuits (ASIC) and field-programmable gate arrays (FPGA) intended for the use by essential entities of the type referred to in [Annex I to the Directive XXX/XXXX (NIS2)].
- Industrial Automation & Control Systems (IACS) not covered by class II, such as programmable logic controllers (PLC), distributed control systems (DCS), computerised numeric controllers for machine tools (CNC) and supervisory control and data acquisition systems (SCADA).
- Industrial Internet of Things not covered by class II.
Class II
- Operating systems for servers, desktops, and mobile devices.
- Hypervisors and container runtime systems that support virtualised execution of operating systems and similar environments.
- Public key infrastructure and digital certificate issuers.
- Firewalls, intrusion detection and/or prevention systems intended for industrial use.
- General purpose microprocessors.
- Microprocessors intended for integration in programmable logic controllers and secure elements.
- Routers, modems intended for the connection to the internet, and switches, intended for industrial use.
- Secure elements.
- Hardware Security Modules (HSMs).
- Secure crypto processors.
- Smartcards, smartcard readers and tokens.
- Industrial Automation & Control Systems (IACS) intended for the use by essential entities of the type referred to in [Annex I to the Directive XXX/XXXX (NIS2)], such as programmable logic controllers (PLC), distributed control systems (DCS), computerised numeric controllers for machine tools (CNC) and supervisory control and data acquisition systems (SCADA).
- Industrial Internet of Things devices intended for the use by essential entities of the type referred to in [Annex I to the Directive XXX/XXXX (NIS2)].
- Robot sensing and actuator components and robot controllers.
- Smart meters.
Requirements
Technical Documentation
Each relevant organisation shall submit technical documentation that contains all relevant data or details of the means used by the manufacturer to ensure that the product with digital elements and the process put in place by the manufacturer, complies with the essential requirements set out in Annex I.
Essential Requirements
In Annex I, the security requirements relating to the properties of products with digital elements are as follows.
Products with digital elements shall be designed, developed, and produced in such a way that they ensure an appropriate level of cyber security based on the risks. Products with digital elements shall be delivered without any known exploitable vulnerabilities. Based on the risk assessment referred to in Article 10(2) and where applicable, products with digital elements.
Reporting Obligations of Manufacturers
The emphasis is on giving manufacturers more accountability. Article 11 states that the manufacturer shall ‘without undue delay and in any event within 24 hours of becoming aware of it, notify to ENISA any actively exploited vulnerability (or infosec incident) contained in the product with digital elements.’ This notification must include details of the vulnerability and, where relevant, corrective, and mitigating measures taken. It’s also required that the manufacturer inform its users of their product of any such incident, along with mitigation strategies.
The next step involves ENISA forwarding the notification to the CSIRT designated for coordinated vulnerability disclosure.
Current Status of the Proposal
The European Commission, Council and Parliament have agreed on the text of CRA, and it’s now fully approved legislation.
However, there have also been concerns amongst open-source developers who rely on monetary compensation for their work. The reporting requirements of the Act mean that knowledge and exploitation of these vulnerabilities could be exposed to a large audience, potentially undermining the intent of the Act itself. Therefore, the fate of the proposal, and its transition into regulation, hinges on the assessment by Member States of the associated risks.
To get compliance-ready, speak to one of our experts and watch this space as we keep you updated on all the latest cyber security developments.
