EU Cyber Resilience Act Raises the Cybersecurity Bar for Digital Products
EU Cyber Resilience Act Raises the Cybersecurity Bar for Digital Products
The EU Cyber Resilience Act (the CRA) is one legislative step away from becoming law and focuses on bolstering the cybersecurity of products with digital elements (PDE). PDEs include software and Internet of Things devices (such as smart fridges and connected toys) and the CRA’s extra-territorial reach will affect organizations along the entire PDE supply chain. So if your organization is involved in the creation, distribution (including import), or sale of PDEs on the EU market, it will likely be caught under this new regulation, regardless of where your organization is based or where the PDE is manufactured. In-scope organizations will need to evaluate and up their cybersecurity game to meet the CRA’s obligations; however, many organizations can also leverage their existing policies and procedures (such as current reporting procedures) to comply with these new rules.
The CRA’s general approach to scope is broad and the definition of PDE is no exception to this. In-scope PDEs are defined by two key criteria. Firstly, the PDE must have been “made available” on the EU market during an organization’s commercial activities, which implies that a PDE that is developed and solely used for internal purposes is not in scope. Secondly, it must be intended (or reasonably foreseeable) that the PDE will be used for a data connection to a device or network. This connection can be direct or indirect and can be virtual or physical (such as implementation through software or through wires or radio signals). So software—including free and open-source software—and hardware products can all fall under the CRA’s regime.
What makes the CRA’s scope even broader is that “components” of PDEs (if placed on the EU market separately) and PDEs’ “remote data processing solutions” are also in scope. The latter means that the CRA catches any software that is designed and developed by a manufacturer, or is under their responsibility, so long as the PDE cannot perform one of its functions without the software. So, for example, a mobile app (provided by a smart home device manufacturer) that lets users remotely control their devices would fall under the CRA as a remote data processing solution.
However, the CRA does carve out specific exceptions from its scope, including certain products that are already covered by sector-specific legislation (e.g., medical devices), as well as cloud computing and cloud services models (e.g., Software as a Service, Platform as a Service, or Infrastructure as a Service) that are not part of a PDE offering (i.e., as remote data processing solutions) or that are already subject to the NIS2 Directive. PDE spare parts also escape the grasp of the CRA if they are made available to replace identical components in a PDE and are made to the same specification as the original components.
What Does the CRA Mean in Practice?
The CRA requires in-scope organizations to minimize and address cybersecurity throughout the entire PDE lifecycle, with the strictest obligations imposed onto manufacturers and developers.
1. Essential cybersecurity requirements: Only PDEs that meet the CRA’s “essential cybersecurity requirements” will receive the green light to enter the EU market. These requirements include protecting the availability of a PDE’s essential and basic functions, as well as allowing users to securely and easily remove all data and settings permanently. For many organizations, these requirements might look familiar, since they are not novel and just codify existing good practice.
2. Assessments for “important” and “critical” products: The CRA also has checks to ensure that organizations are, in fact, living up to the minimum cybersecurity standards that it imposes. All PDEs will need to pass a conformity assessment procedure for this reason, but PDEs that are classified as “important” or “critical” will face a more formal assessment, either by a central EU body or the European cybersecurity certification scheme. These types of PDEs include smart home virtual assistants, network management systems, and firewalls, as well as hardware devices with security boxes and smartcards.
3. Conformity requirements: To further drive home the requirement for conformity, the CRA calls on manufacturers and developers to obtain an EU declaration of conformity for each PDE, and the “CE” conformity mark must be affixed to the PDE itself or the product label. Also, before PDEs can make their way onto the EU market, organizations will need to draw up (and continuously update) certain technical documentation, including a cybersecurity risk assessment.
4. Vulnerability handling requirements: Tackling vulnerabilities is at the top of the CRA’s priority list, and manufacturers and developers will need to offer customers a support period of at least five years to help with handling vulnerabilities (unless the PDE’s lifetime is shorter than five years). Organizations will also need to meet baseline vulnerability handling requirements, such as putting in place appropriate policies and procedures for addressing vulnerabilities.
5. Reporting obligations: While notification requirements may no longer come as a surprise under digital regulations, the CRA takes a unique, multi-pronged approach to tackle “severe” incidents as well as actively exploited vulnerabilities. Manufacturers and developers will find themselves with more stringent obligations (as set out in the table below) compared to their importer and distributor counterparts. In particular, the former will need to provide multiple, time-staggered notifications to the European Union Agency for Cybersecurity (“ENISA”) and must also notify users of such incidents or vulnerabilities in a timely manner. By contrast, importers and distributors have limited, one-time reporting obligations (e.g., they must immediately inform market surveillance authorities of “significant” cybersecurity risks and inform manufacturers, without undue delay, after they become aware of a vulnerability).
Manufacturers and Developer Notifications to ENISA | |
Type of Notification | Notification Deadline |
Early warning | Without undue delay and in any event within 24 hours of becoming aware of the “severe” incident or actively exploited vulnerability (even if a vulnerability patch is not yet available) |
Incident or vulnerability notification | Without undue delay and in any event within 72 hours of becoming aware of the incident or vulnerability |
Final report | For incidents: Within one month of the incident notification above For vulnerabilities: No later than 14 days after a corrective or mitigating measure is available |
6. Verification obligations for importers and distributors: Interestingly, the CRA will also add obligations so that different parties along the supply chain keep each other in check. For instance, before they can place PDE onto the EU market, importers and distributors bear the responsibility for having provided certain information pertaining to the PDE, such as the manufacturer’s name, address, and contact details and the end date of the PDE support period. In addition, importers are required to verify that the manufacturer has carried out a conformity assessment and that it has the appropriate technical documentation in place. These verification obligations add another layer of cyber compliance to both importers and distributors’ own existing obligations (which include ensuring that the PDEs have the necessary CE mark).
ENISA will be overseeing regulation of the CRA at an EU-level, with market surveillance authorities covering enforcement at national level. Keeping up the trend of other EU digital frameworks, these regulators will be able to impose fines of up to €15 million or 2.5% of an organization’s global annual turnover (whichever is higher). The CRA goes even further than some of its digital predecessors, such as NIS2 and DORA, by explicitly allowing regulators to penalize organizations that provide incorrect, incomplete, or manipulated information in response to a market surveillance authority’s request—with fines of up to €5 million or 1% of global annual turnover (whichever is higher). Consequently, organizations could find themselves balancing response deadlines on one hand and providing complete and accurate information on the other. This difficult balancing exercise should encourage those in scope to maintain robust cybersecurity practices and records at all times (to avoid the risk of scrambling to gather the requested information under time pressure).
The current available version of the CRA is the version approved by the European Parliament. The final hurdle for the CRA will be adoption by the European Council, which is expected to proceed in the next few months without any draft amendments. After the CRA comes into force, the clock will start ticking (albeit rather slowly) for organizations and Member States, which will have three years to comply with most of the CRA’s new requirements. However, manufacturers and developers will need to get up to speed slightly earlier, with their reporting obligations applying 21 months after the CRA comes into force.
Michal Pati and Jacqueline Lee, London Trainee solicitors, contributed to the drafting of this alert.
Practices
Industries + Issues
Regions