12 minutes to read With insights from... Piet De Vaere Lead Security Architect piet.devaere@zuhlke.com Sofie Daniëls Trainee Cybersecurity sofie.daniels@zuhlke.com As products continue to evolve towards greater digitalisation and connectivity, they increasingly become targets for cyber threats, as we've illustrated in our previous article. The EU has recognised this threat and is now responding with a new piece of legislation – the European Cyber Resilience Act (CRA). This act outlines a series of preventative measures that are aimed at improving the cybersecurity of products made available in the EU. In this article, we will discuss who is affected by the CRA, what product adjustments should be made to fulfil the new cybersecurity requirements, and what documentation and processes should be prepared internally to ensure compliance with this new legislation. What is the Cyber Resilience Act? The CRA, or Cyber Resilience Act, is an upcoming piece of EU legislation that aims to enhance the cybersecurity of ‘products with digital elements’. In practice, the law covers all products that exchange data with another device or network. The law also covers any remote data processing that is part of a product, such as the use of a cloud backend. The CRA outlines minimum requirements for the security of these products. It also mandates manufacturers to follow specific processes for product development and support. If your company manufactures, imports, or distributes a product that is available in the EU and that performs any type of data communication, you are most likely affected by the CRA. After long negotiations, the CRA is now in the final steps of its legislative process. It was accepted by the EU parliament on March 12, 2024, and is expected to enter into force in mid-2024. Next, compliance requirements will be introduced in two steps: 21 months after final adoption (i.e. early 2026), compliance with the reporting requirements of the text (see below) will be required. 36 months after final adoption (i.e. mid 2027), full conformity by manufacturers, importers, and distributors will be required. Timeline of the eu cyber resilience act implementation and compliance deadlines (Figure 1: Key dates and deadlines around the enactment of the CRA.) ' It may seem like there is still plenty of time before the Act comes into force. But the CRA's requirements can have a significant impact on your development and support operations, so organisations should start implementing the necessary changes today. ' Piet De Vaere Lead Security Architect at Zühlke Although these grace periods may seem generous at first, this impression can be deceiving. The CRA’s stipulations could significantly impact your development and support workflows, and timely implementation of the required changes may demand considerable effort. Moreover, it is critical to ensure that these changes are supported by all levels of the organisation. That’s why we strongly advise to allocate sufficient time for a phased approach to achieving CRA compliance, instead of rushing the process. Depending on the type of violation, failure to conform to the CRA can incur fines of up to 15 million euros, or 2.5% of a company’s worldwide annual turnover, whichever is higher. So, it’s definitely worth planning for CRA compliance as soon as possible. The CRA at a glance Download our one-pager and see the most important facts. Didn’t the EU already regulate cyber security with the NIS2 directive and the RED? CRA vs NIS2 What distinguishes the CRA from the EU’s NIS2 directive is its focus on products. Although both the CRA and NIS2 aim to improve... What distinguishes the CRA from the EU’s NIS2 directive is its focus on products. Although both the CRA and NIS2 aim to improve the cyber security stance of the union, the CRA takes a fundamentally different approach. Concretely, while the CRA regulates product security, NIS2 regulates the security practices of critical organisations, such as utility companies and manufacturing plants. Moreover, even though NIS2 uses the term ‘critical’ liberally, many more organisations will be affected by the CRA than by NIS2. Most notably, organisations outside the EU are not typically subject to NIS2 but are subject to the CRA if their products are made available in the EU. This is similar to how the GDPR affects companies outside of the union if they target their services at union residents. CRA vs RED The Radio Equipment Directive (RED) is a regulatory framework for placing radio equipment on the EU market. In 2022, an amendment... The Radio Equipment Directive (RED) is a regulatory framework for placing radio equipment on the EU market. In 2022, an amendment was added, outlining security requirements for internet-connected radio equipment and radio equipment that processes data. More specifically, depending on the type of device involved, the amendment requires radio equipment to protect users against privacy loss and fraud, and to protect networks against disruptions. These changes will be effective from August 2025 onwards. Unlike the RED, the CRA applies to any product with digital elements, not just to radio equipment. In addition, although aligned with the cybersecurity requirements of the RED, the requirements specified in the CRA are far more extensive and comprehensive. It is likely that, over time, the CRA will replace the security requirements of the RED. Figure 2: NIS2 vs. CRA vs. RED What products are affected by the Cyber Resilience Act? The CRA covers all products that exchange data. This includes data exchanges that take place over a network but also those that occur through a direct connection with another device. That said, there are several limitations to the CRA’s scope: First, the CRA only covers products that are made available as part of a commercial activity. It does not matter if a fee is charged for the product or not. For example, free products that come with (optional) paid maintenance plans or that collect user data are not exempt. Second, exemptions are made for the following products covered under existing EU legislation – medical devices, marine equipment, aviation equipment, and motor vehicles and their components. Third, products developed exclusively for national security or defence purposes are also exempt. Fourth, the CRA does not cover services that are not related to a product. Examples of such services include cloud applications (e.g. Dropbox) and search engines (e.g. Google Search). However, any remote (e.g. cloud) data processing without which a product cannot perform one of its functions is considered part of that product and must comply with all CRA requirements. Update 25.10.2024: We removed a statement about “products already available on the market”, as it is prone to misinterpretation. In principle all products sold on the EU market after the CRA grace period must be fully CRA-compliant. Crucially, the CRA does not distinguish between products originating from countries within and countries outside of the EU, it simply covers all products ‘made available on the EU market’. So, the CRA fully applies to companies based in non-EU countries when they intend to release their products in the EU. To guarantee accountability throughout the entire supply chain, the law includes several requirements for importers and distributors. ' The CRA is fully applicable to companies based in non-EU countries when they intend to release their products in the EU. ' Piet De Vaere Lead Security Architect at Zühlke What does the CRA mean for my business? If you plan to release a product on the EU market, you are likely affected by the CRA. Roughly speaking, the CRA mandates that all products must be secure by default, with requirements including no known vulnerabilities, secure configuration, and robust access control. Products must also remain compliant during a support period, with manufacturers responsible for maintaining conformity. Security must also be considered throughout product development, including regular testing and careful use of third-party components. Additionally, manufacturers must effectively manage product vulnerabilities, have a single point of contact for users, and provide comprehensive documentation for both users and the EU. We discuss these requirements in more detail in the boxes below. Product requirements Product requirements The CRA requires all products to be secure by default. To achieve this, the CRA lists the following concrete requirements: Products must be made available without any known exploitable vulnerabilities. Products must have a secure-by-default configuration. Products must have sufficient access control mechanisms and should detect and report unauthorised access attempts. The confidentiality and integrity of stored, processed, and transmitted data must be protected. Data processing should be minimised to what is necessary for the normal functioning of the product. Products must be designed to be resilient against Denial of Service (DoS) attacks and manufacturers must minimise an attack’s negative effects on the availability of other devices or networks. The attack surface of the product and the impact of any security incidents should be minimised. It should be possible for users to transfer and remove their data easily and securely. Support requirements Support requirements Not only must products meet the base product requirements when they are released, they must also be kept in compliance during a mandated ‘support period’. The duration of this support period should be set to reflect ‘the length of time during which the product is expected to be in use’. In general, the support period should last at least five years, and should be communicated to the customer at the time of purchase. During the support period it is the manufacturers duty to ensure product conformity. When there is reason to believe that the product requirements listed above are no longer satisfied, the manufacturer must take the necessary steps to bring the product back into conformity, for example through a software update. Non-conformity of a product could lead to forced withdrawal of the product from the market as well as product recalls. Requirements on development and post-production Requirements on development and post-production To design products that meet the base product requirements it is important to consider security throughout a product’s development process. Therefore, the CRA includes the following requirements: Manufacturers must explicitly assess the cybersecurity risks and requirements of a product during all phases of product development. Manufacturers must conduct regular tests and reviews to actively verify the security of the product throughout the support period. Care must be taken to ensure that third-party and open-source components do not compromise product security. To track product components and the vulnerabilities, the CRA mandates manufacturers to draw up a software bill of materials (SBOM). Vulnerability management requirements Vulnerability management requirements Manufacturers must have processes in place to effectively manage product vulnerabilities. The governing principle is that vulnerabilities must be addressed ‘without delay’. Further, manufacturers must establish a single point of contact for users to communicate ‘directly and rapidly with them’ and should accept vulnerability reports through this point of contact. Additionally, a contact address for reporting vulnerabilities, and a coordinated vulnerability disclosure (CVD)2 policy must be in place and easily available to the general public. Once a vulnerability has been remediated, mechanisms must be in place so that products in the field are quickly patched, for example, through automated security updates or update notifications. If technically feasible, security updates must be kept separate from functionality updates. After an update has been made available, information about the fixed vulnerability must be communicated publicly. If a manufacturer becomes aware of a vulnerability contained in third party components, the component provider must be informed, and if a mitigation was created, it should be shared with the original component provider. Reporting requirements Reporting requirements Manufacturers must submit security-related event reports through a centralised EU reporting platform. There are strict deadlines in place for sharing these reports. Concretely, if a manufacturer becomes aware of an actively exploited vulnerability, or a severe incident that could impact the security of the product or its users, the EU must be pre-notified within 24 hours. Next, within 72 hours of the event, a more comprehensive description of the event must be shared. This notification should include general information about the product and event, as well as the measures taken to combat the issue, and any measures that users can take. For exploited vulnerabilities (see above), a final report with a more detailed description of the events and the implemented security measures should be sent at the latest 14 days after a mitigating measure is available. For severe incidents (see above), this should be done within one month of submitting the initial 72-hour report. In addition, users should be clearly and promptly informed about the events as well as the protective measures they can take themselves. Documentation requirements Documentation requirements Under the CRA, products must be accompanied by a minimum of user-facing documentation. This documentation must include, among others information about: the product manufacturer the single-point of contact for vulnerability management the intended purpose of the product and information of the product’s security properties known circumstances that might introduce cybersecurity risks to the product the duration of the support period instructions for secure product commissioning and use how to install security updates how to enable or disable automatic security updates Beyond the information compiled for product users, manufacturers must maintain an internal repository of ‘technical documentation’ belonging to the product. This documentation must cover a wide variety of topics, from a description of the vulnerability handling process to the results of the cybersecurity risks assessments, and the considerations made when determining the support period. Upon request, this documentation must be provided to the EU. Among other uses, the technical documentation serves as an audit log to ensure that the various process requirements of the CRA were effectively implemented by the manufacturer. How is CRA compliance demonstrated? Depending on the type of product, there are different options available for demonstrating CRA compliance. For most products, manufacturers can simply self-declare that the necessary requirements were met. In this case, it is important to remember that the product’s technical documentation ensures that this declaration can be audited later, e.g. after an incident has occurred. Beyond this self-declaration mechanism, the CRA foresees several other ways to demonstrate regulatory adherence. These come in to play for the so called ‘important’ or ‘critical’ products, depending on a product’s classification, only a subset of the mechanisms may be used. These additional mechanisms are (ordered by increasing assurance level): Adherence to harmonised standards: Conformity is demonstrated by following a so-called harmonised EU standard, followed by the self-declaration procedure. A type-examination based mechanism: Manufacturers obtain a type certification from an EU-designated third party and then declare products to be conforming to the type. Conformity based on full quality assurance: The manufacturer applies a purpose-certified internal quality management system throughout the product’s design and manufacturing process. A European cybersecurity certification scheme: The cybersecurity of the product is certified by the European Union Agency for Cybersecurity (ENISA). The classification of a product into the ‘important’ or ‘critical’ categories is done based on a predefined list. This list can be updated by the European Commission at any point in time, with changes valid after 12 months. Current examples of products included in this list are password managers, smart home products with security functionality (e.g. smart door locks, security cameras), smartcards, and firewalls. For most of these products, following a harmonised standard (if permitted) will likely be the most straightforward way to demonstrate compliance. However, the ongoing experience with the creation of harmonised standards for the RED has demonstrated that these standardisation procedures can be complex and time-consuming. Moreover, the CRA includes many more requirements than the RED. As such, it is currently unclear if the harmonised standards for the CRA will be completed in time. Although the CRA includes provisions for delayed harmonised standards, it is currently not clear what would happen in such a scenario. What are the next steps? The CRA’s requirements are comprehensive and touch on many aspects of product development and delivery. For many companies, achieving compliance might be a lengthy process. As such, we encourage organisations to begin their journey towards CRA compliance as soon as possible. If you want to start your compliance process with us, we’d be happy to hear from you. With our team of cybersecurity experts, we can help you comply with all the requirements, provide advice on addressing vulnerabilities, and conduct security assessments of your products. Moreover, because of our decades-long experience in all aspects of product design, we are experts at balancing security and non-security needs. Together, we will find a solution that is custom-made to your problems. Stay connected with us Subscribe to receive the latest news, insights and exclusive event invitations from Zühlke. Learn more Contact person for Switzerland Dr. Raphael Reischuk Group Head Cybersecurity & Partner Raphael Reischuk is the author of numerous scientific publications in various areas of IT security and cryptography, many of which have received awards. BILANZ and Handelszeitung listed him among the Top 100 Digital Shapers in Switzerland in 2021. Reischuk is a member of multiple international programme committees for IT security and Vice-President of the Cybersecurity Committee at digitalswitzerland. He is also the co-founder and a board member of the National Test Institute for Cybersecurity (NTC). In 2017, he joined Zühlke, where he channels the expertise he has gained in various industries into his role as Group Head Cybersecurity & Partner. As an experienced IT security expert, he is driven by curiosity, innovation, technology, a sense of commitment and a strong business ethos. Contact raphael.reischuk@zuehlke.com +41 43 216 6611 Your message to us You must have JavaScript enabled to use this form. First Name Surname Email Phone Message Send message Leave this field blank Your message to us Thank you for your message.
' It may seem like there is still plenty of time before the Act comes into force. But the CRA's requirements can have a significant impact on your development and support operations, so organisations should start implementing the necessary changes today. ' Piet De Vaere Lead Security Architect at Zühlke
' The CRA is fully applicable to companies based in non-EU countries when they intend to release their products in the EU. ' Piet De Vaere Lead Security Architect at Zühlke
Industrial Sector – Apps in the industrial sector: developing a software architecture geared for profitability Learn more
Healthcare providers – Health Ecosystem Day: What healthcare players can learn from each other Learn more