Early action pays off when aiming at compliance with the European Cyber Resilience Act (EU CRA)

The rise in cyberattacks on digital products has led to major financial losses [1]. At the same time, the impact of cyberattacks through digital products has increased as more and more products are connected, expanding the attack surface for cybercriminals. Vulnerabilities in the supply chain in particular have become a major risk as they lead to malicious activities such as DDoS attacks and anonymous malware delivery to enable large-scale cyberattacks. A recent example is the botnet established on compromised hardware by cyber actors that the National Security Agency (NSA) and the Federal Bureau of Investigation (FBI) link to the People’s Republic of China [2].

In 2022, the European Commission proposed the EU Cyber Resilience Act (CRA, [3]). This establishes the essential cybersecurity standards for product manufacturers, whether within the EU or not, placing any product with digital elements on the EU market [4] where the “intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or a network” (CRA, Art. 2.1 [3]).

How to get started?

A good starting point, once the cyber security requirements are clear, is to establish the easy-to-use method of threat modeling and involve people in taking responsibility early on. It is especially important to include developers, whether for hardware or software. A key success factor for security is creating a mindset of “security as shared responsibility”.

The shared understanding of the system and the associated cybersecurity risks will evolve into a balanced security architecture. It is essential to prioritize the identified cyber risks in order to avoid being overwhelmed by the sheer number of attack points. Often, addressing certain risks also reduces others, which is why this assessment must be carried out iteratively.

Establishing the three key pillars

The CRA’s defensive approach can be summarized by the following three key pillars that must be fulfilled (see Annex I and Annex II [6]):

1. Secure Product: Ensuring a product is placed on the market only if it is secure by design and default.

2. Secure Operation: Obliging manufacturers to take security seriously and maintain it throughout the whole product lifecycle by providing security updates to address emerging vulnerabilities.

3. Transparency and Disclosure: Empowering users to take cybersecurity into account when purchasing and using products in a secure manner.

Pillar 1: Secure Product

How to achieve security by design

Applying security by design means focusing on minimizing vulnerabilities and reducing the attack surface of the whole system. It is important to take a holistic approach as potential risks can be identified that might be overlooked when focusing on isolated parts of the system. As stated earlier, the product is rarely the target; therefore, a cyber security threat analysis should cover the full system to better understand the possible impact of attacks. This also encompasses how users interact with the system as there can be vulnerabilities due to unintentional misuse.

It is crucial to consider cybersecurity early on during product specification and design. This enables a robust architecture to be developed that can withstand cyberattacks, requiring less effort (and lower costs) than making “end-of-pipe” changes to enhance security in an existing design.

An additional important point is to always consider end-to-end security. If insecure transport channels are protected through encryption, the focus shifts to how the key is secured. With the increase in identity-based attacks, authentication of users and devices is essential. But what is the basis of the trust? Does the product’s hardware support secure boot?

How to achieve security by default

Applying the security by default principle means designing products so that the most secure configuration and settings are applied as the standard, out-of-the-box experience. Instead of relying on users to implement security measures after deployment, security features are automatically built in and enabled without requiring extra steps.

For a product, security by default usually starts by limiting potential entry points by disabling unnecessary services and elements such as diagnostic features (e.g., detailed logs). Whenever a device provides access to sensitive data, strong authentication and the principle of least privilege must be implemented. Data at rest and in transfer must be protected by encryption.

Manufacturers of products that utilize protocols like OPC UA, recognized for their security architecture, must ensure that security measures such as ACLs are not optional features, even though they may increase operational complexity.

Pillar 2: Secure Operation

Providing strong support and automated testing for products with digital elements throughout the entire lifecycle is crucial. This is not just for cybersecurity but also to enable improvements and new features to be implemented rapidly and at high quality through secure software updates (addressing signing, validation, encryption, control over updates, etc.).

Efficiently managing vulnerabilities is vital when it comes to secure operation. Accordingly, the SBOM (software bill of materials) is key (Annex I, Part II, point (1) [6]) as it enables rapid assessment of a product's exposure to new vulnerabilities. Compiling an SBOM has become mandatory. To support CRA adoption, Germany's Federal Office for Information Security (BSI) has clarified SBOM requirements by publishing Technical Guideline TR-03183 [8]. It is important to follow a standard to make the SBOM actionable.

The idea of viewing security as a shared responsibility is also fundamental in operations. The term DevSecOps reflects this as a methodology that combines development, operations, and security practices that are integrated throughout the entire software supply chain. For example, the processes for creating and maintaining an SBOM should be standardized for predictability and repeatability. Creating the SBOM early (during the development phase) helps with tracking all software components from start to finish and provides transparency so that organizations have an insight into their supply chain dependencies.

During production, monitoring can be further automated through new approaches, such as AI agent-based systems, which can take over vulnerability monitoring for an SBOM and even automatically apply patches in the event of particularly severe risks.

The level of automation and maturity in DevSecOps affects how quickly organizations can address issues and reduce exposure to threats.

Pillar 3: Transparency and Disclosure

As mentioned previously, awareness is the starting point for any security consideration. There must be clarity regarding where to request information about vulnerabilities and what the coordinated policy on vulnerability disclosure entails so that users are aware of weaknesses in the product (Annex II, point (2) and Annex I, Part II, point (5) [6]).

After addressing vulnerabilities with security updates, manufacturers are required to publicly disclose this information and provide clear guidance to users to remediate the issues (Annex I, Part II, point (4) [6]). This ensures transparency, empowering users with the knowledge necessary to safeguard their systems and take necessary actions to maintain security and resilience in a rapidly evolving digital landscape.

Throughout the entire lifecycle, end users must be provided with instructions to enable safe installation, operation, and use. In addition, the relevant technical documentation for the assessment of a product's security must be made available and kept for 10 years after the product is placed on the market (CRA, Art.13, point(13) [3]). This extends the concept of “awareness” to the end user and implements it – again – from end to end.

Summary: CRA compliance can be managed as a continuous, iterative process

CRA is essentially an extension of CE marking. With the constant increase in threats, cybersecurity cannot be ignored anymore. There is no avoiding the need to embed security into the DNA of any manufacturer providing products with digital elements, especially to efficiently meet the requirements on vulnerability management.

The challenges may seem significant, and for some companies achieving CRA compliance can feel like a Herculean task. It is important not to panic and to start the journey. As mentioned previously, it is an iterative process, and now is the ideal time for a first iteration. Helbling supports companies and their products with digital elements throughout the entire lifecycle, from design and development to operation, combining precise knowledge of interdisciplinary teams and years of experience.

Authors: Frederic de Simoni, Martin Junghans

Main Image: iStock