What the EU Cyber Resilience Act Requires in an SBOM

Annex I Part II point 1 of the Cyber Resilience Act requires manufacturers to identify and document vulnerabilities and components contained in a product 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 product.

Three words in that sentence do most of the work. "Machine-readable" rules out a spreadsheet of library names. "At the very least the top-level dependencies" sets a floor that is lower than most vendors assume, though most tooling produces the full graph anyway. And "drawing up" makes this documentation the manufacturer holds and produces to market surveillance authorities on request, not a file you are obliged to publish to the world. The requirement applies from December 11, 2027 with the other Annex I obligations.

If you already produce an SBOM for a US federal customer or an FDA submission, you are most of the way there. If you do not, the work is a build-pipeline change rather than a documentation exercise, and that distinction determines whether it takes a sprint or a year.

Key takeaways

• Annex I Part II point 1 requires a machine-readable software bill of materials covering at the very least the top-level dependencies, applying from December 11, 2027.
• It is documentation the manufacturer holds and produces to market surveillance authorities on request. Nothing in the requirement obliges you to publish it.
• No format is mandated. "Commonly used and machine-readable" is plainly satisfied by SPDX and by CycloneDX, so pick whichever your ecosystem already speaks.
• It is not a one-time artifact. The vulnerability-handling duties run across the support period, which Article 13(8) sets at a minimum of five years.
• The real deadline is earlier than 2027. Article 14 reporting from September 11, 2026 asks whether a newly exploited vulnerability affects your shipped versions, which is exactly the question a maintained SBOM answers.

What the requirement actually says

The SBOM clause does not stand alone. It is the first of eight vulnerability-handling requirements in Annex I Part II, and it exists to make the other seven possible. Manufacturers must:

1. Identify and document vulnerabilities and components, including by drawing up a machine-readable SBOM covering at least top-level dependencies

2. Address and remediate vulnerabilities without delay, including by providing security updates

3. Apply effective and regular tests and reviews of the security of the product

4. Publicly disclose information about fixed vulnerabilities once a security update is available, with delayed publication permitted in justified cases

5. Put in place and enforce a coordinated vulnerability disclosure policy

6. Take measures to facilitate the reporting of vulnerabilities, including a contact address

7. Provide mechanisms to securely distribute updates

8. Disseminate security updates without delay and free of charge, with advisory messages

Read as a set, the SBOM is the inventory that makes requirements 2 and 4 achievable. You cannot remediate without delay in a component you cannot enumerate, and you cannot tell customers which fixed vulnerabilities affected them without knowing what shipped.

Top-level dependencies is a floor, not a target

The regulation's minimum is the top-level dependencies of the product: what you directly declare and pull in, rather than every transitive package underneath.

That floor exists for a practical reason. Full transitive resolution across a large system is noisy, changes with every build, and can be genuinely hard to determine for binary or vendored components. Setting the legal minimum at the direct dependency layer keeps the requirement enforceable.

In practice most teams generate deeper than the floor, because the tools they would use to satisfy it (build-time generators wired into a package manager) produce the full graph as a side effect, and because the vulnerability-management value is in the transitive layer where the interesting CVEs live. Our own advice is to generate as deep as your build system produces reliably, mark the boundary where reliability ends, and document that boundary. A defensible SBOM that says where its knowledge stops beats an ambitious one that quietly guesses.

What the CRA does not require

Three misconceptions worth clearing, because each one causes real overspending.

It does not require publication. The SBOM is documentation drawn up by the manufacturer and made available to market surveillance authorities on request as part of the technical documentation. Nothing in Annex I Part II point 1 obliges you to publish it to customers or to the public. Many vendors will choose to share SBOMs with enterprise customers, because those customers ask, and that is a commercial decision rather than a regulatory one.

It does not mandate a specific format. The requirement is "a commonly used and machine-readable format". SPDX and CycloneDX are the two formats that plainly satisfy that, and picking one is a tooling decision, not a compliance risk. Pick the one your ecosystem already speaks.

It is not a one-time artifact. The vulnerability-handling requirements run across the support period, which Article 13(8) sets at a minimum of five years unless the product is expected to be in use for less. An SBOM generated by hand for a certification exercise and never regenerated fails the purpose, because the point is to answer "does this shipped version contain the vulnerable component" for a version you released three years ago.

Build it in the pipeline or do not bother

The engineering shape of a compliant SBOM program is short to state and unglamorous to build.

Generate at build time, not at release time, so the artifact describes what was actually compiled rather than what the manifest hoped. Store the SBOM with the build artifact and version them together, because the question you will be asked is always about a specific released version. Keep historical SBOMs for the whole support period, which for many products means five years of retained artifacts and a storage plan. Wire the SBOM into vulnerability scanning so a newly published CVE can be matched against every version you still support, which is the capability that turns the inventory into remediation. And record the generation boundary, meaning what your tooling can and cannot see, so the gap is documented rather than implied.

The teams that struggle are not the ones with complex dependency graphs. They are the ones whose release process cannot answer "which exact artifact went to that customer", because everything downstream depends on that mapping.

The reporting connection, and why the SBOM arrives early

The Annex I requirements apply from December 11, 2027, but Article 14 reporting applies from September 11, 2026, and Article 69(3) extends it to products already on the market.

That sequencing has a practical consequence people miss when they plan the SBOM work for 2027. From September 2026 you are obliged to report actively exploited vulnerabilities in your in-scope products, on a 24-hour early warning followed by a 72-hour notification. Determining whether a newly published exploit affects your shipped versions is precisely the question a maintained SBOM answers, and precisely the question that takes days without one.

So the SBOM is not really a 2027 deliverable. It is the thing that makes your 2026 reporting obligation survivable, and planning it on the later date is a scheduling error.

Where this overlaps with what you may already do

If you sell medical devices into the US, Section 524B has required a machine-readable SBOM in premarket submissions since October 2023, covering commercial, open-source, and off-the-shelf components. That program transfers with light rework, and the FDA cybersecurity practice we run is the same underlying engineering.

If you sell to US federal agencies, the SBOM expectations that flowed from the federal secure software development push have already pushed many vendors to build generation into CI. Same artifact, different consumer.

If you hold ISO 27001 certification, you likely have asset and configuration management controls that name the requirement without producing the artifact. Certification does not give you an SBOM, and assuming it does is a common and expensive misreading.

Where a vendor can reasonably do less

The against-interest section. If your product is a single small application with a handful of direct dependencies, a build-time generator and a retention bucket is genuinely the whole program, and it is a few days of engineering work. You do not need a software supply chain platform, a consultant, or a governance workstream to satisfy Annex I Part II point 1.

Buy tooling and help when the complexity is real: many products, long support periods, embedded or vendored components your package manager cannot see, or a release process that cannot currently map a customer to an artifact. That last one is the honest signal that this is a project rather than a task.

Where Top Floor fits

Our CRA practice treats the SBOM as one deliverable inside the vulnerability-handling program that Annex I Part II describes, alongside the coordinated disclosure policy, the reporting contact, the update distribution mechanism, and the Article 14 reporting runbook whose dates and transitional trap are covered in our CRA scoping guide. We help pick the format, wire generation into the build, define the retention and the generation boundary, and connect the output to scanning so it produces answers rather than files.

Where the product lands in an Annex III important class, that same inventory becomes part of a technical file a notified body reads, which raises the bar on how the generation boundary is documented.

We do not sell an SBOM as a document. A generated-once SBOM is a compliance artifact that does no security work, and a manufacturer holding one still cannot answer the question a market surveillance authority will actually ask.

How to decide this week

Answer three questions honestly.

Can you name every product version currently deployed at a customer, and map each to the exact build artifact that shipped? If not, fix that first, because everything else depends on it.

Does your build produce a machine-readable component inventory today, in any format, without a human step? If yes, you are closer than you think and the work is retention plus scanning integration.

If a critical CVE in a common library were published tomorrow, how many hours would it take to list every supported version of every product that contains it? That number is your real compliance posture, and from September 11, 2026 it has a 24-hour ceiling over it.

Frequently asked questions

Does the EU CRA require an SBOM?

Yes. Annex I Part II point 1 requires manufacturers to identify and document vulnerabilities and components in the product, 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. It applies with the other Annex I essential requirements from December 11, 2027, and it underpins the vulnerability handling and disclosure requirements that sit alongside it.

Do we have to publish our SBOM publicly under the CRA?

No. The SBOM is documentation the manufacturer draws up and holds, and provides to market surveillance authorities on request as part of the technical documentation. Sharing SBOMs with enterprise customers is common and increasingly expected commercially, but it is a customer requirement rather than a CRA one.

Does the CRA specify SPDX or CycloneDX?

No. The requirement is a commonly used and machine-readable format, and both SPDX and CycloneDX plainly meet it. Choose based on what your build tooling and your customers already use rather than on a compliance argument, and keep the choice consistent across products so your vulnerability matching works against one schema.

How deep does a CRA SBOM have to go?

The legal floor is top-level dependencies. Most teams go deeper because their build-time generators produce the full transitive graph anyway and because the vulnerability-management value lives below the top layer. The defensible position is to generate as deep as your tooling reliably resolves and to document where that resolution stops, particularly for vendored, binary, or third-party components the package manager cannot see.