SBOM requirements under the EU Cyber Resilience Act turn a good engineering habit into a legal duty. Regulation (EU) 2024/2847 obliges every manufacturer of software or connected products sold in the EU to identify and document the components inside them, including a software bill of materials in a machine-readable format. From 11 December 2027 that duty is enforceable with fines of up to €15 million, and the vulnerability-handling regime it supports starts biting from 11 September 2026.
This article is the SBOM deep-dive in our Cyber Resilience Act series. Our Cyber Resilience Act compliance guide for UK software companies covers the whole regime, our guide to Cyber Resilience Act reporting requirements covers the 24-hour and 72-hour clocks, and our Cyber Resilience Act checklist for software developers walks the six workstreams in delivery order.
Here we go one level deeper on a single duty. What the SBOM requirements actually say, the minimum elements a compliant bill of materials should carry, how to choose between SPDX and CycloneDX, how to generate and maintain SBOMs in your pipeline, and what happens when a market surveillance authority asks to see one. If you only have capacity for one piece of CRA engineering this quarter, the SBOM requirements are the right place to spend it, because almost every other duty leans on them.
Table of contents
- What the Cyber Resilience Act Actually Requires in an SBOM
- Who Must Meet SBOM Requirements, and for Which Products
- SBOM Requirements Deadlines and the CRA Timeline
- The Minimum Elements Every SBOM Entry Needs
- SPDX vs CycloneDX: Choosing a Machine-Readable Format
- Building SBOM Requirements into Your Delivery Pipeline
- Keeping SBOMs Current: Depth, Versions and Updates
- SBOM Requirements and Vulnerability Handling
- Market Surveillance, Fines and Producing Your SBOM on Request
- Common SBOM Requirements Mistakes to Avoid
- A 90-Day Plan to Meet SBOM Requirements
- SBOM Requirements FAQ
- References
What the Cyber Resilience Act Actually Requires in an SBOM
The exact legal wording, unpacked
The SBOM duty lives in Annex I, Part II of the regulation, which lists the vulnerability handling requirements. Point (1) obliges manufacturers to identify and document vulnerabilities and components contained in their products, 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 product. Every phrase in that sentence carries weight, and the rest of this guide unpacks them one at a time.
Machine-readable or it does not count
A dependency list in a wiki page or a licence appendix in a PDF does not satisfy the SBOM requirements. “Commonly used and machine-readable” points directly at the two established formats, SPDX and CycloneDX, and the European Commission has the power to specify the format and elements of the software bill of materials in implementing acts. Choosing one of the two mainstream formats now is the safest way to land wherever that specification ends up.
What the duty is actually for
The SBOM is not paperwork for its own sake. Annex I, Part II uses it as the foundation for everything else: you cannot address vulnerabilities without delay if you do not know which components you ship, and you cannot report an actively exploited vulnerability in a dependency you have never inventoried. Regulators treat the SBOM as evidence that your vulnerability handling process rests on facts rather than folklore.
A duty you hold, not one you publish
The regulation does not force you to publish your SBOM. You must draw it up, keep it accurate, include it in the technical documentation, and produce it when a market surveillance authority asks. If you choose to make it available to users, the product information must say where to find it. That distinction matters commercially: meeting the SBOM requirements does not mean handing your dependency graph to competitors.
Who Must Meet SBOM Requirements, and for Which Products
Manufacturers carry the duty
The SBOM requirements bind the “manufacturer”: anyone who develops or has developed a product with digital elements and places it on the EU market under their own name or trademark, paid or free. That includes desktop and mobile applications, firmware, commercial SDKs and libraries, IoT devices and the remote processing a product needs to function. Pure SaaS with no product component generally falls under NIS2 instead, but a downloadable client or an installed agent pulls you back into scope.
UK and non-EU vendors are in scope
The test is market access, not company registration. A UK or US software company shipping into Germany, France or Ireland owes exactly the same SBOM requirements as a vendor in Berlin. Brexit changes nothing about this: if the product is placed on the EU market, the duty follows it, and distributors and importers are obliged to check that it has been met before they resell.
Open source: carve-outs with sharp edges
Open-source software developed or supplied outside a commercial activity sits outside the regulation, and non-profit open-source stewards get a lighter regime. The edges cut fast, though. Monetise support, run a paid tier, or ship a community edition under your trademark and you become a manufacturer with full SBOM requirements. The pragmatic reading: inventory everything that carries your name, then argue about scope with the list in hand.
SBOM Requirements Deadlines and the CRA Timeline
Three dates, three different projects
The regulation entered into force on 10 December 2024 and applies in stages. Notified body provisions applied from 11 June 2026. The Article 14 reporting duties apply from 11 September 2026. The full regime, including the Annex I essential requirements that contain the SBOM duty, applies to products placed on the market from 11 December 2027. Treat these as three projects with three deadlines, not one distant compliance event.
| Date | What applies | What it means for your SBOM |
|---|---|---|
| 11 June 2026 | Notified body provisions | Assessment capacity starts building; no direct SBOM duty yet |
| 11 September 2026 | Article 14 reporting duties | You need component visibility to know a dependency vulnerability affects you |
| 11 December 2027 | Full regime, Annex I applies | Machine-readable SBOM becomes an enforceable requirement |
The runway, measured honestly
Counted from entry into force in December 2024, the milestones landed at eighteen, twenty-one and thirty-six months. Most of that runway has already gone.
Why the SBOM cannot wait for 2027
The reporting duties arrive fifteen months before the conformity duties, and they are the reason SBOM requirements belong in this year’s plan rather than next year’s. From September 2026, an actively exploited vulnerability in a component you ship starts a 24-hour legal clock. Teams without an accurate bill of materials spend that first day discovering whether they are affected; teams with one spend it drafting the notification. The SBOM is the difference between the two.
The Minimum Elements Every SBOM Entry Needs
The seven-field baseline
The CRA text sets the floor at documented components down to at least top-level dependencies, and the widely used baseline for what each entry should contain comes from the US NTIA’s 2021 minimum elements report. Seven data fields per component have become the de facto international norm, and both mainstream formats express all of them natively. Building to that baseline now keeps you aligned with whatever the Commission later specifies.
| Data field | What it records | Why it matters |
|---|---|---|
| Supplier name | Who produced the component | Ties advisories to the right upstream source |
| Component name | The component’s own identifier | The primary lookup key for vulnerability matching |
| Component version | The exact shipped version | Determines whether a CVE actually applies |
| Other unique identifiers | purl, CPE or similar | Removes naming ambiguity across ecosystems |
| Dependency relationship | What includes what | Shows whether a flaw is reachable in your product |
| Author of SBOM data | Who generated the record | Provenance for auditors and authorities |
| Timestamp | When it was generated | Proves the SBOM matches the release it describes |
Where the CRA sets its own floor
Two points in the SBOM requirements go beyond a generic component list. The format must be machine-readable and commonly used, which rules out home-grown CSV conventions. And the bill of materials must cover the top-level dependencies at the very least, which makes direct dependencies a hard floor rather than a nice-to-have. Nothing stops an authority expecting more depth where the risk justifies it, and the technical documentation must describe the approach you took.
Fields that save you later
Beyond the baseline, two additions earn their keep. Package URLs (purl) give every component an unambiguous identity that vulnerability databases understand, which cuts false positives dramatically. And a licence field per component means the same artefact satisfies your open-source licence compliance work, so the SBOM requirements and your legal review stop being two separate spreadsheets maintained by two separate people.
SPDX vs CycloneDX: Choosing a Machine-Readable Format
Two standards, one duty
Both mainstream formats satisfy the SBOM requirements as written today. SPDX grew out of licence compliance in the Linux Foundation and is published as ISO/IEC 5962. CycloneDX grew out of application security in the OWASP community and is standardised as ECMA-424. Both are machine-readable, both are commonly used, and both carry the seven baseline fields. The choice is about your toolchain, not about compliance.
| Factor | SPDX | CycloneDX |
|---|---|---|
| Steward | Linux Foundation | OWASP Foundation |
| Standardisation | ISO/IEC 5962 | ECMA-424 |
| Original strength | Licence and provenance detail | Security use cases, VEX, services |
| Serialisations | JSON, YAML, RDF, tag-value | JSON, XML, protobuf |
| Typical fit | Organisations with heavy licence obligations | Product security and vulnerability workflows |
How to choose in practice
If the SBOM’s first consumer is your vulnerability management workflow, CycloneDX usually fits with less friction, because VEX and analysis workflows were designed into it. If your organisation already runs SPDX for licence compliance, staying with it and generating CycloneDX on demand is entirely workable, since mature tools convert between the two. What matters for the SBOM requirements is picking one primary format, documenting the decision, and applying it to every product consistently.
Building SBOM Requirements into Your Delivery Pipeline
Generate at build time, not audit time
The only SBOM that stays accurate is the one your build produces. Generating the bill of materials as a step in continuous integration, from the resolved dependency graph of the artefact you actually ship, means the record can never drift from reality. This is where SBOM requirements stop being a compliance chore and start behaving like the DevOps practices you already run: automated, versioned and boringly repeatable.
Tooling that does the work
You rarely need to write anything. Syft, Trivy and cdxgen generate CycloneDX or SPDX output from source trees, container images and lockfiles; most package ecosystems have native plugins; GitHub and GitLab can export dependency graphs in SPDX form. Downstream, OWASP Dependency-Track ingests CycloneDX SBOMs and continuously matches them against vulnerability feeds, which converts the static document into the living lookup table the regulation assumes you have.
Store SBOMs like build artefacts
Attach the SBOM to the release it describes: same repository of record, same retention, same immutability as the binary. The technical documentation for a product must hold the SBOM for each version placed on the market, and the support period, five years in most cases, defines how long you may need to produce it. A bill of materials you cannot retrieve for a three-year-old firmware image is a failure of the SBOM requirements even if it once existed.
Keeping SBOMs Current: Depth, Versions and Updates
Top-level is the floor, not the target
The regulation’s minimum is top-level dependencies, but the vulnerabilities that hurt are usually transitive: the logging library inside your framework, the parser inside your SDK. Generating to full depth costs nothing extra with modern tooling, and it is the depth at which vulnerability matching becomes genuinely useful. Meet the SBOM requirements at the legal floor if you must, but understand that the floor exists to accommodate constrained embedded systems, not to describe good practice.
One SBOM per product, per version
An SBOM describes one version of one product. Ship version 4.2 and the 4.1 document does not cover it. In practice this means SBOM generation belongs in the release process itself, and the archive of past SBOMs maps one-to-one onto the versions still inside their support period. Rolling all products into a single organisation-wide bill of materials fails the SBOM requirements because no authority can tell which components a specific product actually contains.
Patches change the SBOM too
Security updates modify the dependency graph, so each update regenerates the document. This is also where the duty pays for itself: the regulation obliges you to address vulnerabilities without delay and to deliver security updates, and the SBOM archive is how you demonstrate which releases carried the vulnerable component and which patched it. Auditors read the sequence of SBOMs as the objective history of your remediation work.
SBOM Requirements and Vulnerability Handling
The SBOM is the lookup table
Annex I, Part II places the SBOM first for a reason: every other vulnerability handling duty consumes it. When a critical CVE lands in a popular library, the affected-or-not question becomes a query across your SBOMs rather than a week of archaeology through build scripts. Teams that meet SBOM requirements well answer in minutes, and the same query tells them which products, which versions and which customers are involved.
VEX: saying which findings matter
An honest SBOM will match hundreds of published CVEs, most of them unreachable in your product. The Vulnerability Exploitability eXchange (VEX) is the companion document that records your assessment: affected, not affected, fixed, or under investigation, with justification. Pairing SBOM requirements with a VEX workflow, in CycloneDX’s native VEX profile or the OpenVEX specification, is what keeps your support inbox from filling with questions about vulnerabilities that cannot touch you.
Disclosure duties lean on the same data
The regulation also requires a coordinated vulnerability disclosure policy, a contact address for reports, and secure distribution of updates. Each of those duties starts with knowing exactly what you ship. A researcher’s report names a component; your SBOM says where it lives; your VEX records the verdict; your update mechanism carries the fix. That chain, documented end to end, is what a mature Annex I, Part II implementation looks like to an assessor.
Market Surveillance, Fines and Producing Your SBOM on Request
Who can ask, and for what
Market surveillance authorities in each member state police the regulation, and they can require a manufacturer to provide the technical documentation, the SBOM included, in a language they can understand. Requests will not arrive on your release schedule. The test you should rehearse is simple: for any supported version of any product, can the team produce the matching bill of materials within a working day, without a special project to reconstruct it?
The fine bands are real money
Non-compliance with the essential requirements in Annex I, or with the Article 13 and 14 obligations, carries administrative fines of up to €15 million or 2.5% of worldwide annual turnover, whichever is higher. Breaches of other obligations carry up to €10 million or 2%, and supplying misleading information to authorities carries up to €5 million or 1%. An absent or fictional SBOM sits squarely in the top band, because the duty is part of Annex I itself. Enforcement is a cybersecurity matter and a market-access one at once: authorities can also force a product off the EU market entirely.
The cheapest defence is a boring one
Nothing in the fine bands requires heroics to avoid. A build-time SBOM step, an artefact store with retention, and a rehearsed retrieval path cover the documentary side of the SBOM requirements for a fraction of what one enforcement engagement would cost in legal fees alone. The manufacturers who struggle will be the ones reconstructing five years of dependency history from memory in a regulator’s timeframe.
Common SBOM Requirements Mistakes to Avoid
Treating the SBOM as a one-off deliverable
The single most common failure: generating a beautiful bill of materials for the audit, then never regenerating it. Six releases later it describes a product that no longer exists. The SBOM requirements are continuous because the product changes continuously; any process that depends on someone remembering to update a document has already failed.
Documenting the wrong artefact
An SBOM generated from a source tree can silently omit what the build injects: base images, bundled runtimes, statically linked libraries. Generate from the shippable artefact, the container image or installer, so the record matches what customers actually run. The gap between source-level and artefact-level SBOMs is exactly where the embarrassing misses live.
Ignoring what suppliers hand you
Your product includes components whose SBOM requirements someone else met, or failed to meet. Collect SBOMs from commercial suppliers as a procurement condition, fold them into your own, and flag the vendors who cannot produce one, because their gap becomes your gap on the day an authority asks. The NCSC’s supply chain guidance makes the same point from the defender’s side.
Forgetting the licence dimension
The same component inventory drives open-source licence compliance, and frameworks such as OpenChain already describe how to run that discipline. Meeting SBOM requirements with a tool that also captures licence data solves two obligations with one artefact. Running them as separate programmes doubles the cost and guarantees the two inventories disagree.
A 90-Day Plan to Meet SBOM Requirements
Days 1 to 30: inventory and decide
List every product placed on the EU market under your name, with its versions inside their support period. Pick your primary format, SPDX or CycloneDX, and record why. Run a first generation against your flagship product and see how bad the naming, versioning and identifier quality is. This month is about discovering the real size of the work while the calendar is still on your side.
Days 31 to 60: wire the pipeline
Add SBOM generation to continuous integration for every product, generating from the shippable artefact at release time. Store the output alongside the binary with the same retention. Stand up ingestion, Dependency-Track or equivalent, so each SBOM is continuously matched against vulnerability feeds, and route the resulting alerts into the same queue that feeds your Article 14 reporting decisions.
Days 61 to 90: prove it works
Rehearse the two moments that matter. First, a retrieval drill: pick an old supported version at random and produce its SBOM within a day. Second, an impact drill: take a real historical CVE, run it across the SBOM archive and time how long the affected-version list takes. Fix what the drills expose, then write the process into the technical documentation. At that point the SBOM requirements are met in the only sense that counts: routinely, with evidence.
SBOM Requirements FAQ
Do we have to publish our SBOM?
No. The duty is to draw it up, keep it current, hold it in the technical documentation and provide it to market surveillance authorities on request. Publication to users is a choice, and if you make it, the product information must say where the SBOM can be accessed. Many vendors share SBOMs with enterprise customers under NDA as a middle path.
Is a spreadsheet or PDF acceptable?
No. The SBOM requirements specify a commonly used, machine-readable format, which in practice means SPDX or CycloneDX. A spreadsheet can be a useful internal view generated from the real SBOM, but it cannot be the system of record, and it is not what you should hand an authority.
Do SaaS products need one?
Pure SaaS with no product component generally sits under NIS2 rather than the CRA, so the strict duty usually does not apply. The boundary runs through your architecture, though: a downloadable agent, a mobile client or an on-premise gateway is a product with digital elements, and its SBOM requirements are the same as for any other product. Many SaaS vendors produce SBOMs anyway because enterprise procurement increasingly demands them.
What about components we did not write?
They are still your problem. The bill of materials covers what the product contains, not what your team authored: open-source libraries, commercial SDKs, bundled runtimes and base images all belong in it. Where a supplier provides their own SBOM, fold it in; where they cannot, document the component yourself and weigh the vendor’s opacity as the supply chain risk it is.
References
Cyber Resilience Act | European Commission
NIS2 Directive | European Commission
SPDX: System Package Data Exchange
ECMA-424: CycloneDX Bill of Materials Standard
NCSC: Supply Chain Security Guidance
NIST SP 800-218: Secure Software Development Framework
NIST SP 800-161: Cybersecurity Supply Chain Risk Management Practices
