SBOMs are becoming the SME supplier file

The software bill of materials is moving from security vocabulary into the supplier file that an SME will be asked to show.

ENISA published its SBOM Adoption State of Play report on 9 June 2026, after a survey launched at the end of 2025. The report says the Cyber Resilience Act is acting as an accelerator for SBOM adoption, which means the question is no longer whether component inventories are fashionable. It is whether a smaller supplier can explain what is inside the product it sells.

The inventory is becoming external

For years, many SMEs treated dependency lists as internal engineering housekeeping. The CRA changes the audience. A product with digital elements does not only need patches; it needs traceable information about components, versions, support periods and vulnerability handling.

ENISA’s SBOM report received 334 responses from organisations in the EU and beyond. It found that 78% of respondents had already started an SBOM adoption journey, while 44% were still in pilot or limited adoption and 9% reported broad adoption across products. That is a useful warning for smaller firms: the market is moving, but it is not yet settled.

The practical gap is visible in ENISA’s own barrier list. Respondents named SBOM completeness, SBOM data quality and integration into operational risk management as obstacles. Those are not legal-theory problems. They are spreadsheet, build pipeline and ownership problems.

A supplier file beats a dashboard

An SME does not need to begin with a full platform. The first useful version is a supplier file that a product owner, a developer and a procurement lead can all read.

File item	Minimum evidence
Product	Name, version, support period and responsible owner
Components	Top-level dependencies, supplier or maintainer, licence and source
Updates	Last security update, patch channel and customer notification route
Vulnerabilities	How alerts are received, triaged and linked to affected versions
Exports	SBOM format used and where the latest file is stored

Source: ENISA SBOM Adoption State of Play and Regulation (EU) 2024/2847. Last verified 2026-07-05.

That file can later feed CycloneDX, SPDX or whatever tooling the company adopts. Starting with the file also exposes the real problem quickly: nobody owns one product line, a supplier name is missing, or an old component has no support-period record.

Procurement will ask earlier than regulators

The formal CRA application date for most obligations is December 2027, but waiting for that date is the wrong operational clock. The Commission says CRA reporting obligations start on 11 September 2026 and will run through the Single Reporting Platform. ENISA’s SRP FAQ already lists fields that connect reports to the manufacturer, product, vulnerability or incident, mitigation and user action.

That reporting context makes SBOM readiness visible to customers. A larger buyer does not need to audit every line of code to ask one simple question: if a component is actively exploited, can the supplier identify affected products and versions quickly enough?

If the answer depends on one developer remembering the dependency tree, the supplier is fragile. If the answer points to a maintained product file, the buyer has something to assess.

The SME test is boring on purpose

The July job is not to buy an SBOM product because ENISA published a report. It is to pick one sold product and run a dull test.

List the product, its current version, its top-level dependencies, the source for each dependency, the owner who can update it, the support period promised to customers and the place where vulnerability notices arrive. Then choose one dependency and ask what would happen if an exploited vulnerability appeared tomorrow.

If the company cannot find the affected versions, the missing artefact is not a compliance policy. It is an inventory. Build that first, because every later CRA workflow assumes it already exists.