The Cyber Resilience Act — Security Requirements for Products with Digital Elements or Networked Hardware and Software Products in the EU

The European Cyber Resilience Act (CRA) is an EU Regulation governing fundamental cybersecurity requirements for products with digital elements or networked hardware and software products on the European market. These include industrial control units, IoT products and software installed on electronic devices. The Regulation obligates manufacturers and operators to ensure that their products remain secure throughout their entire life cycle. The aim of this is to increase cybersecurity on the European single market and provide a transparent insight into the security level of products with digital elements.

The interior ministers of the European Council adopted the CRA on October 10, 2024. Due to its status as a Regulation, it is being enforced as a binding and directly applicable piece of legislation. Manufacturers and operators will have until November 2027 to ensure that new products they place on the market comply with the CRA requirements. National authorities will assess the implementation of the CRA, and failure to comply with its requirements may result in corrective measures, product recalls or sanctions. In the future, obtaining a CE quality marking will also be linked to compliance with the CRA — in other words, the marking will signify that the product not only meets certain quality standards, but also demonstrates a certain level of security.

Who does the CRA affect?

The requirements of the CRA apply to manufacturers, importers and distributors of products with digital elements or networked hardware and software products along the entire supply chain. There are no exceptions based on company size or turnover.

Products that are subject to existing EU security regulations are exempt from the CRA requirements. Additionally, the CRA does not affect open-source software developed without a commercial purpose in mind, military products and software as a service provided as a non-essential component of a product. However, it does apply with binding effect to cloud services that involve remote data processing. As it incorporates the entire supply chain, it has particular implications for many companies that contribute software artifacts or hardware components to security-critical products.

What sanctions are being envisaged for breaches of the CRA’s requirements?

The amounts at which fines are set will depend on how serious the breach is. If information is left incomplete, fines could reach as much as 5 million euros or 1% of annual turnover. Breaches of the obligations that distributors are required to fulfill may incur fines of up to 20 million euros or 2.5% of annual turnover. As compliance with CRA requirements will also be a factor in whether CE markings are awarded, products that are not CRA-compliant may end up lacking a CE marking, preventing them from gaining access to the European single market at all. 

The CRA demands a high level of security throughout the entire life cycle of products with digital elements — regardless of whether they contain the manufacturer’s own components or third-party ones. In the future, it will only be possible to launch products if they have no known exploitable vulnerabilities. Specifically, the following security requirements apply: 

• Prevention of attack surfaces right from the product’s concept planning stage 
• Planning of protective mechanisms during the concept planning and design stage 
• Provision of a secure by default configuration and the ability to reset the product securely     
• Establishment of protective measures to prevent unauthorized access (using authentication, identity and access management systems, for example) 
• Assurance of data confidentiality (by means of encryption mechanisms, for example) 
• Assurance of data and service integrity  
• Restriction of data processing to include only data that is essential for operating the product 
• Monitoring and storage of internal processes (such as data access instances, data changes and services used)
• Assurance that essential functions will be available even if an attack is successful 
• Minimization of negative impacts on other market players in the event that an attack is successful 
• Provision of free security updates

The CRA also explicitly prescribes risk assessments for all products with digital elements. Risk assessments conducted in the early stages of developing a product help to resolve security vulnerabilities promptly and identify them systematically. Security concepts created on the basis of these risk assessments embed protective mechanisms in the design itself.

What Fraunhofer AISEC can assist with when it comes to conducting risk assessments and creating security concepts

Risk assessment using QuBA

The risk level can be assessed quickly and easily using the questionnaire-based QuBA method that has been developed and put into practice by Fraunhofer AISEC in collaboration with SICK AG. 
This assessment process involves the following core activities::

• Answering a questionnaire containing questions on the impact rating and the required attack potential
• Performing an automated risk assessment on the basis of the answers, using AISEC’s existing risk catalogs
• Automatically generating appropriate countermeasures for mitigating identified risks
• Allocating proposed countermeasures to assessed risks
• Having assessments of remaining risks performed by IT security specialists
• Automatically generating documentation with a summary of the results and allocation to the CRA requirements 

Using this method, it can take just a few hours to identify the risk status of basic products with homogeneous protection needs. Fraunhofer AISEC helps companies adapt this assessment method to their needs, evaluate suitable protective measures and put these into practice.

AISEC has developed the MoRA tool for more complex risk assessments, and this has been successfully used by industrial partners for several years now. 

Tailored security concepts

Fraunhofer AISEC provides support for customers in the process of designing and implementing individual security concepts for IT-based systems and products. In doing so, we consider security aspects on the basis of risk, looking at everything from hardware to the cloud, across the entire life cycle. 

Examples of support that Fraunhofer AISEC provides for designing and implementing security concepts: 

• Establishing processes for secure product development
• Tool-supported secure programming
• State-of-the-art technical security measures, including
  • Zero-trust paradigm
  • Multifactor authentication 
  • Secure cloud connectivity
  • Secure use of artificial intelligence, and use of artificial intelligence to automate security services such as network asset management and network monitoring
  • Automated solutions for implementing GDPR guidelines
  • State-of-the-art use of encryption (cryptographic processes, post-quantum cryptography)

We develop tailored security concepts for

• microcontrollers, systems-on-chips and dedicated security chips
• embedded systems and IoT products
• control units, vehicle electrical system architectures and Car-to-X (C2X) systems
• architectures for individual and distributed systems
• operating systems, hardware-facing software and container infrastructures
• distributed applications and cloud infrastructures
• network architectures and network protocols    

The CRA requires a software bill of materials (SBOM) for identifying, handling, disclosing and reporting vulnerabilities. The SBOM includes information on the manufacturer’s own program code and components from other manufacturers, which means that it provides an overview of the product’s architecture and dependencies.

Vulnerability management requires the following:

• Creation of a software bill of materials in a machine-readable format 
• Documentation of all security-related aspects, including known vulnerabilities
• Immediate resolution of vulnerabilities based on the quality of the risk they pose
• Immediate provision of free security updates and a secure distribution method, plus secure installation and use
• Publication of information on resolved vulnerabilities and prompt notification of users about required security measures
• Coordinated disclosure of vulnerabilities, with a contact address provided
• Regular security tests
• Ongoing security monitoring

What Fraunhofer AISEC can assist with when it comes to vulnerability management 

Hardware-based security and trustworthiness for IoT

Secure hardware provides a foundation for all the digital functions and applications that use it. In the future, Internet of Things (IoT) devices will be present in more and more areas of business and everyday life, and will become indispensable elements of communication (including industrial communication), smart manufacturing, networked logistics and smart vehicles. As they often process sensitive data, it is essential that they are secure and trustworthy. 

Fraunhofer AISEC is involved in a range of projects in which it is conducting research into securing IoT devices at hardware level. As part of this, it is developing analysis methods and appropriate countermeasures for protecting hardware and software that runs on the system. A key aspect of this involves analyzing physical fault injection attacks; for example, protection against laser and fault attacks, voltage glitch attacks and cycle tampering. 

Transparency and verifiability of software supply chains

The CRA requires assurance that security and integrity will be maintained in software throughout a product’s life cycle. However, there are risks involved in executing software on third-party infrastructures provided in the cloud. Measures for verifying identifies and ensuring the integrity of software stacks are an integral part of meeting the security requirements stipulated by the CRA, and ensuring that a product is trustworthy as a result.

The CMC Connector Measurement Component developed at Fraunhofer AISEC automatically registers the trustworthiness of software components using hardware-based, cryptographic trust anchors. This open-source tool establishes transparency and verifiability for software packages — providing a secure and traceable way of evaluating trust in the software, and making it possible to identify non-trustworthy changes to it.

The tool forms a trustworthy basis for securely and verifiably running software in the cloud and producing secure, high-quality applications.

Secure execution environments with the GyroidOS platform

Using and processing data, and operating digital applications, are all important links in the digital value chain. The CRA stipulates requirements for the integrity, confidentiality and availability of data and software. This is where the GyroidOS platform solution developed by Fraunhofer AISEC comes in.

A key aspect of GyroidOS is its focus on IT security and support for certification processes that conform to industry standards DIN SPEC 27070 and IEC 62443-4-2, and the Common Criteria. GyroidOS isolates highly sensitive applications and data, and prevents uncontrolled information exchange between execution containers. It contains many additional security functions such as complete hard disk encryption, secure booting with remote attestation and secure element support for two-factor authentication. As a result, it is able to not only safeguard the integrity and authenticity of the system, data confidentiality and the trustworthiness of the environment as a whole, but also make a significant contribution to in fulfilling CRA security requirements. 

Tests and analyses for identifying vulnerabilities  

Fraunhofer AISEC offers a wide range of solutions and processes for security tests and analyses: 

• Side-channel analyses, fault attacks and optical analysis processes as part of hardware pentesting
• Analysis of entire vehicles, vehicle parts or larger parts of systems
• Analysis of control units, vehicle electrical system architectures and communication connections
• Penetration testing
• Static and dynamic analyses of source code and binary code, plus code reviews using dedicated tools and solutions such as Codyze, a Code Property Graph and IntelliSecTest, plus the use of AI-based processes that will automatically search for patterns indicating a potential vulnerability.
• Software fuzzing
• Custom development of test and analysis tools

Monitoring

AI-based solutions can be used as an automated way of monitoring the security of networked hardware and software products. AISEC develops AI-based solutions that help companies perform automated tests to determine whether their software is affected by new Common Vulnerabilities and Exposures (CVEs) that have been reported.   It also develops new and improved processes for data-based anomaly detection and for data validation, making it possible to identify abnormal behavior in complex systems and pinpoint specific anomalies in data streams and data access instances. This enhances data quality and allows process optimizations to be achieved through predictive quality and predictive maintenance.

The declaration of conformity confirms that the CRA security requirements have been fulfilled and is issued by the manufacturer or an authorized body. The evidence of conformity that needs to be presented in each case varies according to the product classification, which is based on the product’s cybersecurity risk.

The declaration is continually updated — especially after vulnerabilities have been identified and resolved, or after security incidents. It contains information on the product, manufacturer and harmonized standards, plus a declaration of responsibility and information on the notified body and evaluation process.

The manufacturer signs and dates the declaration. Where product conformity is concerned, the manufacturer is accountable to authorities with a market surveillance function, such as the German Federal Office for Information Security (BSI).

What Fraunhofer AISEC can assist with when it comes to creating a declaration of comformity 

Using its Confirmate tool, Fraunhofer AISEC conducts research into automated compliance testing of software components. Confirmate compares security settings with CRA specifications, identifies vulnerabilities and determines what action needs to be taken in each specific case. This saves time for planning and implementing security measures.

The solution focuses on the source code analysis of the software components integrated in the product and the interfaces provided (e.g., to cloud backends). Confirmate combines static analysis for testing the security properties of program code with automated compliance evaluation. The company’s existing documentation of processes is also reviewed — for vulnerability management purposes, as an example. The program also identifies any third-party software components used and verifies their compliance with the EU Regulation using information from databases on known vulnerabilities.

If an actively exploitable vulnerability is identified in a product, the manufacturer must report the incident to the European Union Agency for Cybersecurity (ENISA) within 24 hours of becoming aware of it. This obligation also applies to security-related incidents and incidents that have the potential to affect product security. If vulnerabilities are discovered in integrated components, the manufacturer must notify the manufacturer of those components. The product user must also be informed of the incident, its impact and any necessary security measures.

As the interior ministers of the European Council adopted the CRA on October 10, 2024, this reporting obligation will apply from November 2025 onward. 

What Fraunhofer AISEC can assist with when it comes to fulfilling reporting obligations

The German Federal Office for Information Security (BSI) is the security authority responsible for enforcing the CRA in Germany and has a market surveillance function. The framework developed by the BSI, entitled the Common Security Advisory Framework (CSAF), is used for reporting vulnerabilities. Product manufacturers and operators go through a local trusted provider in order to access the framework so that they can report vulnerabilities and make use of information.

The kotlin-csaf open-source library makes it possible to integrate the CSAF framework into the product software and parse, import and validate CSAF documents as a result. The library can also provide an automated way of checking that the provider has been implemented correctly.

The technical documentation for products with digital elements contains all the data indicating that the product complies with fundamental security requirements. This documentation is created before the product launch and updated within the support period defined by the manufacturer.

The BSI has published technical guidelines for CRA documentation.
These state that technical documentation must contain the following elements:

• A general description of the product, with the intended purpose and software version specified
• A description of the design, development and manufacture of the product (especially with regard to security properties that the product contains)
• A description of the process involved in dealing with vulnerabilities
• Documentation of the security risks that are relevant to the product, and of the security measures that have been applied
• Details of the security tests that have been performed
• A description of the components using the software bill of materials (SBOM)
• Details of the support period

Documentation obligations toward users

Manufacturers are also obligated to create publicly accessible documentation for product users.
This must contain the following:  

• The name and contact details of the manufacturer
• Where to contact in the event of cybersecurity breaches
• The batch, version or serial number
• A description of the product (and its functions)
• Information on the intended purpose
• Instructions on putting the product into service, using it and taking it out of service securely
• Instructions on securely installing software updates
• A list of known risks and the product’s security properties
• The software bill of materials (SBOM)