Endpoint Security
,
Geo-Specific
,
Internet of Things Security
European Commission Publishes Draft Guidance for Cyber Resilience Act
As deadlines approach for one of Europe’s pivotal cybersecurity initiatives, the European Commission has released draft guidance aimed at helping manufacturers navigate the complexities of compliance with the Cyber Resilience Act (CRA). This ambitious legislation, which was approved in 2024, is designed to impose security standards on a wide range of internet-connected products. These include everything from smart refrigerators and mobile phones to various applications and cloud services.
The Cyber Resilience Act is positioned to echo the influence of the EU General Data Protection Regulation (GDPR), which reshaped global data management practices. By enforcing security-first design principles, the CRA will necessitate comprehensive cybersecurity assessments for any company intending to market its digital products in the European single market. Without obtaining the critical CE marking of conformity, manufacturers will find it nearly impossible to enter or compete within this significant marketplace.
Beginning in December 2027, manufacturers will be required to ensure timely security updates for their connected devices and software. This overhaul will involve thorough supply-chain risk assessments and the deployment of security measures such as data protection by design. The first deadline is imminent, scheduled for this September, when manufacturers must begin reporting actively exploited vulnerabilities and certain serious security incidents to the European Union Agency for Cybersecurity (ENISA). The task of enforcing compliance will fall largely to national market surveillance authorities, which will monitor adherence to the CRA’s mandates.
In the wake of the CRA’s passage, many corporations raised pertinent questions regarding the practical implications of the law. Specific concerns included whether open-source software projects would face stringent regulatory requirements, the standard for security updates, and which types of cloud services would be affected. The regulation stipulates that products must receive security updates for a minimum of five years—leading to uncertainty over how to handle long-lasting versus short-lived products. Additionally, businesses have sought clarity on how to interpret the requirement for disclosing security vulnerabilities within 24 hours, particularly concerning the timing of awareness of such vulnerabilities.
Earlier this month, the European Commission published draft implementation guidance on the CRA. Manufacturers, along with developers and other stakeholders, have until April 13 to submit their feedback. Legal experts like Ceyhun Pehlivan, based in Madrid, have noted the guidance addresses many of the practical concerns previously expressed by companies. However, he cautioned that some of the most complex issues, such as software updates and cloud service dependencies, remain challenging to regulate effectively.
Pehlivan characterized the draft guidance as a robust advance, stating, “It answers many practical questions companies had. However, it also highlights that certain difficult issues, including those related to software updates, are inherently complex.” He emphasized that the guidance clarifies which products fall under the CRA’s ambit, particularly with regard to software, which often defies clear categorization under existing EU product regulations. Notably, the guidance specifies that software available for download or remote access in the European market is subject to the CRA, with exceptions made for products that do not possess network connectivity. Importantly, activities related to providing sample or demo code for demonstration purposes are not covered under the regulation.
Further clarity is provided regarding the parameters governing cloud services or software-as-a-service (SaaS) products. The draft guidance introduces a three-question evaluation to determine whether these services qualify as remote data processing solutions under the CRA. If a service does not process data “at a distance,” it falls outside the CRA’s scope. Conversely, if a product requires such processing but its absence wouldn’t impede its core functionality, it is treated merely as a component requiring due diligence. These specifications underline the need for manufacturers to be acutely aware of their back-end systems, as entities like Amazon Web Services are generally classified as components under this framework.
While the draft offers some respite for open-source software contributors, it also presents conundrums for those looking to commercialize their work. Contributors who do not control releases or governance decisions will not trigger specific CRA requirements, which are activated only when the software is commercialized or when personal data processing is a condition for usage. Thus, the free version of a software product does not fall within CRA’s jurisdiction.
The Open Regulatory Compliance Working Group, which advocates for open-source interests, responded to the draft guidance with nuanced optimism. Juan Rico, a senior manager at ORC and an employee of the Eclipse Foundation, remarked that the European Commission is responding attentively to constructive feedback from the technical community. Nevertheless, he noted that additional areas still require clarification to benefit both regulatory bodies and the broader ecosystem.
Experts like Pehlivan also anticipate potential legal ambiguities for software vendors who frequently update their products. Significant modifications made during updates could classify a product as newly launched under the CRA, especially if such changes affect the cybersecurity compliance of the product. This regulatory complexity raises questions over whether an app update constitutes a “substantial modification,” placing the final determination in the hands of supervisory authorities.
On pressing issues, the draft guidance resolves pivotal questions, particularly regarding the forthcoming September reporting deadline. It stipulates that companies must notify ENISA and their national computer security incident response teams within 24 hours of discovering an actively exploited vulnerability. Notably, this timeframe does not extend to the period required for verification of the vulnerability.
The draft also clarifies that while the security update period is set at a minimum of five years, this timeframe acts as a baseline. If a product is intended for use beyond this timeframe, it should receive corresponding security updates. At the same time, manufacturers will be mandated to inform customers at the point of purchase about the end date of the support period, specifying this at least down to the month and year. They will also be required to provide notifications to users once the support period elapses, where technical capabilities allow for such actions. This reiteration of clarity is crucial for enterprise software, where the product lifecycle typically extends beyond the advertised terms, necessitating careful forecasting and management of support expectations.