Does the CRA require SBOMs to be public?

No — the SBOM must exist in a commonly used machine-readable format covering at least top-level dependencies, but publication is not required.

Which SBOM format does the CRA mandate?

None yet. An implementing act on format is provided for (Art 13(24)) but not adopted at our verification date — CycloneDX and SPDX are convention, not law.

How deep must a CRA SBOM go?

The floor is top-level dependencies. Operationally, it must be deep enough to answer component-vulnerability exposure questions, because it feeds the remediation and reporting machinery.

Kilde › Guides › CRA › The CRA's SBOM requirement: what it de…

The CRA's SBOM requirement: what it demands, and the two things it doesn't

Current to 26 August 2026 · updates land in the changelog.

The CRA makes the software bill of materials a legal artifact. Within the vulnerability-handling requirements, manufacturers must identify and document the product's vulnerabilities and components — including an SBOM in a commonly used, machine-readable format, covering at the very least the top-level dependencies (the definition sits in Article 3(39)).

The two things it does not demand

First, publication: the SBOM is not required to be public — it exists for the manufacturer's own handling process and for authorities on request. Second, a specific format: an implementing act on SBOM format is provided for (Article 13(24)) but none has been adopted at our verification date — so CycloneDX and SPDX are convention, not law. Both facts matter commercially: teams over-scope by assuming public full-depth SBOMs, and vendors sell format certainty that does not exist yet. When a format act lands, it lands in our updates feed.

Top-level is the floor, not the target

The at-least-top-level rule sets the compliance floor, but the SBOM's job in the CRA machine is operational: it feeds the duty to remediate without delay and the component due-diligence duty (Article 13(5)) — exercising due diligence on third-party components, and reporting vulnerabilities you find in them to the component's maintainer (13(6)). A one-level SBOM that can't answer “are we exposed to this CVE?” satisfies the letter while failing the machine it serves.

Making it real before 2027

The workable sequence: generate at build time (not as an annual artifact), reconcile against what actually ships, and wire the SBOM to your vulnerability intake so component advisories map to affected products automatically — that mapping is precisely what a 24-hour early-warning clock will demand of you from September 2026 when an exploited component vulnerability lands in your stack.

Related guides

Quick answers

Does the CRA require SBOMs to be public?: No — the SBOM must exist in a commonly used machine-readable format covering at least top-level dependencies, but publication is not required.
Which SBOM format does the CRA mandate?: None yet. An implementing act on format is provided for (Art 13(24)) but not adopted at our verification date — CycloneDX and SPDX are convention, not law.
How deep must a CRA SBOM go?: The floor is top-level dependencies. Operationally, it must be deep enough to answer component-vulnerability exposure questions, because it feeds the remediation and reporting machinery.

Be reporting-ready before 11 September 2026.

The CRA Reporting-Ready Pack: the staged 24h / 72h / final-report runbook and templates, vulnerability-vs-incident triage worksheet, CSIRT-routing and main-establishment worksheet, platform registration runbook, CVD policy and evidence log — built from the regulation and the ENISA platform guides, with pinpoint citations.

Get the pack — US$390 Free 4-page sample (PDF)

Instant download · 14-day unconditional refund · single-organisation licence · full product page

General information only — not legal advice, and never a conformity assessment. Whether a specific product falls in a listed category is decided against the binding technical descriptions in Implementing Regulation (EU) 2025/2392, and reporting-platform mechanics are ENISA-published material marked subject to change. Sources are Regulation (EU) 2024/2847 (CELEX 32024R2847; Annex III/IV item texts read verbatim from EUR-Lex) and our audited kit research. © 2026 Kilde.

Built by Kilde's founder, a practising attorney admitted to a US state bar (not an EU or Hong Kong admission). About · Verification log · Refunds · Terms · Privacy · esau@trykilde.com