What is Cyber Resilience Act, and what cybersecurity requirements does it impose?

• What is the CRA?
• What software is subject to the CRA?
• What cybersecurity requirements does the standard impose on products?
  • Cybersecurity requirements relating to the properties of products with digital elements
  • Requirements for handling vulnerabilities
• How to meet these requirements
• Conclusion

What exactly is the Cyber Resilience Act? This article covers the regulation that establishes cybersecurity requirements for products sold in the European market. We'll discuss everything: from what these requirements entail to penalties for non‑compliance.

What is the CRA?

The Cyber Resilience Act (CRA) is an EU regulation that sets requirements for software companies that release their products in the European Union. These requirements address cybersecurity of the product under development.

The European Commission initiated this regulation. It took effect on December 10, 2024, and companies must meet its core requirements within 36 months of that date—by December 11, 2027. However, some obligations come with earlier deadlines:

• Reporting obligations of manufacturers (Article 14)—by September 11, 2026;
• Notification of conformity assessment bodies (Chapter IV)—by June 11, 2026.

The CONFIDENTIALITY AND PENALTIES section, Article 64 (paragraph 2), states that non-compliance with the CRA requirements shall be subject to administrative fines of up €15,000,000 or, if the offender is an undertaking, up to 2.5% of its worldwide total annual turnover for the previous financial year, whichever is higher.

Based on the wording, the reasons for introducing this regulation are as follows:

• software has a low level of cybersecurity, reflected by widespread vulnerabilities and the insufficient and inconsistent provision of security updates to address them;
• users lack information about how well the software they use is protected against vulnerabilities.

What kinds of software be developed under CRA guidelines?

What software is subject to the CRA?

As noted earlier, the CRA is a European Union regulation, and its requirements apply to those who ship their software products to the EU market, even if the products are developed outside the EU.

Which software does it apply to? The standard establishes requirements for "products with digital elements" and provides the following definition:

'product with digital elements' means a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately;

This may give the impression that any software is a product with a digital element, making it seem that all software must comply with the CRA. However, the Scope section provides the following clarification:

This Regulation applies to products with digital elements made available on the market, the intended purpose or reasonably foreseeable use of which includes a direct or indirect logical or physical data connection to a device or network.

That section also adds an important clarification: several industries, such as medicine, automotive, defense, and a few others already operate under their own regulatory frameworks that govern software development in those fields. The CRA doesn't apply to those sector-specific rules because they take priority.

To sum it up, the CRA applies to companies that develop products with digital elements meeting all of the following criteria:

• they're supplied within the EU;
• they connect to other devices or networks to exchange data;
• they don't fall under any other, more specialized regulation already listed in the CRA's Scope section.

We've discussed who might be affected by this standard, but we haven't yet explored its requirements. Let's fix this.

What cybersecurity requirements does the standard impose on products?

The requirements appear in CHAPTER III. CONFORMITY OF THE PRODUCT WITH DIGITAL ELEMENTS, which refers to Annex I.

The core requirements for a product with digital elements fall into two groups:

• cybersecurity requirements related to properties of products with digital elements;
• requirements for handling vulnerabilities in products.

Let's go through each group.

Cybersecurity requirements relating to the properties of products with digital elements

Broadly speaking, this group ensures that a product provides an adequate level of cybersecurity by considering potential risks that may arise during its use.

I simplified and grouped the requirements in this article to make the information easier to follow. You can find the original version in the CRA here.

Requirements for default security and resilience of a product:

• the product must not include any known vulnerabilities when it reaches the market;
• the product must ship with a secure default configuration (and let users reset it to original settings);
• the product must support security updates, including:
  • automatic updates enabled by default;
  • notifications about new versions;
  • the option to postpone or disable updates.

Requirements for protecting the data a product handles and for maintaining proper access control:

• provide authentication, identity management, and access control mechanisms, as well as logging of any unauthorized login attempts;
• protect data confidentiality by encrypting it in transit and at rest and relying on modern security technologies.
• maintain the integrity of data, commands, and configurations and provide a way to detect any tampering;
• accept only the minimum amount user data necessary for the product to operate.

Maintaining resilience and mitigating attack impact:

• maintain the availability of core functions, including measures that defend against denial-of-service (DoS) attacks;
• minimize negative effects on other connected devices and networks;
• limit the attack surface by exposing as few interfaces as possible;
• use mechanisms that reduce damage when an incident occurs.

Monitoring and control:

• maintain security logs and event monitoring, allowing users to disable them if they choose;
• provide users with a secure way to erase all data and settings and transfer them securely when needed.

Requirements for handling vulnerabilities

As with the previous set of requirements, I've summarized these here in a simplified and grouped format. You can find the original version here.

Managing vulnerabilities in a product:

• maintain a registry of vulnerabilities and components;
• promptly fix vulnerabilities and release security updates separately from feature updates;
• run regular security tests and checks on the product.

Informing users and disclosing information:

• publish details about fixed vulnerabilities after each patch release, including descriptions, affected products, severity levels, and recommendations;
• follow the Coordinated Vulnerability Disclosure (CVD) policy.

User communication and updates:

• create a system for reporting and sharing vulnerability information;
• provide a secure way to deliver updates, including automatic and free distribution;
• accompany updates with clear notifications and instructions for users.

How to meet these requirements

At first glance, each requirement appears to demand complicated processes. However, it's often unclear what those processes should actually look like. To make the standard easier to work with, ENISA published an article that maps CRA requirements to existing standards.

One requirement worth highlighting is regular and thorough product testing. Systematic and comprehensive testing supports the shift-left approach, enabling developers to identify issues, bugs, and vulnerabilities as early as possible in the development cycle. This early detection significantly reduces the cost of fixing problems for the software manufacturer.

The risk of bugs slipping into the final release grows if tests don't cover the product sufficiently. Since every testing method detects issues in its own domain, developers need a broad, well-balanced testing toolkit to avoid blind spots where issues can hide.

When it comes to the shift-left approach, static analysis deserves special attention. It helps developers catch errors during the development process—long before testing or, even worse, after release. Static analysis also lays the groundwork for SAST, an approach that enables detection of security issues in source code. SAST plays an essential role within the Software Development Lifecycle (SDLC). We have an article dedicated to this topic, which I recommend reading.

In addition to everything mentioned above, SAST tools can help meet the specific requirements we discussed earlier. PVS-Studio is an example of a SAST solution capable of detecting:

• potential injections and other vulnerabilities, including SQL injection, XSS, path traversal, and more;
• insecure encryption algorithms;
• outdated data exchange protocols;
• errors that can lead to DoS issues, such as ReDoS or XEE;
• etc.

When searching for such errors, the following standards and classifications are typically applied:

• OWASP Top Ten;
• MISRA;
• AUTOSAR;
• OWASP ASVS;
• Top 25 CWE;
• SEI CERT.

Given the requirements discussed earlier, SCA is also worth mentioning. This automated process detects vulnerable libraries or components within a product during the development process. SCA can also help meet the requirement for releasing vulnerability-free products.

Conclusion

Secure software development continues to attract a global attention. In this article, we provided a brief overview of the European Cyber Resilience Act and its key requirements for software products.

Still, effective software development requires comprehensive testing. SAST tools are just one part of the puzzle. Developers also need unit tests, functional tests, dynamic analysis, and other practices that make a product more resilient and secure.

Let's wrap things up here. Subscribe to our blog and see you soon!