Cyber Resilience Act (CRA) Requirements Explained

TL; DR

The Cyber Resilience Act (CRA) introduces binding essential cybersecurity requirements for products with digital elements placed on the EU market. Most CRA obligations apply 36 months after entry into force, with earlier deadlines for vulnerability reporting. Manufacturers must implement secure-by-design development, coordinated vulnerability disclosure, and maintain technical documentation demonstrating lifecycle security. In practice, CRA compliance depends on continuous transparency into software components and embedded cryptographic functions.

Cyber Resilience Act: Requirements, Timeline and Compliance Impact

The Cyber Resilience Act (CRA) represents the first horizontal EU regulation imposing mandatory cybersecurity requirements directly on products with digital elements placed on the European market. It converts cybersecurity into an enforceable condition for market access as it will form part of the CE marking.

The Regulation introduces a phased implementation period. For organisations distributing software, embedded systems or connected devices in the EU, the issue is simple: do you know what you ship?

When Did the CRA Enter Into Force?

The Cyber Resilience Act (CRA) was formally adopted in October 2024, following negotiations between the European Commission, the Parliament and the Council. In December 2024, it was published in the Official Journal of the European Union (EU) 2024/2847.

From that date, the compliance clock started.

The CRA introduces a phased transition. By around September 2026 — 21 months after entry into force — manufacturers must be able to operate a coordinated vulnerability disclosure process and report actively exploited vulnerabilities to ENISA and CSIRT. By approximately December 2027 — 36 months after entry into force — the essential cybersecurity requirements in Annex I must be fully applied to products placed on the EU market.

That includes secure-by-design development, delivery without known exploitable vulnerabilities, and mechanisms to provide security updates during the support period.

The 36-month window can appear generous. It is not. Building reliable visibility into what software components and cryptographic libraries are embedded across a product portfolio is not a last-minute compliance exercise. It requires structured processes, repeatable detection and documentation that reflects reality.

It is important to note that the scope is market-based. A manufacturer headquartered outside the EU falls under the CRA if it places products with digital elements on the EU market. Geography does not exempt responsibility.

What Does the CRA Mean for Software Supply Chain Visibility?

Under Article 14, the CRA requires manufacturers to operate a vulnerability disclosure process, report actively exploited vulnerabilities to ENISA and CSIRT, and issue security updates without delay.

In practice, this does not mean tracking every vulnerability published globally. It means being able to determine — immediately — whether a disclosed vulnerability affects software or hardware inside your product.

That is only possible if you know what you ship.

If a critical vulnerability is announced in a widely used library, the first question is “do we use it?” If you cannot answer that quickly and confidently, you have a problem.

This is where software supply chain visibility becomes central to CRA compliance.

The CRA does not explicitly mandate a Software Bill of Materials (SBOM) in all cases. However, its documentation and vulnerability handling requirements make structured component visibility operationally necessary. This means maintaining a continuously updated SBOM that reflects what is actually embedded in a product.

To meet CRA obligations, manufacturers must be able to:

• Identify incorporated software components

• Determine whether those components are affected by newly disclosed vulnerabilities

• Issue updates and document remediation if the vulnerability is exploitable

An SBOM can support this, but only if it functions as living infrastructure. A static inventory generated at release is insufficient.

CRA compliance ultimately depends on visibility, not only at the component level, but at the algorithm level. This is where a Cryptography Bill of Materials (CBOM) becomes relevant.

Cryptographic libraries are frequently embedded deep within dependency chains and are not always visible through package manifests alone. When a vulnerability affects an encryption implementation, you must determine exposure immediately.

If you cannot identify which cryptographic algorithms are present in your software — including inherited or hard-coded implementations — you cannot confidently assess risk, plan remediation, or demonstrate lifecycle control.

Under the cybersecurity risk analysis required by the CRA, cryptographic visibility therefore becomes part of regulatory readiness. A traditional SBOM may identify that a library is present; a CBOM approach identifies which cryptographic algorithms are actually implemented and exposed.

Even though the CRA does not mandate post-quantum algorithms, it does require manufacturers to manage cryptographic risk over the product lifecycle.

How Does the CRA Interact With Other EU Regulations?

The CRA does not operate in isolation. It sits alongside other EU cybersecurity instruments, including the Digital Operational Resilience Act (DORA) and the NIS2 Directive.

DORA focuses on ICT risk management in the financial sector. NIS2 strengthens cybersecurity obligations for essential and important entities across critical industries. The CRA, by contrast, governs the security of the products themselves.

For technology vendors supplying some regulated sectors, these frameworks overlap. A product that fails CRA requirements may create downstream compliance risk for customers subject to DORA or NIS2.

What Should Organisations Do Now to Prepare for CRA Compliance?

Organisations should already be:

• Establishing continuous visibility into incorporated software components

• Ensuring vulnerability workflows can correlate newly disclosed CVEs to affected products

• Identifying embedded cryptographic libraries and algorithms that may not appear in package manifests

• Aligning technical documentation with actual product composition

The preparation window has already begun.

For many manufacturers, the challenge is knowing what is actually present inside a product, including inherited open source components and embedded cryptographic routines.

SCANOSS supports this by enabling continuous, code-level identification of open source components within development workflows. Its API-first approach allows integration into CI/CD pipelines, helping teams maintain an up-to-date inventory as code evolves.

Beyond dependency manifests, SCANOSS detects inherited and snippet-level components that may otherwise remain undocumented. Crypto Finder extends this visibility further by identifying cryptographic implementations directly in source code — making encryption usage explicit.

Together, these capabilities help organisations move from static documentation to verifiable, continuous visibility.

CRA compliance ultimately depends on being able to answer a simple question with confidence: what is inside our products?

If that answer is uncertain, the time to address it is now.