Core Concepts

This guide explains how CRA Evidence models your compliance data: products, versions, SBOMs and quality scores, readiness status, artifacts, and retention.

New to the Cyber Resilience Act itself? The regulatory background (what the CRA is, why it exists, who must comply, exemptions, and key dates) lives on the CRA compliance hub: What is the CRA? and the CRA compliance hub. This guide covers only how the product works.

---

The CRA Evidence data model

Understanding how CRA Evidence organises information:

Organisation (your company)
    |
    +-- Product (your PDE)
    |       |
    |       +-- Component(s) (source repositories: one for a monolith,
    |       |                 one per repo for a multi-repository product)
    |       |
    |       +-- Version (e.g., v1.0.0, v2.1.0)
    |               |
    |               +-- SBOM (software inventory; attributed to the component it came from)
    |               +-- 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
• One or more components (its source repositories)
• Multiple versions

Component

A source code repository that makes up the product. A simple, single-repository product (a "monolith") has one component; a product assembled from several repositories has one component per repository.

Each component records the repository it maps to (VCS URL and, optionally, a subpath within the repo). When you upload SBOMs from CI, CRA Evidence attributes each SBOM to the component it came from (creating the component automatically on first sight), so a single version's SBOMs can span multiple repositories while staying organised by source.

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, for example no SBOM, missing required documents, or key fields not filled.

Action: Upload SBOM and required documents.

Ready

Meaning: The version meets all the CRA requirements that apply to its product category.

Achieved when every required item for the product category is complete. These include an SBOM with acceptable quality, the required documents, complete product and version information, and a defined support period, plus category-specific gates such as the conformity approach, applied standards, update-mechanism documentation, and CE marking. The version page shows the exact checklist and lists any missing items.

• 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 is 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

---

CRA dates and timeline

CRA Evidence tracks compliance deadlines for you (for example, ENISA reporting windows on a version). For the regulatory timeline itself (when the CRA entered into force, when reporting obligations begin, and the full enforcement date), see What is the CRA? on the compliance hub.

---

Product categories

When you create a product, CRA Evidence asks you to set its CRA category. The platform uses these categories to surface the right requirements and conformity-assessment route for that product:

• Default
• Important Class I
• Important Class II
• Critical

For the regulatory definitions of each category, which products fall into them, and which conformity-assessment module applies, see Product classification and Conformity assessment on the compliance hub.

---

How CRA Evidence helps

CRA Evidence provides tools to manage your CRA compliance:

---

Glossary