EU Cyber Resilience Act: What are its Essential Requirements for Software Products?

Originally published on 28 Oct 2024
Last updated on 28 Oct 2024

The EU’s Cyber Resilience Act (CRA) 2024 lays down a “legal framework for essential cybersecurity requirements for placing products with digital elements on the Union market” (CRA, 1). These requirements cover “products with digital elements”. The goal is to establish conditions for developing secure software. Software venders must take security seriously thought the entire SDLC. Consequently, the intention is that “hardware and software products are placed on the market with fewer vulnerabilities and that manufacturers take security seriously throughout a product’s lifecycle” (CRA, 2).

This blog post will answer some basic questions, based on our understanding of the Act. What is the new Cyber Resilience Act in the EU? What is the key focus of the Cyber Resilience Act and who does it affect? When will the EU Cyber Resilience Act come into force? How do software venders comply with its requirements? Are there obligations for other parties too? And does Payara help its customers to comply with their requirements under the Act?

The information provided does not, and is not intended to, constitute legal advice; instead, all information, content, and materials available are for general informational purposes.

Cyber Resilience Act Requirements & Scope

The title of EU Cyber Resilience Act’s Consolidated text calls it a Regulation “on horizontal cybersecurity requirements for products with digital elements” (EU CRA, Consolidated text). Both aspects are important for understanding the CRA’s scope. Let’s look at each in turn.

“Horizontal” Cybersecurity Requirements

In general, “horizontal requirements" refers to essential requirements that apply to all software products, rather than specific ones for certain products only. The Act defines the horizontal nature of its requirements in different ways.

It is made up of legislation that covers cybersecurity from “different angles (products, services, crisis management, and crimes)” (EU CRA, Consolidated text, 3)

It is intended as a regulatory framework that establishes “comprehensive cybersecurity requirements for all products with digital elements” (EU CRA, Consolidated text, 4).

It lays down rules that are “not specific to sectors or certain products with digital elements” but states that further "sectoral or product specific” rules could be added later (EU CRA, Consolidated text, 28)

It is clear from the broad scope of its language at this stage that the CRA is intended by the EU to cover as wide a reach and range of related products as possible. And, it’s important to remember that although the focus of this blog post is software, the definition of products in the CRA includes hardware elements too.

“Products with Digital Elements”

The CRA refers to “products with digital elements” throughout (EU CRA, Consolidated text, 13)

One of the ways it defines a product with digital elements is “any software or hardware product and its remote data processing solutions, including software or hardware components to be placed on the market separately” (EU CRA, Article 3, 1).

This is one of Article 3’s broad, all-encompassing definitions of the products covered by the Act. The reference to “remote data processing”, “means data processing at a distance the software for which is designed and developed by the manufacturer, or under the responsibility of the manufacturer, and the absence of which would prevent the product with digital elements from performing one of its functions” (EU CRA, Article 3, 2). This seems to suggest it includes all software products including applications that are cloud based or rely on cloud storage.

Critical and Highly Critical

Products with digital elements that could present a cybersecurity risk are divided into “critical” and “highly critical”:

“Critical product with digital elements” means a product that is considered a security risk due to its association with privilege, control, trust, sensitivity, impact, and destruction (Article 6(2) - Annex III)

“Highly critical product with digital elements” means a product that is relied on by essential entities or is “relevant for the resilience of the overall supply chain of products with digital elements against disruptive events” (Article 6(5))

The Cyber Resilience Act and its Essential Requirements

For a product with these digital elements to be made legally available in the marketplace, it needs to meet essential requirements. These requirements assume that the product has been properly “installed, maintained, used for their intended purpose...and, where applicable, updated” (Article 5).

This means that software products must be delivered to customers “without any known exploitable vulnerabilities.” To achieve this, software products must be risk assessed (Article 10(2)). The CRA requires software to adhere to all sorts of security requirements (Annex 1 – Section 1) and complements related legislation, particularly the NIS2 Framework. Software must possess these properties, where possible:

Products must ensure protection from unauthorized access, and provide security related information on access to that data

All data processed by a product must have its confidentiality and integrity protected, and be limited to the product’s intended use (“minimisation of data”)

The availability to users of a product’s essential functions must be protected, while the negative impact of the available services provided by others must be minimised

The product must be designed and developed to limit attack surfaces and reduce the impact of exploitation incidents (“security by design”)

Specific Requirements Examples

The CRA provides examples in its requirements list that help to explain their meaning and give a sense of the specificity needed for compliance, for example:

Implementing cybersecurity protection mechanisms such as “authentication, identity or access” systems and data encryption are mentioned

Mitigating of denial-of-service (DoS) cyberattacks

Addressing vulnerabilities by “automatic updates and notification” to users

The Processes to Comply with Essential Requirements in the CRA

It is not enough that a product itself meets the essential requirements before it is made available to the market. Product manufacturers must also put in place processes that meet requirements. The CRA calls these “vulnerability handling requirements”.

The CRA does not itself definite what a vulnerability is. But it states that a vulnerability is a vulnerability as defined by Network and Information Security Directive II (NIS2). The NIS2 contains the more technical definitions that are used across EU legislation for cybersecurity issues. It defines a vulnerability as: “a weakness, susceptibility or flaw of ICT products or ICT services that can be exploited by a cyber threat” (NIS 2, Article 6:15).

However, the CRA does define what an “actively exploited vulnerability” means (3:39): “a vulnerability for which there is reliable evidence that execution of malicious code was performed by an actor on a system without permission of the system owner.”

Process Requirements for Software Manufacturers

These are some of the main process requirements on manufacturers of software (Annex 1 – Section 2):

Vulnerabilities must be idented, documented, and remediated without delay

Information about fixed vulnerabilities must be publicly disclosed in security updates

Information about potential vulnerabilities must be shared too

Mechanisms to report vulnerabilities must be facilitated

Updates and patches for products with exploitable vulnerabilities must be provided quickly and freely

Specific Process Examples

As with the requirements, the CRA is not shy about providing details on how to comply with the process requirements on dealing with vulnerabilities. Affected vendors must:

Provide security updates “without delay and free of charge” to address vulnerabilities

Provide information on these “publicly disclosed” updates including: vulnerability descriptions, advice on identification, impact, severity, remediation, and action to be taken

Supply a contract address for reporting discovered vulnerabilities

What is the Cyber Resilience Act Timeline?

The EU’s Cyber Resilience Act comes into force in the second half of 2024

Manufacturers will need to comply before placing their products on the market by 2027

How Payara Helps Customers Comply with the EU Cyber Resilience Act Requirements

Payara Services' design and engineering practices adhere to two of the most inspirational industry standards:

Data minimization – the principle that states that if and where it is necessary to collect, store, or process data, this data should collected only if strictly necessary to carry out processing; stored only as long as a need can be easily stated; explained and accessible to users; and deleted once it is no longer needed for its original purpose – which also happens to align with the General Data Protection Regulation (GDPR)

Security by design – the principle that security considerations, plans, and implementations are central to the entire Software Development Lifecycle (SDLC), not an afterthought – from the earlier stages of a specification for a new product, during its scoping, design, coding, testing, releases, further development, and updates

But, there are some specific ways in which we address the specific requirements of the Cyber Resilience Act. Each is outlined below.

In the Payara Platform, you have many tools to enable you to harden your system against unauthorized access and malicious attack:

First, you have various, configurable authentication (whether users can get access) and authorization (what they can get access to) mechanisms. Next, Security Auditing enables you to cover the human elements in your application. This means being able to identify who can gain access to sensitive data and how. Payara Server Enterprise contains various Audit Modules that allow you to administer and track all authentication and authorization decisions. And, finally, Firewall configurations including Remote Method and double firewall architecture means you can manage communications between networks, while Certificates and Ciphers help further enable confidential communication (see (see Administering System Security).

Other tools help enforce the System Security policies you establish on Security Realms and File Groups or File Users (see Administering User Security).

End-to-end authentication is provided by Message Layer Security for SOAP web services, with username tokens, digital signatures, and encryption, together with policies that reinforce the security for request and response message processing (see Administering Message Security).

To support security in your production environment where high availability is a non-negotiable, Payara Server Enterprise provides enables the configuring of certificates in Cluster Mode. This means that administrative commands execute on the domain administration server (DAS) can be replicated on affected server instances of those that are part of a Cluster or Deployment Group (see Administering Security in a High-Availabilty Environment).

Our Managment API enables administrators to secure all administrative communication between the domain administration server (DAS), any remote instances, and administration clients such the asadmin CLI utility, the administration console’s web UI, and REST clients. This means unauthorized users or processes cannot intercept administrative traffic or masquerade as legitimate components (see Managing Administrative Security).

Some aspects of security are to do with the overall environment in which your application is deployed. These can include understanding your environment, installing in a secure environment, enabling the Secure Administration, running on Web Profile, securing the host machine, and securing Payara Server Enterprise (see Running in a Secure Environment).

There are a few other tracking and logging features we’d like to call to your attention, that will help your monitor and detect problems as they arise:

Eclipse MicroProfile Health Check allows your development team to create and configure your own health checks to automate the verification of your application’s health checks (see Health Check Configuration)

The Open Tracking API enables you to trace the flow of requests (see Eclipse MicroProfile Open Tracing).

Log Rotation, for example, ensures that log files are kept to a manageable size in the Payara Platform, while old ones are deleted once they reach a configurable threshold (by time, size, or number)