# SBOM for small vendors: what the CRA actually requires (and what it doesn't) Canonical: https://craguard.eu/blog/sbom-for-small-vendors-what-the-cra-requires Language: en Last updated: 2026-09-02 - [CRAguard](https://craguard.eu/)/ - [Blog](https://craguard.eu/blog)/ - SBOM for small vendors: what the CRA actually requires (and what it doesn't) 3 Sep 2026 · CRAguard Summary An SBOM is a machine-readable list of your product's software components. The CRA requires it in Annex I as part of the vulnerability-handling process — top-level dependencies are enough, in a common format (CycloneDX or SPDX). It is not published: it is part of the technical documentation and is provided on request to a market surveillance authority. You generate it from your build with a single command using Syft or Trivy. When people say "comply with the Cyber Resilience Act", most small software companies picture mountains of paperwork. In fact one of the first and most useful things is very concrete and takes minutes to produce: an **SBOM** — a Software Bill of Materials, that is, a list of the software components your product is made of. This article explains what Regulation (EU) 2024/2847 actually wants from it, what is merely a myth, and how to build one without a consultant. If you don't yet have the full picture of what awaits you from 11 September 2026, start with the [first article on reporting](https://craguard.eu/blog/cra-reporting-11-september-2026) — an SBOM is one of the five things we recommend doing right away. ## What an SBOM is and why the CRA wants it An SBOM is simply a **list of components** — libraries, packages and dependencies — that are in your product, together with their versions. Think of the ingredients list on food packaging, but for software. The CRA requires it in **Annex I, Part II, point 1** as part of the vulnerability-handling process: the manufacturer must "identify and document the components of the product", including drawing up an SBOM. The regulation talks about **at least the top-level (direct) dependencies** and a "commonly used, machine-readable format". It does not prescribe a specific standard — in practice this means **CycloneDX or SPDX**, the two established machine-readable formats. The Commission may later specify the format and mandatory fields through an implementing act, but no such act has been issued yet — so today either of those two formats is enough. ## What the law actually requires (and what it doesn't) It's worth being precise here, because a lot of misunderstanding surrounds SBOMs. **An SBOM is not published.** It is not a public document or something you put on your website. It is part of your **technical documentation** and you provide it **on request to a market surveillance authority**. That is the full extent of the outward legal obligation. **Commercial pressure** is a separate matter: large buyers and public procurers increasingly ask for an SBOM contractually, as a condition of supply. But that is not a CRA requirement — it is your customer's requirement. If they ask, you satisfy it with the same file you need for the documentation anyway. And third: you do **not send the SBOM to ENISA** or file it anywhere "for storage". ENISA's platform is only for reporting actively exploited vulnerabilities and severe incidents — not component lists. Scope-checker ### Find out whether the CRA applies to you Six questions, two minutes, no account. Get your product class and first steps. [Start the scope-checker](https://craguard.eu/checker) ## What an SBOM is actually for Even if the law didn't want one, an SBOM is the thing that saves you the most stress at the worst moment. From 11 September 2026 you must report an actively exploited vulnerability **within 24 hours** (Article 14). When a new vulnerability appears — a new CVE — you must be able to answer one question fast: *does it affect us?* Without a list of components you have no way to answer other than digging through the code by hand under time pressure. With an **SBOM** the comparison can be automated: your list of components and versions against vulnerability databases — **OSV.dev, NVD, CISA KEV** — and you have the answer in moments instead of hours. That is exactly the link between the SBOM and the reporting duty in Article 14. ## How to build one in minutes The good news: you don't write an SBOM by hand. You generate it **from your build or lock file** with ready-made tools. The two most common are open-source tools under the Apache-2.0 licence: **Syft** and **Trivy**. Both can scan your project or build and produce an SBOM with **a single command**, exporting to **both CycloneDX and SPDX**. You don't have to choose between formats — generate both. A few practical habits worth adopting straight away: - **Version the SBOM with every release.** Each product version has its own component list — otherwise you can't tell which shipped version is vulnerable. - **Keep it with the documentation.** Under the CRA, technical documentation is retained for 10 years from placing the product on the market (or for the support period, if longer) — the SBOM belongs with it. - **Don't forget versions and transitive dependencies.** The minimum is top-level, but having at least an overview of what your direct dependencies pull in will pay off during the first incident. ## Three common myths - **"We're SaaS, we don't need an SBOM."** Pure cloud SaaS is mostly out of scope of the CRA. But if you ship a client app, an agent or a device alongside the service, that piece is a product — and the SBOM applies to it. If you are not sure, [our scope-checker](https://craguard.eu/checker) tells you in two minutes. - **"Our package.json is enough."** A manifest is a good start, but it is not an SBOM. It lacks the exact resolved versions and does not account for transitive dependencies. The minimum is top-level components with versions — and those you can't reliably read from a bare manifest. - **"I have to send the SBOM to ENISA."** No. ENISA's platform is for reporting vulnerabilities and incidents, not SBOMs. It stays with you in the documentation. ## How CRAguard helps This is exactly the part we want to take off small companies' hands. CRAguard generates an SBOM from your lock file (both CycloneDX and SPDX), keeps it versioned with every release, and compares it **daily** against OSV, KEV and EPSS — so when a new vulnerability appears, the answer to "does it affect us?" is ready before the 24-hour clock even starts. The dates are clear: **11 September 2026** reporting and **11 December 2027** full conformity and CE marking. [Find out whether the CRA applies to you](https://craguard.eu/checker), or [join the waitlist](https://craguard.eu/#waitlist) — we'll let you know at launch. *This article is informational and not legal advice. It is based on Regulation (EU) 2024/2847 (Annex I Part II, Art. 13, Art. 14), the European Commission's guidance of 27 July 2026 and ENISA's FAQ on the Single Reporting Platform.* Scope-checker ### Find out whether the CRA applies to you Six questions, two minutes, no account. Get your product class and first steps. [Start the scope-checker](https://craguard.eu/checker) ## Sources - [EUR-Lex — Regulation (EU) 2024/2847 (Cyber Resilience Act)](https://eur-lex.europa.eu/eli/reg/2024/2847/oj) - [ENISA — Single Reporting Platform](https://www.enisa.europa.eu/) --- Source: CRAguard — https://craguard.eu