An SBOM under CRA is evidence, not a file you generate once

Under the Cyber Resilience Act the software bill of materials is not a compliance souvenir. Annex I Part II asks the manufacturer to identify and document vulnerabilities, including an SBOM. Article 13 ties that documentation to a lifecycle risk assessment. By 11 December 2027 the SBOM sits in the technical file that market surveillance can demand.

A CycloneDX or SPDX export from last year’s pipeline does not do that job if the product on the Union market has moved two minor versions since.

What CRA actually wants from the SBOM

The regulation does not pick your format. It picks your duty. You place a product with digital elements on the market. You owe due diligence on third-party components. You must be able to say what is inside the version you shipped, and you must keep handling vulnerabilities through the support period you stated at purchase (month and year).

That makes the SBOM a product record, not a repository record. The unit is the PDE version: the firmware in the box, the installer on the store, the library you sell as a component. A monorepo dump that mixes three SKUs is not evidence. A cloud lockbox that the operations team cannot open on a Friday night is not evidence either.

The SBOM also has to be usable when Article 14 starts on 11 September 2026. An actively exploited vulnerability in a transitive dependency is a 24-hour problem only if you can name the products that contain it.

Match the shipped version, or the file is already wrong

The usual failure is drift. The store shows 3.4.1. The SBOM in the share drive was generated from main in March. Two sprints added a TLS library and removed a vendor SDK. The scan still runs. The evidence does not.

Lock the SBOM to the build that left the warehouse:

• the same version string as the catalogue,
• the same commit / image digest you signed,
• own components and third-party components, with supplier and version,
• a date, so you can see when the file stopped matching the product.

Due diligence stays on the component. If a supplier ships a fix, your row has to show that you saw it, that you assessed it against this PDE, and that you either took the update or accepted a documented risk against Annex I. A green badge in a SaaS scanner is not that row.

The SBOM feeds the queue, the queue is not the SBOM

CRA is not a vulnerability scanner. The SBOM tells the queue which components exist. The scanner tells the queue which of those components have known weaknesses. Article 14 then asks a third question: is this actively exploited, or is this a severe incident, and can you warn the CSIRT and ENISA in 24 hours.

If those three objects live in three tools with three product names, the 24-hour clock is already lost. The minimum join is boring and non-negotiable:

1. PDE identity in the catalogue.
2. SBOM lines keyed to that identity.
3. Findings keyed to those lines.
4. A named owner and a 24h / 72h state.

Without the join you get either silence (nobody knows the product is affected) or noise (every CVE in the industry lands on one mailing list).

What belongs in the technical file

By 11 December 2027 the file is not “attach latest SBOM.pdf”. It is the product identity, the risk assessment, Annex I evidence, the SBOM of the placed version, the support period, instructions, the EU declaration and the CE mark.

That has consequences for how you store it:

• the authority asks for this product, not your company’s software estate,
• you may need the SBOM years after the release train has moved on,
• exporting it must not mean copying the catalogue onto a vendor cloud.

Crado AI keeps the SBOM on-premise, next to the catalogue and the Article 14 queue, for that reason. The bill of materials is part of the file you can show before the product leaves the warehouse.

A working SBOM practice before September 2026

1. Generate the SBOM from the pipeline for every version you still support, not only the next release.
2. Refuse to ship if the catalogue version and the SBOM version disagree.
3. Keep supplier and version on every third-party line, so due diligence has a handle.
4. Link findings to those lines. Close or accept them against Annex I, not against a ticket count.
5. Rehearse one Article 14 drill: pick a component, list the PDEs, name the owner, time the early warning.

If you cannot do step 5 on a weekday afternoon, the SBOM is still a file. It is not yet evidence.