Full CRA enforcement begins 11 December 2027. After that date, every product with digital elements placed on the EU market must carry CE marking, and CE marking requires a compliant SBOM. Annex I, Part II, point (1) is the operative clause: manufacturers must "identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products". That phrase determines format, scope, and where the SBOM must live in your technical file. This page covers exactly what the law requires and what it does not.
Summary
- SBOMs are mandatory under Annex I, Part II, point (1) for every product with digital elements
- Format must be machine-readable (CycloneDX or SPDX; PDFs and spreadsheets do not qualify)
- Minimum coverage: top-level dependencies of the products; transitive coverage is best practice but beyond the legal floor
- The SBOM is part of the Annex VII technical documentation (point 2(b), with point 8 covering on-request copies to market surveillance)
- The obligation is ongoing: update triggers include every firmware release, component change, and vulnerability discovery
- Full enforcement: 11 December 2027; vulnerability reporting clock starts 11 September 2026
The CRA SBOM Obligations
The CRA references SBOMs in two critical sections:
Annex I: Essential Requirements
The official text of Annex I, Part II, point (1) reads:
"identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products"
This means:
- SBOMs are mandatory, not optional
- They must be in machine-readable format (not PDFs or spreadsheets)
- They must cover at minimum the top-level dependencies of the products; transitive dependency coverage is best practice but goes beyond the legal floor
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.
Annex VII: Technical Documentation
The Annex VII technical file lists the SBOM in two places:
- Point 2(b): the description of vulnerability handling processes "including the software bill of materials" must form part of the technical documentation kept by the manufacturer.
- Point 8: "where applicable, the software bill of materials" must be supplied "further to a reasoned request from a market surveillance authority".
The SBOM is not submitted proactively. It must exist at the time the product is placed on the EU market and be ready for authorities on request.
The SBOM in Annex VII must enable:
- Component-level vulnerability tracking
- Supplier identification
- Licence compliance verification
- End-of-life planning
What Your Annex VII SBOM Must Include
The technical documentation has three required dimensions for the SBOM: format, content, and scope. The table below reflects what market surveillance authorities will check.
| Category | Requirement | Source |
|---|---|---|
| Format | Machine-readable (CycloneDX or SPDX) | Annex I, Part II, point (1) |
| Format | Human-readable summary | Best practice |
| Content | All software components listed | Annex I |
| Content | Component versions specified | Annex I |
| Content | Supplier information | Annex I; TR-03183 |
| Content | Licence information | TR-03183 |
| Content | Known vulnerabilities at assessment time | Annex VII point 2(b) |
| Scope | Direct (top-level) dependencies | Annex I (legal floor) |
| Scope | Transitive dependencies | TR-03183 (best practice) |
| Scope | Operating system components if applicable | TR-03183 |
| Scope | Third-party libraries | Annex I |
For the specific 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 Compliant SBOM Entry Looks Like
A correctly structured Annex VII technical-file entry references the machine-readable file and records the vulnerability status at the time of assessment:
SOFTWARE BILL OF MATERIALS
Product: SmartSense Pro (SSP-3000)
Firmware Version: 2.4.1
SBOM Format: CycloneDX 1.5
Generated: 2027-01-15
Tool: Trivy + syft
SBOM FILE:
sbom-ssp3000-v2.4.1.json (attached)
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-15
Scanner: Trivy v0.48.0
Critical: 0
High: 0
Medium: 2 (accepted - see below)
ACCEPTED VULNERABILITIES:
CVE-2026-XXXXX (Medium): Component xyz v1.2.3
Status: Not exploitable in our configuration
Justification: Feature not enabled, code path not reachable
Review Date: 2027-04-15
-------------------------------------------------------------
SBOM UPDATE COMMITMENT:
SBOM will be updated with each firmware release and made
available to customers upon request.
When to Update Your SBOM
The SBOM is not a one-time document. The technical file must stay current throughout the product lifecycle.
Mandatory update triggers:
| Trigger | What changes | SBOM update required? |
|---|---|---|
| New firmware or software version | New build artefact | Yes, full regeneration |
| Security patch release | Component version bumped | Yes, affected components |
| Vulnerability discovered and addressed | VEX or exploitability status | Yes, VEX fields |
| Component added, removed, or replaced | Dependency graph | Yes, full regeneration |
| Design change affecting security | Components and architecture | Yes, full regeneration |
| Applied harmonised standards change | Standards reference | Yes, metadata |
Periodic reviews:
| Cadence | Scope |
|---|---|
| Quarterly | SBOM and vulnerability status |
| Annually | Full technical file review |
| Before support period end | Final documentation freeze |
Manual SBOM creation is error-prone and does not scale across product versions. Every build should produce a current SBOM artifact. See common SBOM mistakes for what goes wrong when teams skip automation.
Retention Requirements
Article 13(13) requires manufacturers to keep the technical documentation and the EU declaration of conformity at the disposal of market surveillance authorities "for at least 10 years after the product with digital elements has been placed on the market or for the support period, whichever is longer". The clock starts from the last unit placed on the market, not the first.
| Milestone | Example date |
|---|---|
| Product first placed on market | March 2027 |
| Last unit placed on market | December 2030 |
| Documentation retention until (10y minimum) | December 2040 |
Keep the SBOM in secure, accessible storage with backup procedures, integrity protection, and the ability to retrieve and supply it on a reasoned request from a market surveillance authority. Annex VII point 8 specifies the SBOM is provided "further to a reasoned request" rather than proactively.
Enforcement and Penalties
Full CRA enforcement starts 11 December 2027. The vulnerability reporting obligation under Article 14 starts earlier, on 11 September 2026. Products placed on the EU market after December 2027 without a compliant SBOM cannot carry CE marking and cannot legally be sold in the EU. For the full timeline and penalty breakdown, see CRA SBOM deadlines and penalties.
Frequently Asked Questions
Does the CRA require a machine-readable SBOM or is a PDF acceptable?
Annex I explicitly requires machine-readable format. A PDF is not acceptable. CycloneDX or SPDX serialized as JSON or XML satisfies the requirement. A spreadsheet or human-readable document does not.
Does the CRA require an SBOM for open-source components?
Yes. Annex I states manufacturers must document components in a machine-readable SBOM with no exception for open-source. If an open-source library is in your product, it must appear in your SBOM with version and identifier information.
When must an SBOM be submitted: at market placement or on request?
The SBOM does not need to be submitted proactively. It must be part of the technical file (Annex VII), ready and available to market surveillance authorities on request. It must exist at the time 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 broadly aligned with what the CRA and BSI TR-03183 require at the basic level. They are a reasonable starting floor, but TR-03183 mandatory fields go further: hash values and PURL identifiers are expected for CRA compliance.
Can I reuse SBOMs from my suppliers to satisfy the CRA?
Partially. Supplier SBOMs are a valid input for the components they ship, and the CRA expects manufacturers to leverage upstream documentation. But the obligation under Annex I sits on the manufacturer of the integrated product: you must produce and maintain an SBOM for the product as shipped, which means consolidating supplier SBOMs with your own first-party components and build dependencies. If a supplier SBOM is missing fields required by BSI TR-03183 (PURL, hash, license), you are responsible for filling those gaps. Treat supplier SBOMs as raw material, not as a finished compliance artefact.