Cyber Resilience Act: What manufacturers need to know now 


With the Cyber Resilience Act (CRA), the European Union is creating the first binding legal framework for cybersecurity of digital products.

Whether it's a smart coffee machine, industrial control system, or business software: In the future, all connected products must meet specific security requirements throughout their entire lifecycle. The goal is to create uniform requirements for the cybersecurity of hardware and software. 
 
For developers, this means: Now is the right time to prepare.

In this article, we show what specific requirements the CRA imposes, which products are affected, what steps developers should take now, and what risks arise from non-compliance. 
 
With a transition period of only 36 months, the CRA becomes mandatory from mid-2027. The products that will be sold then are being developed today. Those who act now minimize risks and gain competitive advantages. 
 
CSA supports companies in implementing CRA requirements early and efficiently. From analyzing affected products to technical implementation, documentation, and audit support. 

 

Key Points

  • The CRA affects almost all connected products, including embedded systems.
  • Besides product security, processes are crucial (e.g., vulnerability management and documentation).
  • Compliance must be proven, including CE marking.
  • Those who violate the CRA risk high penalties.
  • Documentation, especially risk analysis, is not a one-time task and must be updated periodically.

 

What is the Cyber Resilience Act (CRA)? 

The Cyber Resilience Act (CRA) is a planned EU regulation that establishes binding cybersecurity requirements for products with digital elements for the first time. This applies to almost everything that contains software and can communicate with other devices or networks. 
 
The CRA pursues three main goals:

  • Protecting consumers and businesses from unsafe digital products
  • Reducing security vulnerabilities in software and connected devices throughout the entire product lifecycle
  • Strengthening the digital single market through uniform security standards in the EU 

 

This means concretely: Manufacturers (and distributors) must implement technical and organizational measures to ensure their products are secure, from development to decommissioning.

This includes:

  • Secure-by-Design:
    Consider security already during development
  • Vulnerability Management:
    Establish processes for identifying, reporting, and patching security vulnerabilities
  • Technical Documentation:
    Demonstrate risk assessment, security concepts, and updates
  • Declaration of Conformity:
    Security requirements must be documented and potentially confirmed by a Notified Body

 

Which products fall under the CRA and which do not?

The CRA applies to "products with digital elements", which include:

  • Software and operating systems
  • IoT devices (e.g., smart home, wearables)
  • Industrial control systems
  • Network devices (e.g., routers, firewalls)
  • Applications with network connectivity

Not affected are:

  • Open-source software that is not commercially distributed
  • Products that already fall under other EU regulations with equivalent requirements (e.g., medical devices under the MDR)

The exact distinction is made through two product categories: 

 

Overview of product categories in the Cyber Resilience Act (CRA): Classification into standard category, important products (Class I and II), and critical products with respective requirements for conformity assessment and certification.

Source: https://www.tuvsud.com/de-de/dienstleistungen/produktpruefung-und-produktzertifizierung/cyber-resilience-act

 

What consequences arise from non-compliance?

The EU relies on strict enforcement:

  • Fines up to 15 million euros or 2.5% of global annual turnover, whichever is higher
  • Market access can be prohibited if CE marking is missing or deficiencies exist
  • Liability in case of damage if security deficiencies were demonstrably not considered

This means: Cybersecurity becomes a central compliance task, including for management.

 

Manufacturer vs. Distributor: Who bears the responsibility?

  • Manufacturer:
    Primarily responsible for design, development, risk management, conformity assessment

  • Distributor (e.g., distributors, OEMs):
    Must ensure that delivered products are CRA-compliant including documentation and CE marking

Responsibility cannot be completely outsourced. Distributors are also liable if they put unsafe products into circulation.

 

Developers must keep the following points in mind 

  • Vulnerability Identification and Management 
    A central element of the CRA is the systematic identification and management of vulnerabilities. Manufacturers must ensure they can identify, assess, and remediate vulnerabilities early, both in self-developed code and in used third-party components. This includes implementing automated security analyses (e.g., static and dynamic code analyses) and creating and maintaining a Software Bill of Materials (SBOM). This is particularly challenging for embedded systems, as proprietary components and limited resources often make comprehensive monitoring difficult.

  • Security Updates and Disclosure 
    The CRA requires manufacturers to provide security-relevant updates throughout the entire intended lifetime of their products and to design them so that users can install them reliably and securely. This particularly affects IoT and embedded devices, where updates are often rare or non-existent. At the same time, security updates must be documented comprehensibly and communicated publicly, such as by specifying fixed CVEs. Missing or insecure update management can be assessed as a serious compliance violation in the future.

  • Vulnerability Reporting and Coordination 
    The reporting and coordination of vulnerabilities gains new binding force under the CRA. If a manufacturer discovers an actively exploitable security vulnerability, they are required to report it to the competent authorities or ENISA within 24 hours. Additionally, clear processes must be provided for accepting external vulnerability reports.

  • Security Management 
    Security must not be an add-on but must be an integral part of the entire product development process. The CRA therefore requires structured security management throughout the entire product lifecycle. This includes risk analyses, implementing a secure development process (Secure SDLC), clearly defining roles and responsibilities, and comprehensive documentation of all security measures. Organizations must be able to demonstrate these measures during an audit.

  • Data and Privacy Protection 
    Products with digital elements must be designed according to the CRA to ensure the confidentiality, integrity, and availability of personal and sensitive data. Requirements include the use of strong encryption, applying "Privacy-by-Design" and "Privacy-by-Default" principles, and protection against unauthorized access or uncontrolled data sharing. For embedded systems with limited memory and computing power, this often presents a particular challenge - such as secure storage and processing of personal data.

  • Access Control and Monitoring 
    Another focus is on protection against unauthorized access. The CRA requires the implementation of robust access controls, including secure authentication mechanisms, role and rights management, and avoiding preset default passwords or hardcoded credentials. Additionally, products must offer the possibility to log security-relevant events and evaluate them comprehensibly when needed. Especially in distributed systems with embedded components, this requires targeted architecture planning.

  • Resilience and Incident Mitigation 
    Finally, the CRA requires that products be resilient against cyber attacks - and can react in a controlled manner in case of emergency. This means: Security functions must not completely fail during an attack but must show fault tolerance. Built-in recovery mechanisms, such as dual-firmware strategies or secured bootloaders, can be crucial here. Companies must also be able to respond quickly to security incidents, limit their impact, and immediately inform affected users.

 

We help

The CRA is more than a legal requirement; it is an impulse to anchor security as a fixed component of product development.

Those who start implementing early secure long-term trust, legal certainty, and market opportunities.

How are you dealing with the CRA in your company? Do you have questions about implementation or classification of your products?

Contact our expert team, we are happy to accompany you on the path to CRA compliance. 

Matthias Renner

Matthias Renner

BSc in Microtechnology, Bern University of Applied Sciences
Embedded Software Engineer

About the author

Since early 2022, Matthias Renner has been working as an Embedded Software Developer at CSA Engineering AG, where he primarily supports clients in the medical technology sector in developing secure and high-performance firmware in C/C++.

His particular interest lies in cybersecurity in the embedded environment, especially the challenges arising from regulatory requirements such as the Cyber Resilience Act.

Contact us