CRA for machine builders: your first SBOM without a dev team

If you build machines, “draw up a Software Bill of Materials” can sound like it belongs to a software company with a DevOps team and a CI pipeline. It doesn’t. The Cyber Resilience Act requires an SBOM covering at least your product’s top-level dependencies, and for a machine that is mostly an inventory exercise you can do with a spreadsheet and a few emails to suppliers. This guide is the hands-on companion to our machine-builder overview — that one explains how the CRA stacks on CE marking and the Machinery Regulation; this one walks you through actually building the first SBOM.

If you want the concept-level background first — what an SBOM is and why regulators want a parts list for software — read what is an SBOM. Here we assume you just want to get one done.

Not sure the CRA applies to your machine? Run the free 3-minute scope check first.

What software is actually in a machine?

The first surprise for most machine builders is how much software ships inside a “mechanical” product. Before you can list components, you need to know where they hide. A typical line looks like this:

The pattern that matters: some of this software you wrote (your PLC program, your HMI screens, your PC application), and a lot of it you did not (firmware, runtimes, the OS, purchased modules). Both belong in the SBOM. You are the manufacturer of the finished machine, so its SBOM is yours — but for the parts you bought, you lean on your suppliers rather than reverse-engineering them.

Step 1: Inventory the machine

Walk the machine, physically or through its bill of materials, and write down every component that contains software or firmware. Do not try to name versions yet — just list the boxes: each drive, each smart sensor, the PLC, the HMI, the industrial PC, the managed switch, the remote-access gateway, and every purchased module. Work from your electrical schematic and your mechanical BOM; anything with a processor in it has software.

Keep this at the machine-family level, not per serial number. Every unit of the same family with the same firmware baseline shares one SBOM.

Step 2: Get names and versions

An SBOM entry without a version is close to useless — you cannot match a component to a published vulnerability if you only know it is “the Siemens one.” So for each item in your inventory, capture:

• Component name — the product/model as the vendor names it
• Version — firmware or software version actually installed on the machine you ship
• Supplier — who you buy it from
• Where it runs — PLC, HMI, industrial PC, network, and so on

Versions come from the devices themselves (the firmware screen on the drive, the PLC diagnostics, the OS “About” dialog) or from your purchasing records. This is the slowest step; budget a day per machine family the first time. It gets easier once you have a template.

Step 3: Ask suppliers for their SBOM

For purchased modules and subassemblies — a robot cell, a vision system, a pre-built safety controller — you should not try to list the internal software yourself. The supplier is also in CRA scope for what they place on the market, so ask them for their SBOM and their security contact. A short email works:

“For our EU Cyber Resilience Act technical file, please send the SBOM (CycloneDX or SPDX) for the [module] at firmware version [X], and the security contact for vulnerability advisories.”

Their SBOM becomes a referenced sub-component of yours, and their advisories feed your monitoring. Start asking now — suppliers who cannot answer are telling you something about your supply-chain risk. We cover this vendor-component split in more depth in the machine-builder overview.

Step 4: Pick a format — use CycloneDX

Two formats are accepted under the CRA: CycloneDX and SPDX. For a machine builder starting out, pick CycloneDX JSON unless a customer specifically requires SPDX — it is the more common choice for CRA purposes and every serious tool can convert between the two. You do not need to hand-write JSON either: maintain your inventory as a spreadsheet with one row per component, then export or convert it to CycloneDX once. The format is a container for the same facts you already collected — name, version, supplier, and a package identifier where one exists.

Step 5: Assemble the top-level list

The CRA asks for at least the top-level dependencies — not a forensic, bit-level teardown of every machine. For a machine builder that means: the components you consciously include and the major software running on them. Combine three inputs into one file:

1. Software you wrote — your PLC program, HMI project, and industrial-PC application, each with a version.
2. Software you run but didn’t write — PLC/HMI runtimes, the OS, .NET/Java runtimes, drivers, remote-access agents, with their versions.
3. Supplier SBOMs — referenced for each purchased module.

That combined list is your first SBOM. It is allowed to be imperfect: a top-level component list today beats a complete dependency graph in six months. You do not need to install Syft, cdxgen, or any developer tooling to produce a valid first version — a maintained component list, exported to CycloneDX, satisfies the requirement. Add depth later.

Step 6: Keep it per machine family and per firmware release

An SBOM describes one software state. The moment you change a firmware version, update the OS, or swap a module, the SBOM is out of date. So version it the way you version the machine:

• One SBOM per machine family, shared across every identical unit.
• A new revision on every firmware/software release — treat it like a drawing revision, with a date and a version.
• Stored with your technical file, referenced from your CRA documentation.

This is also what makes the 24-hour vulnerability reporting duty (live from 11 September 2026) survivable: when a CVE lands in a component, you check the SBOM instead of opening up machines in the field. Which risk class your machine falls into — most land in the default self-assessment class — shapes how much scrutiny the file gets; see CRA product classes if you are unsure.

A realistic first pass

You can build a defensible first SBOM for one machine family in a couple of days: a day to inventory and pull versions, a few emails to suppliers, and an afternoon to assemble the CycloneDX file. The work compounds — the same SBOM serves every unit of the family, and each release is an edit, not a restart. If you would rather not maintain the spreadsheet-and-export dance by hand, CRA compliance software builds the CycloneDX SBOM from a simple component list, references your suppliers’ files, and keeps one current per machine family and firmware release.

Before you build the list, confirm the CRA applies and which class you are in: check your machine’s scope and class free — three minutes, no signup.