SBOM under the Cyber Resilience Act: format, depth, signing, and update cadence

The short answer

CRA Annex I Part II requires manufacturers to draw up and maintain a machine-readable Software Bill of Materials (SBOM) for every product with digital elements. The regulation does not mandate a specific format, but SPDX 2.3+ and CycloneDX 1.5+ are the formats recognised in the ENISA guidance and expected by market surveillance authorities. Full CRA SBOM obligations apply from 11 December 2027.

What CRA Annex I requires

CRA Annex I Part II §1 states that manufacturers must:

"draw up and maintain a software bill of materials corresponding to the product with digital elements, including at least the top-level dependencies of the product"

Key elements derived from the text and ENISA guidance:

| Requirement | Detail |

|---|---|

| Format | Machine-readable — SPDX 2.3/3.0 or CycloneDX 1.5 are the recognised options |

| Minimum depth | Top-level dependencies at minimum; transitive dependencies strongly recommended |

| Content | Component name, version, supplier, license, known vulnerabilities (VEX recommended) |

| Currency | Updated on each product release or significant component change |

| Availability | Available to market surveillance authorities on request; not required to be public |

SPDX vs CycloneDX

| Dimension | SPDX 2.3 / 3.0 | CycloneDX 1.5 |

|---|---|---|

| Governing body | Linux Foundation | OWASP |

| ISO standard | ISO/IEC 5962:2021 (SPDX 2.2) | — |

| Format | RDF, JSON, YAML, tag-value | JSON, XML |

| VEX support | SPDX 3.0 native VEX | CycloneDX VEX document (separate) |

| Tooling | syft, SPDX tools, FOSSology | Dependency-Track, cdxgen, Grype |

| CRA guidance | Referenced in ENISA SBOM guidance | Referenced in ENISA SBOM guidance |

| Best for | License compliance + security hybrid | Security-focused, richer metadata |

Practical recommendation: Both formats satisfy CRA Annex I. Choose based on your existing toolchain. If you have no existing SBOM tooling, CycloneDX + cdxgen integrates faster into most CI pipelines. If you need ISO alignment for procurement, SPDX 2.3 is the safer choice.

Minimum required fields (both formats)

An SBOM that satisfies CRA Annex I at minimum must include for each component:

Fields 1–5 are the minimum. Field 6 (VEX) is strongly recommended for CRA compliance and is required for effective Art. 14 vulnerability triage.

• Component name — package name as published
• Component version — exact version string (not a range)
• Supplier / originator — organisation or individual maintaining the component
• License — SPDX license identifier (e.g. Apache-2.0, MIT)
• Package URL (PURL) — machine-readable identifier (e.g. pkg:npm/lodash@4.17.21)
• Known vulnerabilities — CVE references or VEX assertions at time of generation

Depth: top-level vs transitive

CRA Annex I specifies "at least the top-level dependencies." In practice:

For products with a large dependency tree (e.g. Node.js or Python applications), full transitive SBOMs can contain thousands of components. This is normal and expected.

• Top-level only satisfies the legal minimum but provides limited security value — a vulnerability in a transitive dependency will not appear
• Full transitive is the industry standard (syft, cdxgen default) and what MSAs and procurement teams will expect
• Recommended depth: full transitive, filtered to production dependencies (exclude dev/test-only)

Signing the SBOM

CRA does not mandate SBOM signing, but signing provides two practical benefits:

Recommended signing approach:

• Tamper-evidence — proves the SBOM has not been altered after generation
• Procurement leverage — signed SBOMs are increasingly required in enterprise procurement and US federal supply chain contexts (NIST SP 800-218A)
• Sigstore / cosign — keyless signing, widely adopted in open-source ecosystems
• PGP / GPG — traditional key-based signing, still common in enterprise contexts
• NexCyber MRCC — when your SBOM is submitted as evidence in a gap assessment, NexCyber includes a hashed reference in the MRCC (SHA-256 manifest hash), providing indirect attestation

Update cadence

Your SBOM must reflect the current state of your product. Recommended update triggers:

| Event | SBOM action |

|---|---|

| New product release | Regenerate SBOM, version it with the release tag |

| New dependency added | Update SBOM (automated via CI) |

| Dependency version update | Update SBOM |

| Known vulnerability discovered | Add/update VEX assertion |

| Annual compliance review | Verify SBOM currency, archive previous version |

Integrating SBOM generation into your CI/CD pipeline (pre-release gate) is the only sustainable approach. Manual SBOM generation creates drift and fails at the 24h Art. 14 notification timeline.

SBOM and CRA Article 14

An up-to-date SBOM directly enables Art. 14 compliance:

→ CRA Article 14 — vulnerability reporting workflow

• When an actively exploited vulnerability is reported, you can immediately check whether your product is affected by querying your SBOM against the CVE
• Without a current SBOM, confirming impact within 24 hours is operationally very difficult for products with more than ~50 dependencies
• A machine-readable SBOM with PURL identifiers enables automated CVE matching (Grype, OSV-Scanner, Dependency-Track)

SBOM and NIS2

NIS2 Art. 21(2)(e) requires supply chain security measures. An SBOM satisfies this requirement for the software component inventory dimension — see NIS2 × CRA overlap.

Tools and resources on NexCyber

This page provides regulatory guidance for informational purposes. It is not legal advice. ENISA SBOM guidance and CRA delegated acts may add requirements after publication. For compliance decisions, consult the applicable market surveillance authority or a qualified legal adviser.

NexCyber — EU Market Access Compliance Platform

• CRA gap assessment — includes SBOM evidence collection (account required)
• CRA Scope Checker — confirm whether CRA applies to your product
• CRA regulations overview