Understanding The EU CRA's SBOM & Technical Documentation Requirements

TL;DR The EU Cyber Resilience Act makes a machine-readable Software Bill of Materials (SBOM) mandatory for every product with digital elements sold in the EU. The SBOM has to cover at least your product's top-level dependencies, stay current, and live inside your technical documentation, ready for authorities on request. The deadline for full compliance is December 11, 2027. Build the SBOM from what actually ships, not just declared dependencies, or it breaks the first time a vulnerability lands.

The EU Cyber Resilience Act makes creating a Software Bill of Materials (SBOM) and technical documentation compulsory for any manufacturer selling connected products into the European Union. This isn't just another regulation. The CRA pushes the whole market toward software supply chain transparency, and it backs that push with legally binding obligations instead of voluntary guidance. The smart manufacturers treat it as a chance to prove accountability and ship more secure products, not a compliance checkbox.

This is part three of our six-part series on the EU Cyber Resilience Act. Here we focus on one question other guides get half-right: what does a CRA-ready SBOM actually have to be?

What does the EU Cyber Resilience Act require for SBOMs?

The EU CRA requires every product with digital elements to include a machine-readable SBOM covering at least its top-level dependencies, kept current and stored in your technical documentation.

This is the core obligation, and the detail matters. The SBOM has to be in a commonly used, machine-readable format. It has to cover, at minimum, the top-level dependencies of the product. You don't have to publish it, but you do have to keep it in your technical documentation and hand it to market surveillance authorities when they ask. And it can't go stale: as your product receives updates and patches, the SBOM has to track the current state of the software.

One nuance worth getting right, because most coverage glosses over it. The legal floor is top-level dependencies. Going deeper, covering transitive and nested components, is stronger practice and what serious vulnerability management depends on. The minimum keeps you legal. The depth keeps you secure.

What is an SBOM, and why does the CRA require one?

A Software Bill of Materials (SBOM) is a machine-readable inventory of every software component in a product, much like an ingredient list that lets you trace hidden vulnerabilities back to their source.

Think of the ingredient list on packaged food. You can't manage an allergy if you don't know what's inside. Software is the same. Most modern products are assembled from open-source and third-party components, and a single flawed library can put an entire device at risk. When a new vulnerability like Log4Shell hits, the manufacturers with an accurate SBOM know in minutes whether they're exposed. The ones without it start guessing. If you're new to the concept, our explainer on what a software bill of materials is covers the fundamentals.

What is EU CRA compliance?

EU CRA compliance means proving a connected product meets the Cyber Resilience Act's security requirements across its full lifecycle, backed by a current SBOM and complete technical documentation for authorities.

CRA compliance isn't a single document or a one-time test. It's an ongoing obligation that runs from design through the product's whole support period. It covers secure-by-design development, vulnerability handling, mandatory incident reporting, and the evidence that proves all of it. The SBOM and technical documentation are the backbone, because they're how you demonstrate, on request, that the product and the processes behind it meet the essential requirements. Miss the deadline or the evidence, and you lose EU market access and risk significant penalties.

What is the EU CRA's guidance on SBOMs and technical documentation?

The CRA's guidance places the SBOM inside vulnerability handling, not paperwork. Keep it internal, include it in your technical documentation, and provide it to authorities on request.

This placement tells you how the regulators think about it. The SBOM requirement lives in the CRA's vulnerability-handling rules, which means it's treated as an operational security tool, not a filing-cabinet formality. The European Commission can still specify the exact format and elements through later implementing acts, so the guidance may tighten. In the meantime, Germany's Federal Office for Information Security has published a technical guideline, BSI TR-03183 [verify before publishing], that gives the first detailed national interpretation of what a CRA-aligned SBOM should contain. The CRA also doesn't sit alone: it complements the NIS2 Directive and builds on earlier EU work like the Cybersecurity Act and ENISA's role, so teams already meeting those rules have a head start.

What are the accepted SBOM guidelines and formats?

CRA SBOMs must use a commonly used, machine-readable format such as SPDX, CycloneDX, or SWID, and cover at least the product's top-level dependencies.

The CRA doesn't name a single format, it sets a bar: commonly used and machine-readable. In practice that points at three established standards, with the US government's NTIA minimum elements as a useful reference for the data fields a usable SBOM should carry. Here's how they compare.

For the data-field baseline that most regulators and customers expect, our breakdown of the NTIA minimum elements for an SBOM is a practical starting point. Whichever format you pick, the SBOM should show how components relate to each other, not just list package names.

What are the software documentation standards under the CRA?

Under Annex VII, the CRA requires a structured technical file covering product description, risk assessment, the SBOM, and vulnerability-handling evidence, retained for at least ten years.

This is where "technical documentation" gets concrete. The CRA doesn't want a vague claim that you follow best practices, it wants traceable, dated artifacts assembled into one evidence file. The legal basis is Article 31, and Annex VII enumerates the contents. Here's what a CRA-ready technical file needs to contain.

Inadequate or missing documentation isn't a minor problem. It can trigger penalties and delay your time-to-market, because conformity assessment runs on this file. Our deeper guide to automated, evidence-backed compliance covers how to keep this file audit-ready without manual scramble.

How can manufacturers comply with CRA SBOM requirements?

Comply by automating SBOM generation from what you actually ship, integrating it into your CI/CD pipeline, enriching it with live vulnerability data, and centralizing documentation for audits.

Manual SBOM work doesn't scale and it drifts out of date the moment a release ships. The manufacturers who stay compliant build it into how they work. Four practices do most of the lifting.

Automate SBOM generation. Use tools that scan software components during development and update the SBOM with every iteration and patch. This removes manual errors and keeps the SBOM consistent across your portfolio.

Manage the SBOM, don't just generate it. Set up a process that reviews and updates the SBOM after product updates and vulnerability disclosures. Wire it into your secure software development lifecycle and your CI/CD pipeline so every release ships with a current SBOM, and so security teams get notified when a new vulnerability hits a listed component.

Coordinate with your suppliers. Request SBOMs or component lists from upstream vendors so third-party and open-source components are accounted for in your own product SBOM. Supply chain transparency only works if it runs in both directions.

Prepare for audits. Keep all SBOMs and technical documents in one centralized, continuously maintained software inventory so internal teams and auditors can find evidence fast. Organization is the difference between passing an inspection and scrambling through it.

What separates a CRA-ready SBOM from a checkbox?

A CRA-ready SBOM is built from what actually ships and kept continuously matched to live vulnerability data. A list of declared dependencies, filed once and forgotten, breaks under audit.

This is the gap most guides miss. An SBOM generated only from your source code or build manifest tells you what you meant to ship. It doesn't always match what's actually in the binary you put on the market, including components pulled in at build time or by third parties. The CRA put the SBOM inside vulnerability handling for a reason: it's supposed to answer "are we exposed?" accurately, in real conditions. If the SBOM doesn't reflect the shipped product, that answer is wrong exactly when it matters. Build it from the binary, keep it enriched with current vulnerability data, and it stays defensible.

How Finite State helps with CRA SBOM and documentation requirements

Generating and maintaining an accurate SBOM that reflects current vulnerability data is the hardest part of CRA compliance. Here's how we help.

Automated SBOM generation and management. Our platform automates SBOM generation and management for connected devices. By combining source code and binary analysis, it builds a complete view of every software component in a product, not just the declared dependencies, and continuously enriches that SBOM with vulnerability data. That gives you an up-to-date picture of risk across open-source and proprietary code, with far less manual effort.

Continuous vulnerability detection and tracking. Keeping vulnerability data current is relentless as new threats surface. We continuously monitor for vulnerabilities and feed them straight into the SBOM, so you don't have to scramble to update documentation with every new CVE. With MergeBase technology now part of the platform [verify before publishing], we strengthen insight into vulnerabilities across both source code and third-party libraries.

Audit-ready reporting. Our compliance reporting tools generate detailed, consolidated reports of software composition and vulnerability data on demand, so you can demonstrate compliance for internal reviews or external audits with minimal burden on your team.

Conclusion

A CRA-ready SBOM isn't a file you generate once and forget. It's a living record of what you actually shipped, matched to real vulnerability data, and stored where authorities can find it. Get that right and technical documentation stops being a deadline you dread and becomes a report you generate.

December 11, 2027 is the compliance deadline, and the manufacturers preparing now will be the ones who pass cleanly. Talk to our team to see what audit-ready CRA evidence looks like in practice.