CRA SBOM Requirements: Format, Scope, Updates and Retention
The CRA requires every product with digital elements to ship with a machine-readable Software Bill of Materials (SBOM) that lists its software components and covers at least their top-level dependencies. The SBOM lives in your technical documentation and has to be ready for a market surveillance authority on request, not filed in advance.
Summary
- Every product with digital elements needs a machine-readable SBOM as part of its vulnerability-handling evidence. It is mandatory, with no size-based exemption.
- The legal minimum is top-level dependencies. Transitive coverage is stronger practice and what most SBOM quality frameworks expect.
- One product means one body of SBOM evidence, even when the product is built from many repositories or components.
- Keep the SBOM current during the support period, especially after releases, component changes and vulnerability decisions.
- Store the SBOM with the technical documentation for at least 10 years, or the support period if that is longer.
- Vulnerability reporting duties start 11 September 2026; full CRA application is 11 December 2027.
What is an SBOM?
A Software Bill of Materials (SBOM) is a structured inventory of the software inside a product: libraries, frameworks, operating-system packages, and the dependencies between them. For the CRA it is the record a market surveillance authority would use to check which of your components are affected by a reported vulnerability, so it has to be machine-readable rather than a prose document.
What the CRA requires in an SBOM
The SBOM obligation has two practical layers: what the inventory has to cover, and where the evidence has to sit in the technical file.
Which components must the SBOM cover?
Manufacturers have to identify and document the components and vulnerabilities in their products with digital elements, and draw up an SBOM in a commonly used, machine-readable format that covers at least the product's top-level dependencies.
This means:
- The SBOM has to be machine-readable and in a commonly used format. A PDF or spreadsheet can help people review the inventory, but it does not replace the SBOM file.
- It has to cover at least the top-level dependencies. Transitive coverage goes beyond the bare floor, and it is the better baseline for vulnerability monitoring.
Every product with digital elements placed on the EU market must have a machine-readable SBOM. There is no opt-out and no size threshold below which the obligation disappears. How much detail you document scales with the product's risk, but the duty to draw up an SBOM does not.
Right now the rules only ask for a commonly used, machine-readable format covering at least the top-level dependencies. They do not name a specific format or a fixed field list. That floor can be raised: the CRA leaves room for the Commission to set out an exact SBOM format and field set later. Choosing a well-supported format now, CycloneDX or SPDX, and capturing more than the bare minimum, is the safest hedge against a future prescribed format.
Where the SBOM sits in the technical file
The SBOM is part of your technical documentation, filed alongside the rest of the vulnerability-handling evidence: the coordinated vulnerability disclosure policy, a contact address for reporting, and how you distribute updates securely. You do not submit it in advance. It has to exist when the product is placed on the EU market and be ready for a market surveillance authority if they make a reasoned request.
In practice the SBOM should let you do component-level vulnerability tracking, supplier and origin checks, license review and end-of-life planning.
How many SBOMs does one product need?
A product is often built from many repositories and components, and each can emit its own SBOM. The CRA fixes the unit of evidence at the product, not the repository or the build.
The CRA defines an SBOM as a record of the components in a product's software and how they relate, and it expects that record to cover at least the product's top-level dependencies. The evidence object is the product you place on the EU market, identified by product and version. A product assembled from ten repositories is not covered by ten loose component SBOMs that nothing ties together. You owe SBOM evidence that represents the product as shipped.
The CRA does not mandate a single physical file, and it does not forbid keeping component SBOMs. Two routes both work, as long as the result is machine-readable, sits at product level, and covers at least the top-level dependencies:
- Compose. Keep component SBOMs as separate documents and link them into a product SBOM, using CycloneDX assembly components with BOM-Link references, or SPDX relationships with external-document references.
- Merge. Flatten every component into one CycloneDX or SPDX document for the product version.
Because the SBOM is meant to capture how components relate, a flat list of package names is not enough on its own. Whichever route you pick, the SBOM should show how components depend on and contain each other, which both CycloneDX dependency graphs and SPDX relationships provide. For the format mechanics, see CycloneDX vs SPDX.
Who has to receive the SBOM?
The SBOM is technical-file material, not a public document. The CRA does not require you to publish it, and the only party that can compel it is a market surveillance authority, which can ask for it on a reasoned request when it needs to check your compliance. Sharing the SBOM with users is optional. If you do choose to share it with users, you then have to tell them where to find it.
| Who | What the CRA expects |
|---|---|
| Market surveillance authority | Can request the SBOM on a reasoned request, when it is needed to check compliance |
| Users and the public | No duty to publish or hand it over; sharing is your choice |
| Importers and distributors | No right to the SBOM itself; they have to be able to get your technical documentation to authorities on request |
| Integrators building on your product | Where your product is meant to be integrated into theirs, you give them the information they need to meet their own obligations, which is not automatically the full SBOM |
Do not publish the SBOM or push it to users by default. An SBOM is a precise map of your components and versions, which is exactly what an attacker wants, and the CRA gives you no duty to hand it out broadly. Release it to a market surveillance authority when it makes a reasoned request, and to business customers who build on your product, under an NDA or contract, because they need it to assemble their own product-level SBOM and meet their own obligations. Keep a record of who received which version.
What the SBOM Must Include
Separate the CRA legal floor from the fields that make the SBOM usable in real vulnerability workflows. The regulation sets the minimum. TR-03183, CycloneDX/SPDX tooling and customer expectations usually push the operational bar higher.
| Area | CRA floor | Strong implementation |
|---|---|---|
| Format | Commonly used and machine-readable | CycloneDX JSON/XML or SPDX JSON/tag-value, generated by build tooling |
| Scope | At least top-level dependencies | Direct and transitive dependencies, internal libraries, firmware and OS packages where applicable |
| Components | Components contained in the product | Component name, version, supplier, package URL or CPE, hash and relationship data |
| Vulnerabilities | Components and vulnerabilities identified and documented | Current vulnerability status, VEX or exploitability decision, remediation reference and review date |
| Technical-file evidence | SBOM included with vulnerability-handling process evidence | Stable file reference per product version, generation tool, generation date and validation result |
| Authority access | Available where needed for a reasoned market-surveillance request | Secure archive with retrieval owner, integrity controls and support-period coverage |
The CRA requires you to identify and document vulnerabilities, but that does not mean the vulnerability or VEX data has to live inside the SBOM file itself. Carrying it there is good practice, not a floor. For the field requirements that go beyond this checklist (PURL identifiers, hash values, document metadata), see how BSI TR-03183 extends the CRA. For a comparison of CycloneDX and SPDX tooling, see CycloneDX vs SPDX.
What a technical-file SBOM summary looks like
A strong technical file pairs the machine-readable SBOM with a short summary record. The summary is a cover sheet for human review. The actual SBOM is the attached CycloneDX or SPDX file it points to.
TECHNICAL-FILE SBOM SUMMARY
Product: SmartSense Pro (SSP-3000)
Firmware Version: 2.4.1
SBOM Format: CycloneDX 1.6
Generated: 2027-01-15
Tools: Syft (generation), Trivy (scanning)
SBOM FILE:
sbom-ssp3000-v2.4.1.json (attached, machine-readable)
COMPONENT SUMMARY:
-------------------------------------------------------------
Total Components: 127
Direct Dependencies: 23
Transitive Dependencies: 104
By Type:
Libraries: 98
Frameworks: 12
Operating System: 1 (FreeRTOS)
Firmware Modules: 16
VULNERABILITY STATUS AT ASSESSMENT:
-------------------------------------------------------------
Scan Date: 2027-01-17
Scanner: Trivy v0.48.0
Critical: 0
High: 0
Medium: 2 (accepted - see below)
ACCEPTED VULNERABILITIES:
CVE-2026-15432 (Medium): libexpat 2.5.0
Status: Not exploitable in our configuration
Justification: Feature not enabled, code path not reachable
Review Date: 2027-04-15
-------------------------------------------------------------
When to Update Your SBOM
The SBOM is not a one-time document. Your technical documentation has to be drawn up before the product goes on the market and kept up to date, where appropriate, at least through the support period. The support period reflects how long the product is expected to be in use, and it is at least five years unless the product is genuinely expected to be in use for less.
Review or regenerate the SBOM when:
| Trigger | What changes | Practical action |
|---|---|---|
| New firmware or software version | New build artifact | Regenerate the SBOM for that product version |
| Security patch release | Component version changes | Update affected components and archive the new SBOM |
| Vulnerability discovered and assessed | VEX or exploitability status changes | Update vulnerability status and decision evidence |
| Component added, removed or replaced | Dependency graph changes | Regenerate and validate the SBOM |
| Security-relevant design change | Components or architecture change | Regenerate the SBOM and update technical-file references |
| Applied standards or specifications change | Compliance metadata changes | Review metadata and linked evidence |
Periodic reviews. The CRA does not set a fixed review interval. These cadences are a practical baseline:
| Cadence | Scope |
|---|---|
| Quarterly | SBOM and vulnerability status |
| Annually | Full technical file review |
| Before support period end | Final documentation freeze |
Every build should produce a current SBOM artifact, so the evidence stays in step with what you ship. See common SBOM mistakes for what goes wrong when teams skip automation.
How Long to Keep SBOM Evidence
Keep the SBOM with the technical documentation for at least 10 years after the product with digital elements has been placed on the market, or for the support period if that is longer. The same retention rule applies to the technical documentation and the EU declaration of conformity. This is about keeping the documentation. It is separate from the duty to keep the security updates themselves available, which runs for its own ten years from when each update ships.
For a product line sold over time, keep evidence for the versions and units placed on the market. Do not treat the first launch date as the practical end of the evidence obligation while later units or versions are still being supplied.
| Milestone | Example date |
|---|---|
| Product first placed on market | March 2027 |
| Last unit placed on market | December 2030 |
| Practical evidence coverage | Through December 2040 or longer if the support period requires it |
The clock runs from the last unit placed on the market, so December 2030 plus ten years reaches at least December 2040, longer if the support period extends past that. Store the SBOM somewhere secure and backed up, with integrity protection, so you can retrieve and supply the right version on a reasoned request.
Dates and Enforcement
Full CRA application is 11 December 2027. The vulnerability reporting duty starts earlier, on 11 September 2026. That earlier date is not a separate SBOM filing deadline, but it does require you to know quickly which product versions and components are affected by a reportable vulnerability or incident. For products placed on the EU market after full application, the SBOM is part of the evidence base behind conformity assessment, the EU declaration of conformity and CE marking. For the reporting workflow, see CRA vulnerability and incident reporting. For the general CRA timeline, see what the CRA is; for the penalty table, see CRA penalties and enforcement.
Frequently Asked Questions
Does the CRA require a machine-readable SBOM or is a PDF acceptable?
The SBOM must be in a commonly used, machine-readable format. A PDF or spreadsheet can accompany the file for human review, but it does not replace the SBOM. CycloneDX or SPDX serialized as JSON or XML is the practical route.
Does the CRA require an SBOM for open-source components?
Yes. Open-source components are still components contained in the product, so they belong in the SBOM with version and identifier information. The CRA also expects you to exercise due diligence over the third-party components you integrate, including open-source software that was not supplied to you commercially, and to report any vulnerability you find in an integrated component, including an open-source one, to whoever maintains it.
When must an SBOM be submitted: at market placement or on request?
The SBOM is not normally submitted proactively. It must be part of the technical documentation, ready and available to market surveillance authorities on reasoned request, and it must exist when the product is placed on the EU market.
What are the NTIA minimum elements and do they satisfy CRA requirements?
The NTIA minimum elements (supplier name, component name, version, unique identifiers, dependency relationships, SBOM author and timestamp) are a reasonable starting point. They do not by themselves answer every CRA evidence question or every TR-03183 quality expectation. For CRA work, validate the generated file against your chosen format, record vulnerability status, and fill richer fields such as PURL/CPE, hashes and relationship data where your quality framework requires them.
Can I reuse SBOMs from my suppliers to satisfy the CRA?
Partially. Supplier SBOMs are valid inputs for the parts they ship, but you still owe one SBOM for the product as placed on the market. That means consolidating supplier SBOMs with your first-party components and build dependencies into product-level evidence, as covered above in how many SBOMs one product needs. Treat supplier SBOMs as raw material, not as the finished compliance artifact.