Can you say what is inside your product?

What the EU's cybersecurity agency found

ENISA's June 2026 survey of small and medium firms on the Cyber Resilience Act (194 responses from 31 countries and regional groupings, 174 of them from firms inside the Regulation's scope) found awareness high and readiness low: 67 respondents, about 35%, keep a software bill of materials. ENISA says the survey was voluntary and should not be read as representative of the sector.[ENISA, SME CRA Survey Report, June 2026, executive summary and s.3; DOI 10.2824/0994553; ISBN 978-92-9204-793-1; catalogue TP-01-26-010-EN-N. Every percentage in the report is taken over all 194 responses, not over the 174 in scope]

Two numbers describe most product companies in 2026. About 66% of the companies surveyed had heard of the Cyber Resilience Act. Only about 35% keep a list of the software inside their own product.

In ENISA's June 2026 survey, incident response and product life-cycle management scored lowest of the five areas measured, at 2.6 out of 5; more than a third of the smallest firms have no incident response plan at all. The widest gaps between what firms do today and what the Regulation expects were in threat modelling and software bills of materials. Company size was the most consistent factor in how mature a firm was.[ENISA, SME CRA Survey Report, June 2026, key findings, s.3 and s.5.4; DOI 10.2824/0994553. The report pairs threat modelling with software bills of materials as the adoption gap, and names incident response and product life-cycle management as the weakest measured domain — it never pairs threat modelling with incident response] In ENISA's June 2026 survey, financial support was the single most-cited need in the support section, named by 142 of the firms that answered that question — level with templates and checklists for the required technical documentation. Taken as a category, practical templates were what firms asked for most.[ENISA, SME CRA Survey Report, June 2026, key findings, s.4.2 and s.7.6; DOI 10.2824/0994553. Financial support and technical-documentation templates are tied at 142 (73.20%); ENISA's own summary calls templates the most requested form of support]

Awareness is not the problem. The problem is that the first concrete thing the law depends on is missing at most companies, and everything else stands on it.

Why that list comes first

Manufacturers must identify and document the vulnerabilities and the components contained in the product, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at least the top-level dependencies.[Annex I, Part II, point 1]

Read it as a dependency rather than as paperwork.

• Reporting needs it. The duty to report a weakness under attack, or a serious incident affecting the product, is the first thing this list serves. Manufacturers' reporting obligations for actively exploited vulnerabilities and severe incidents apply from 11 September 2026.[Art. 71(2); Art. 14] You cannot know that a component you ship is under attack unless you know that you ship it — and a hand-kept list will not tell you the version.
• Fixing things needs it. Matching that list against vulnerability data is how "somebody published a security bug" becomes "it affects release 3.2, in the network code, fixed in 3.2.1".
• Your paperwork needs it. The list is part of what an authority can ask for, per release — and the window in which it can ask outlives the support period. The manufacturer keeps the technical documentation and the EU declaration of conformity available to market surveillance authorities for at least ten years after the product is placed on the market or for the support period, whichever is longer.[Art. 13(13)]
• Your customers will ask for it. Importers, distributors and large buyers are writing supplier questionnaires right now, and "send us your component list" is the first line on most of them.

A company without one cannot report reliably, cannot fix things systematically and cannot assemble its paperwork. That is why this gap is the one to close first.

Why it is usually missing

Three reasons come up in every conversation.

It looks like a document. People hear "bill of materials" and reach for a spreadsheet. A spreadsheet is out of date within a release and nobody updates it. This has to be something your build produces.

Nobody owns it. It falls between engineering, security and quality, and each assumes another has it. Give it to whoever owns the build.

The format looks complicated. The standard formats are verbose. You do not read them; tools do. Producing one is a single step in your build.

An afternoon per technology

For each technology the pattern is the same: run a generator against what you actually ship, produce the standard file, sign it, keep it with the release, and send it to whatever matches it against vulnerability data.

Python. Generate from the resolved environment or the lock file after the build, not from the requirements list, so indirect dependencies and exact versions are captured.

Node. Generate from the lock file and the installed packages of the production build; leave out development-only ones unless you ship them.

Java and .NET. Generate from the build tool's own dependency resolution, at the module that produces the thing you ship.

Docker. Generate from the final image. It captures the operating system packages too, and that is usually where the surprises are.

Whatever you use: generate on every release, sign the file so a reader can tell it has not been altered, keep it with the release, and make the build fail if the generation fails. A release whose list is silently missing is a hole in your evidence that nobody notices until an authority or a customer does.

What to do with it

The law's minimum is the components you depend on directly. Go deeper if your generator can: the extra depth is free and the matching is better. Then two things make the file useful.

1. Match it. Send each list to a tool that checks it against vulnerability databases and against the lists of weaknesses attackers are using, and have a person look at new matches every working day.
2. Keep it. Store each release's list with its checksum next to the release, so you can answer "what was in version 3.2" for as long as an authority can still ask — which is longer than you support the product, so the archive does not get cleared out on the day support ends. The manufacturer keeps the technical documentation and the EU declaration of conformity available to market surveillance authorities for at least ten years after the product is placed on the market or for the support period, whichever is longer.[Art. 13(13)]

Five ways it goes wrong

• Generating from your source files instead of the built product, and shipping something different from what the list says.
• Generating once, by hand, for a questionnaire, and never again.
• Skipping the container image, where most operating-system weaknesses live.
• Producing the list and never matching it against anything.
• Publishing it by accident. You do not have to publish it; you have to have it and produce it on request. Decide on purpose.

The checklist

• Every shipped product has a generator in the build, producing the list on every release.
• It runs against the built product or image, not the source files.
• The list is signed and stored with the release, with its checksum.
• The build fails if the list is not produced.
• Each list is matched against vulnerability data that includes the under-attack lists.
• Somebody looks at new matches every working day and knows who decides what to do.
• The decision on whether to publish the list is written down.
• Old releases' lists are kept for as long as an authority can still ask for them, not only while the product is supported. The manufacturer keeps the technical documentation and the EU declaration of conformity available to market surveillance authorities for at least ten years after the product is placed on the market or for the support period, whichever is longer.[Art. 13(13)]

If you want help

None of this needs us: the generators are free and the pattern above is the whole trick. If you would rather it was done and handed over, the first thing our sprint produces is one change proposed against your own build — a signed component list, a check that stops a bad build, and a published address for security reports — which your engineers review and merge. Getting the matching in step 1 above running is a separate fixed-price job: we choose a tool with you, set it up in an account you own, point the alerts at your own people and hand over the keys. We do not watch it for you afterwards. If you would rather see the gaps before deciding anything, our gap review runs the same tools over your code and maps what it finds to the law's requirements. Either way you end up running it, not us.

Where this sits in the rest of the law: the list of what is inside your product, in our plain-English explainer.

Run the free check