Cyber Resilience Act: Key Concepts for Implementation

The Official Source of Truth on the Cyber Resilience Act

The summary table above provides essential details about the Cyber Resilience Act. The regulation’s official requirements are detailed in Regulation-2024/2847-EN-EUR-Lex, which should be regarded as the source of truth for all CRA requirements, enforcement, and consequences.

This article highlights the essential requirements and implications for technical professionals, but the regulation is subject to change, and you are responsible for adhering to it as appropriate for your context. The sections that follow frequently link to and quote from the CRA’s official document, so you can learn more directly from the official source of truth on the subject.

Practical Implications of the Cyber Resilience Act

So, what does the CRA actually require of technical professionals?

There are four primary implications for those creating a product with digital elements:

• Risk assessments

• “Secure by default” requirements

• Vulnerability handling and response

• CE marking requirements

Anyone involved in importing and/or distributing a relevant product also has obligations to verify / ensure compliance conditions are met before placing/making it available on the EU market (you can find more details on this responsibility here).

Risk Assessments

The CRA requires manufacturers to conduct a risk assessment before making a product publicly available in any capacity, including pre-release versions (e.g., alpha/beta releases). This risk assessment must be provided as part of the technical documentation the CRA requires (see Article 31).

Risk assessments must consider how the cybersecurity risks in Part I of Annex 1 apply to “the intended purpose and reasonably foreseeable use...” of the product. If some risks in Annex 1 don’t apply, you must document why they aren’t applicable. This assessment must also consider the risks associated with third-party integrations, including those involving free and open-source software.

So what might a risk assessment look like for a team planning a product that communicates with a third-party API? For the sake of brevity, we’ll walk through a couple of the criteria in Part I of Annex 1 to illustrate what this should look like:

1. Products with digital elements shall be made available on the market without known exploitable vulnerabilities

The team will start a risk assessment by analyzing whether any of its software (used in the product that communicates with the third-party API) has known exploitable vulnerabilities. For example, if a product uses the requests library, the team would have to consider vulnerabilities related to said library.

Additionally, the risk assessment must consider the third-party API to ensure that there are no documented vulnerabilities in the third-party system that could present a vulnerability to the product (see Article 13, Section 5 for more details on the responsibilities of manufacturers as it relates to third-party systems).

​​(e) Protect the confidentiality of stored, transmitted or otherwise processed data, personal or other, such as by encrypting relevant data at rest or in transit by state of the art mechanisms, and by using other technical means

A risk assessment must ensure that data processed by the device/system is appropriately protected throughout its lifetime in the system. A risk assessment would need to answer questions related to this criterion, like these:

• Is there any data that isn’t being protected?

• Are the planned or implemented protection mechanisms up to date?

• Is data protected through the entire system (in transit and at rest)?

“Secure by Default” Requirements

Under the CRA, products with digital components must be “secure by default” (see 2b of Annex 1). This means it is not enough to have a security feature that addresses one of the requirements listed in Annex 1 that is merely “available”—it must be enabled in the product’s initial state. The CRA also requires that products be able to be reset to their original state, allowing users to confidently return to a secure state if needed.

For example, if a product accesses a third-party API, it must do so in a manner that is secure and poses no risk to the product owner, the third party, or any other party. The data and authentication (if present) must be securely stored and processed. The product can support user configurability under the CRA, and such configurability may even allow modifications that could make the product slightly less secure, but users must be able to reset the system to its original, secure state.

Vulnerability Handling/Response

Another practical implication of the Cyber Resilience Act is that you must have a process for handling vulnerabilities that you find or are reported to you. The process of reporting “actively exploited vulnerabilities” is laid out in Article 14, Section 2, with this timeline:

• Hour zero: You become aware of an “actively exploited vulnerability.”

• Within 24 hours: You must send an early warning notification to the appropriate CSIRT and ENISA.

• Within 72 hours: You must send a vulnerability notification with general details about the vulnerability and exploit to the same.

• Within 14 days: The final report (detailing what happened and what you did to fix/mitigate the issue.) must be submitted no later than 14 days after a corrective measure is available.  

You also have to report any “severe incidents” as described in sections 3-5 of Article 14. Severe incidents have the same timeline as vulnerabilities, except the final report isn’t due until a month after the early warning notification.

For practical purposes, the key takeaway here is to develop a plan for handling this kind of incident now. Having even a basic reporting process documented can save a lot of time and headaches later. A vulnerability reporting process can be as simple as a document describing the following:

• The required reporting timeline (as detailed above)

• What has to be reported at each stage of the timeline

• Who needs to be contacted and how to get a hold of them

Documenting this process now will ensure that you don’t have to do it later while also handling an actively exploited vulnerability.

Importers and distributors of a product are responsible for reporting any vulnerabilities they discover or become aware of to the manufacturer and ensuring that they are addressed as required by the CRA.

CE Marking Requirements

The last significant implication of the CRA that you should be aware of is the “CE” symbol, which you’ve probably seen before.

The CE marking indicates the manufacturer’s declared conformity (following the applicable conformity assessment route) with EU requirements, including CRA where applicable. It indicates that the marked product meets the necessary requirements to be sold in the EU. Keep in mind that a product may need to meet multiple requirements, one of which may be the CRA, depending on the type of product. Until now, some products with digital elements haven’t needed the “CE” logo, but they will once the CRA goes into full effect.

You can read more about these requirements in Recital 89 and Article 30.

How the Cyber Resilience Act Impacts Common Scenarios

Let’s walk through some common scenarios and examine how they should be handled under the CRA.

Using an Open-Source Dependency

Let’s say your product uses an open-source software library. Before the CRA, you could use this library without considering its dependencies or vulnerabilities. After the CRA goes into effect, you will be responsible for keeping a software bill of materials (SBOM), which is “a formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements” (Article 3, point 39). The CRA expects an SBOM in a commonly used, machine-readable format covering at least top-level dependencies. It may be requested by authorities, and it isn’t necessarily required to be public.

CRA regulators and reviewers generally expect an SBOM to be in a standard format, such as CycloneDX. Many tools can automatically generate an SBOM. To illustrate this, assume you want to create an SBOM for a Python application with the following requirements.txt: