A Primer for the Cyber Resilience Act (CRA)

The Cyber Resilience Act (CRA) is a new cybersecurity regulation that aims to ensure the security of “products with digital elements” (PDEs) sold in the EU market. 

PDEs are defined as “any software or hardware product and its remote data processing solutions” – the regulation will apply to all digital elements with “a direct or indirect logical or physical data connection to a device or network.”

The compliance framework acknowledges the gap in existing EU cybersecurity regulations regarding vulnerabilities in PDEs, and will likely require significant changes for most software development and security teams that sell into EU markets.

To paraphrase, the CRA seeks to address the following challenges:

1. Widespread vulnerabilities within PDEs introduce considerable risk to EU consumers.

2. EU consumers lack the information they need to make informed decisions about the security of the products they purchase.

Much of the regulations focus on product security vulnerabilities that could provide hackers with access to sensitive information. To understand the types of vulnerabilities and attacks the European Commission is looking to prevent, the following excerpt from the first section of document one can give a good idea: “There are numerous examples of noteworthy cyberattacks resulting from suboptimal product security, such as the WannaCry ransomware worm, which exploited a Windows vulnerability that affected 200,000 computers across 150 countries in 2017 and caused a damage amounting to billions of USD; the Kaseya VSA supply chain attack, which used Kaseya’s network administration software to attack over 1,000 companies and forcing a supermarket chain to close all its 500 shops across Sweden; or the many incidents in which banking applications are hacked to steal money from unsuspecting consumers.”

To summarize the two main objectives of the regulations, the CRA aims to:

1. Reduce the vulnerabilities within PDEs on the market and ensure vendors have a plan to manage and respond to new vulnerabilities. 

2. Ensure consumers are equipped with the information they need to take cybersecurity into account when purchasing a product.

The rest of this article will explain some of the key components of the CRA, while suggesting technologies and processes to fulfill them. 

Many of these requirements will require changes to the way software developers build PDEs. Security technologies and processes are notorious in the development world for being burdensome and time-consuming, so we’ll also discuss methodologies for implementing these controls without disrupting the software development process.

The Basic Structure of the Cyber Resilience Act

The CRA consists of two documents. The regulation objectives and legal specifications are captured in 57 Articles described in the first document of the act, while continuously referring to Annexes in the second document.

Each Article describes specific requirements and definitions that can be broadly grouped into these categories:

• Requirements aligned with best practices for product security.

• Requirements aligned with best practices for security communication to consumers.

• Legal language that defines the scope of the regulations, definitions, penalties, auditor requirements, and other legal specifications.

The CRA covers a lot of ground. Below is a summary of its contents, which we will explore further in the following sections:

• Scope and Applicability: The CRA applies to any manufacturer of a digital product in the EU market, which ranges from consumer electronics like smart refrigerators, to critical infrastructure like identity management systems and microchips. 

• Security by Design: based on longstanding best practice, the CRA requires digital product manufacturers to bake security scanning and remediation into the software development process, while making it easy to update apps with security fixes.

• Vulnerability Management: build out processes that enable quick handling of new vulnerabilities throughout the product development lifecycle. Security incidents must be promptly reported to national cybersecurity authorities and, if severe, to the European Union Agency for Cybersecurity (ENISA).

• Conformity Assessments and Incident Reporting: digital product manufacturers must undergo routine assessments from reputable security auditors, which are to be selected by the national courts for each EU member state.

• Impact on Open Source and SaaS: the regulation includes extensive provisions around the use of open source software components, which can contain known security vulnerabilities. No known vulnerabilities are permitted within digital products on the EU market – a tough requirement for any software engineering team.

• Economic and Social Benefits: by strengthening cybersecurity measures and improving security-related communication with the market and regulators, the CRA aims to reduce the total cost of cybersecurity breaches and boost demand for digital products by increasing public trust and awareness.

Breaking Down Key Articles in the Cyber Resilience Act, and How to Fulfill Them

We won’t address all 57 Articles in the CRA, but we’ll review some of the key Articles that provide an overview of the technologies and processes that need to be implemented to address CRA requirements. Let’s get started.

Articles 1, 2, and 3

Before getting into the meat of the requirements, these initial Articles describe the subject matter, scope, and definitions for the rest of the regulation.

• Subject matter: Article 1 states that the regulation consists of rules surrounding the development of PDEs, the vulnerability management process throughout the product lifecycle, and security-related communication to the public. These rules will need to be met to sell PDEs in EU markets. There are other rules that describe enforcement mechanisms for the regulation.

• Scope: Article 2 describes the relevant products for this regulation while listing exemptions such as medical devices that are already covered by existing regulations.

• Definitions: Article 3 defines terms used throughout the regulation. Critically, it defines “Products with Digital Elements” (PDEs), which has significant implications for the scope – “‘product with digital elements’ means any software or hardware product and its remote data processing solutions, including software or hardware components to be placed on the market separately”.

Article 5

Now we begin with the actual requirements in the regulation. This Article is short, but it deserves special attention because it mandates PDEs meet the requirements described in Sections 1 and 2 of Annex I. The sections in this Annex lay out the core security requirements for building PDEs and managing vulnerabilities.

Let’s start with a table that summarizes some of the key requirements.

Section 1 of Annex I

This section lists the “Security Requirements related to cybersecurity for products with digital elements”. This includes but is not limited to, the following requirements.

Deliver products without known vulnerabilities

“Products with digital elements shall be delivered without any known exploitable vulnerabilities”

This is a big deal. Most modern software development teams heavily rely on open-source components – many of which contain known vulnerabilities documented as “Common Vulnerabilities and Exposures” (CVEs) by MITRE.

Manually documenting open-source components and mapping the CVEs within them isn’t scalable. To automate this process and generate reports to demonstrate compliance, organizations will need to adopt Software Composition Analysis (SCA) tools to continuously scan open-source components for CVEs so developers can remediate them. 

Open source tools like npm-audit and OSV scanner are great options to start with SCA for free. You can also use tools like Trivy to cover the open source dependencies. Since the requirements specified that PDEs will need to be delivered without known vulnerabilities, these tools will need to be integrated into the Software Development LifeCycle (SDLC), so that developers can surface and resolve CVEs before production.

While npm-audit and OSV Scanner are great tools, they will take time to implement and require developers to leave their environment, scroll through long backlogs of vulnerabilities, and manually research vulnerabilities to make the fix. 

Verify that each request is authenticated

“ensure protection from unauthorized access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems”

This requirement mandates that PDE developers verify that each request is authenticated. To fulfill this, you’ll need Dynamic Application Security Testing (DAST) tools like ZAP, which have specific rules that verifies the authentication methods for requests.

There are many ways to verify that each request is authenticated, such as monitoring logs, ensuring MFA is enabled for all users, using encryption, and others.

Guard against data manipulation

“protect the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration against any manipulation or modification not authorized by the user, as well as report on corruptions”

There are many ways attackers can gain access to sensitive data and manipulate it – one of the most common ways is through injection attacks, like SQL injection or cross-site scripting. These vulnerabilities enable attackers to run commands against a datastore to manipulate, steal, delete, or tamper with the data in other ways.

Similarly to the requirement above, you can use ZAP to scan your application for injection vulnerabilities. That said, DAST tools can only scan applications at runtime, which requires burdensome feedback cycles of triaging vulnerabilities back to developers to make the fix.

A more efficient approach is to catch injection attacks early in the SDLC. To do this, consider Static Application Security Testing (SAST) tools like Semgrep to scan code within the IDE or during the CI process. By providing quick feedback to developers on the security of their code, they can fix vulnerabilities before they make it to production.

You can also unify Semgrep SAST with the rest of your product security toolset with Jit, which provides an all-in-one platform for code and cloud security.

Section 2 of Annex I

Section 2 of Annex I describes the vulnerability management process and reporting requirements to demonstrate risk mitigation.

Generate and Continuously Update a Software Bill of Materials (SBOM)

“identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the product”

A Software Bill of Materials (SBOM) is a list of dependencies used in an application, which often contain vulnerabilities and the open source license associated with each dependency. This provides auditors with a complete view of the open source components used in PDEs, and whether they’re relying on insecure components. 

There are many options for generating SBOMs – simply google SBOM or investigate commercial application security solutions and you’re sure to find many options. If you’re looking for a fast and free way to get started, Syft is a great open source tool specifically designed to generate SBOMs. It is easy to set up and has integrations with tools like Grype, which can populate the Syft SBOM with vulnerabilities associated with each dependency.

Publicly disclose information about newly discovered vulnerabilities

“Once a security update has been made available, publically disclose information about fixed vulnerabilities, including a description of the vulnerabilities, information allowing users to identify the product with digital elements affected, the impacts of the vulnerabilities, their severity and information helping users to remediate the vulnerabilities”

This is an interesting one. The open-source community consists of developers who contribute to publicly available code. Transparency and knowledge sharing are some of its core pillars.

This requirement codifies this cultural element of software development into law. If you aren’t a responsible steward of open source who discloses new vulnerabilities and communicates them back to the maintainer, you could be violating the CRA.

Article 23

This article specifies the technical documentation required to communicate cybersecurity measures for PDEs.

“The technical documentation shall contain all relevant data or details of the means

used by the manufacturer to ensure that the product with digital elements and the

processes put in place by the manufacturer complies with the essential requirements

set out in Annex I. It shall at least contain the elements set out in Annex V.”

Annexes 1 and 2, as we know, list security requirements for developing PDEs and managing vulnerabilities. Annex V describes the specific documentation needed to demonstrate compliance with these requirements. This Article describes technical documentation elements such as:

• An in-depth description of the system architecture and data flow throughout the PDE.

• A description of the vulnerability remediation process, including the vulnerability disclosure policy.

• A report to demonstrate fulfillment of the processes articulated in Annexes 1 and 2. Again, product security tools like Semgrep, ZAP, and npm-audit will be needed to generate these reports.

• A contact address for anyone to report vulnerabilities within the organization’s PDE.

• Software versions for open-source components, which will require an SBOM or SCA solution.

This Article is squarely in line with the second Cyber Resilience Act objective, which aims to improve the security-related information available to consumers to help inform their purchasing decisions. 

Will consumers actually read this? Probably not many, but requiring this documentation is a positive step to demonstrate security readiness to the public.

Chapter IV and V – Notification of Conformity Assessment Bodies (Articles 25-49)

While the previous chapters focused on the requirements for PDE manufacturers to deliver secure products, these chapters set requirements for the compliance auditing and enforcement organizations. Specifically, the chapters define guardrails for:

1. The organizations that are permitted to assess PDE manufacturers’ compliance with the Cyber Resilience Act.
2. The organizations that are permitted to surveil the market and enforce penalties for noncompliance.

The EU will decentralize the auditing process for the Cyber Resilience Act to organizations that are approved by member nations. Each nation will need to evaluate and report authorized organizations to audit PDE manufacturers and enforce penalties – which will be another step before this act is applied to organizations selling PDEs in EU markets.

Article 27 describes the requirements that determine whether an organization is suitable for the auditing process – factors include no conflicts of interest, the ability to hire knowledgeable personnel, and the ability to keep confidential information secure.

For PDE manufacturers, there isn’t any new information about the specific requirements they’ll need to address. However, they may want to review these chapters to learn how PDEs will be evaluated, and who will evaluate them.

Chapters VI-VIII – Delegated Power, Penalties, and Transitional Provisions

These final chapters define which organizations have the power to amend the Cyber Resilience Act, penalties for non-compliance, and specifications for products currently on the market.

Article 53

This Article describes penalties for noncompliance with the Cyber Resilience Act.

It states that the fine for noncompliance with Annex I is up to 15,000,000 EUR or up to 2.5% of the annual worldwide turnover for the previous financial year (whichever is higher). Wow! Interestingly, the fine for noncompliance with all other requirements is lower – up to 10,000,000 EUR or up to 2% of annual worldwide turnover for the previous financial year (whichever is higher). Time to double check those Annex 1 rules.

As a reminder, Annex 1 describes the security requirements needed to build PDEs, while other Annexes define requirements for vulnerability management and security information communication.

The fine for misleading auditors is up to 5,000,000 EUR or up to 1% of annual worldwide turnover…so no short cutting.

This Article also states that national courts for member states will determine the fines depending on the nature, gravity, duration of the offense, the size of the offender, and whether fines have already been applied for similar infringements. 

Beyond financial penalties, the regulation states that the enforcement organizations could force the PDE manufacturer to withdraw their product from the market altogether.

Article 55 

This article specifies the compliance requirements for PDEs already on the market.

It states that PDEs already on the market will not be subject to the Cyber Resilience Act regulations unless “those products are subject to substantial modifications in their design or intended purpose.”

This introduces some legal gray areas, which will have to be interpreted by the Member State courts.

Next Steps for Gaining Achieving Compliance with the Cyber Resilience Act

According to Article 57, the Cyber Resilience Act will take effect 20 days after it is published in the Official Journal of the European Union. It was recently approved by the EU parliament, and will now need to be formally adopted by the European Commission.

As discussed throughout the article, PDE manufacturers will need to implement a set of security technologies, processes, and reporting mechanisms to demonstrate compliance. Such security processes are notorious for burdening engineers and slowing down software development.

If you’re looking for a way to implement the security controls described in this article without slowing down developers, try Jit, which integrates SAST, SCA, SBOM, and DAST controls across code repositories in a few minutes.

Critically, Jit delivers these controls entirely within the developer environment, so developers don’t need to context switch during the scanning and remediation process. Jit provides immediate feedback on each code change – making it easy for developers to independently and consistently resolve product security issues before production.

Get started with Jit for free, learn how it works, or book a demo to achieve some of these core CRA requirements quickly.