Core Concepts

This guide explains the fundamental concepts you need to understand for CRA compliance and how CRA Evidence helps you achieve it.

What is the Cyber Resilience Act (CRA)?

The Cyber Resilience Act (Regulation (EU) 2024/2847) is an EU regulation establishing cybersecurity requirements for products with digital elements sold in the European Union.

Why Does CRA Exist?

Before CRA, cybersecurity for connected products was largely voluntary. This led to:

• Products shipped with known vulnerabilities
• No requirement to provide security updates
• Consumers unable to assess product security
• Supply chain risks from untracked software components

CRA addresses these issues by requiring manufacturers to:

1. Design products securely from the start
2. Track software components in their products
3. Fix vulnerabilities throughout the product lifecycle
4. Report serious vulnerabilities to authorities
5. Keep documentation for regulatory oversight

Who Must Comply?

CRA applies to manufacturers of products with digital elements that are:

• Placed on the EU market (sold, even if free)
• Connected directly or indirectly to networks or devices

This includes:

• Software applications
• IoT devices
• Industrial control systems
• Network equipment
• Consumer electronics with software

Exemptions include:

• Pure SaaS (no software distributed to user devices)
• Medical devices (covered by MDR)
• Vehicles (covered by vehicle regulations)
• Open source developed non-commercially

---

Products with Digital Elements (PDEs)

A Product with Digital Element (PDE) is CRA's term for any product that includes software or can connect to a network.

Examples of PDEs

What CRA Evidence Calls Them

In CRA Evidence:

• Product = Your PDE (the thing you sell/distribute)
• Version = A specific release of your product
• Artifacts = Evidence files attached to a version (SBOMs, documents)

---

The CRA Evidence Data Model

Understanding how CRA Evidence organizes information:

Organisation (your company)
    |
    +-- Product (your PDE)
    |       |
    |       +-- Version (e.g., v1.0.0, v2.1.0)
    |               |
    |               +-- SBOM (software component inventory)
    |               +-- HBOM (hardware component inventory)
    |               +-- VEX (vulnerability status)
    |               +-- Documents (risk assessment, user manual, etc.)
    |
    +-- Vulnerabilities (tracked across products)

Organisation

Your company. Contains:

• Company contact information (for CE marking, Annex II)
• CSIRT member state designation (for ENISA reporting)
• Billing and storage settings

Product

A product with digital elements. Contains:

• Product name and description
• CRA category classification
• Multiple versions

Version

A specific release of your product. Contains:

• Version number and release date
• Support period (end of support date)
• CRA readiness status
• All compliance artifacts

---

Artifacts: What You Need to Upload

Artifacts are the evidence files that demonstrate compliance. CRA Evidence supports:

SBOM (Software Bill of Materials)

What: A machine-readable list of software components in your product.

Why Required: CRA Article 13(6) requires manufacturers to identify and document components.

Formats: CycloneDX JSON, SPDX JSON

Quality Matters: BSI TR-03183 defines quality expectations. CRA Evidence scores your SBOM and highlights gaps.

See SBOM Guide for details.

HBOM (Hardware Bill of Materials)

What: A list of hardware components (for products with physical elements).

Why Relevant: Hardware components can have firmware vulnerabilities.

When Needed: For products that combine software with custom hardware.

VEX (Vulnerability Exploitability eXchange)

What: Statements about which vulnerabilities affect your product and how.

Why Relevant: Not all vulnerabilities in components affect your product. VEX documents your analysis.

Format: CycloneDX VEX (part of SBOM) or standalone

Documents

What: PDF/document files for CRA requirements.

Required Documents:

See Documents Checklist for the complete list.

---

CRA Readiness Levels

CRA Evidence tracks your compliance status with two levels:

Incomplete

Meaning: Missing one or more CRA requirements — no SBOM, missing required documents, or key fields not filled.

Action: Upload SBOM and required documents.

Ready

Meaning: All basic requirements met for technical file export.

Achieved When:

• SBOM uploaded with acceptable quality
• All required documents present
• Product and version information complete
• Support period defined

Note: "Ready" means CRA Evidence has the information it needs. Actual CRA compliance also requires the content of documents to be accurate and complete.

---

Quality Scoring (TR-03183)

CRA Evidence evaluates SBOM quality based on BSI TR-03183 recommendations:

What's Measured

Score Ranges

Why Quality Matters

Higher quality SBOMs enable:

• Better vulnerability detection: PURLs are needed to match components to CVE data
• Supply chain traceability: Supplier information shows where components come from
• Integrity verification: Hashes prove you have the expected component version
• Regulatory confidence: Demonstrates due diligence in component management

---

Key CRA Dates Timeline

Understanding the compliance timeline is critical for planning:

CRA TIMELINE

Dec 2024            Sep 2026              Dec 2027
   |                   |                     |
   v                   v                     v
+------+           +--------+           +----------+
| CRA  |           |Reporting|          |  Full    |
|Enters|           |Obligations|        |Enforcement|
|Force |           | Apply   |          |          |
+------+           +--------+           +----------+

   |                   |                     |
   |                   |                     |
   v                   v                     v

We are               24h/72h/14d           All products
here                 notification          must comply
                     to ENISA              with Annex I
                     for actively          requirements
                     exploited CVEs

December 10, 2024: CRA Entered into Force

The regulation is now law. The transition period has begun.

What This Means:

• Start preparing for compliance now
• New products should be designed with CRA in mind
• Build your SBOM generation into development processes

September 11, 2026: Reporting Obligations Begin

You must report actively exploited vulnerabilities to ENISA.

Timeline for Actively Exploited Vulnerabilities:

What This Means:

• Need a process to detect when vulnerabilities are exploited
• Need rapid response capability
• CRA Evidence tracks these deadlines automatically

December 11, 2027: Full Enforcement

All products with digital elements must comply with CRA requirements.

What This Means:

• Products must meet essential security requirements (Annex I)
• Technical documentation must be available (Annex VII)
• CE marking required
• Market surveillance authorities can take action

---

Product Categories and Conformity Assessment

CRA defines different requirements based on product risk:

Default Products

Most products fall here. Self-assessment is sufficient.

Examples: Internal business applications, consumer apps, most software

Assessment: Module A (internal production control)

Important Class I (Annex III Part I)

Higher-risk products with security functions.

Examples:

• Password managers
• VPN software
• Network management systems
• SIEM solutions
• Browsers

Assessment: Self-assessment with harmonised standards OR third-party assessment

Important Class II (Annex III Part II)

Critical security products.

Examples:

• Operating systems
• Hypervisors
• Container runtimes
• Firewalls and IDS/IPS
• Microcontrollers

Assessment: Third-party assessment required

Critical Products (Annex IV)

Highest-risk products.

Examples:

• Hardware security modules (HSMs)
• Smartcard readers
• Industrial control systems
• Smart meters

Assessment: Third-party assessment required (most stringent)

---

How CRA Evidence Helps

CRA Evidence provides tools to manage your CRA compliance:

---

Next Steps

Now that you understand the concepts:

1. Quickstart Guide - Set up your first product (if you haven't)
2. SBOM Guide - Learn how to generate and improve SBOMs
3. Documents Checklist - Understand what documents you need

---

Glossary