SBOM scanners only detect known components, while firmware in purchased parts often remains invisible. The CRA, however, requires a complete documented list of components.
What the CRA actually requires
Annex I, Part II of the CRA requires manufacturers to provide documentation of software components, including an SBOM. This requirement is part of the technical documentation that accompanies a product throughout its entire lifecycle.
Crucially: the SBOM is not the output of a downstream scan. It is based on a maintained components list created in the development process and continuously updated. That list documents which software and firmware building blocks are contained in a product — completely, not just the parts an automated tool can recognize.
The CRA therefore requires a documented overview of all dependencies of a product with digital elements. That includes in-house software, third‑party libraries, open‑source components and the firmware in purchased parts.
Where SBOM tools fall short
SBOM scanners certainly make a useful contribution. They analyze source code and build artifacts, identify known software packages and generate a machine‑readable components list — typically in SPDX or CycloneDX format. For pure software products with common package managers this often works well.
For products with digital elements as meant by the CRA — devices, machines and embedded systems — the reality is different. Many of these products contain components a scanner simply cannot detect:
- Firmware in purchased parts: a cellular modem, a Bluetooth chip or a specialized sensor brings its own firmware. It runs on the device but is neither visible in the product’s source code nor resolvable via package managers. For a scanner, this firmware does not exist.
- Purchased software modules: proprietary libraries from suppliers that are integrated as binaries do not show up in an automated scan.
- Operating system layers and board support packages: BSPs for embedded systems often include patches, drivers and configurations that go beyond standard packages.
The result: an SBOM scan yields a subset of the components actually contained in the product. Treating that subset as the complete SBOM leaves a gap in the documentation that will show up under closer inspection.
The component list as the starting point
The real basis of the SBOM is not a tool output but a components list maintained within the development process. Ideally this list is created at the start of product design and grows with every design decision: which operating system will be used? which libraries are integrated? which supplied parts bring their own firmware?
This components list is a working document for development. It is supplemented when new dependencies are added and cleaned up when components are removed. At the end of the development process it forms the basis from which the SBOM for the technical documentation is produced.
In this picture the SBOM scan plays a different role than many assume: it is a validation, not the starting point. The scan checks whether the maintained components list matches the actual build. If the scan results differ from the list (e.g. components are missing or unexpected ones appear), that points to a problem in the development process. Something was added without documentation, or a documented component was replaced without updating the list.
Reversing this order and making the scan the source of the SBOM removes that control function and thus a key element of the required traceability.
The relation to the secure development process
The requirement for a complete components list is not isolated. The CRA requires manufacturers to develop products with digital elements taking cybersecurity into account. Documenting the used components is part of that secure development process.
Those already working with established frameworks will see the parallel: IEC 62443-4-1, for example, explicitly requires component management within a secure development lifecycle. Components are recorded, assessed and tracked across the entire lifecycle. The maintained components list there is not an optional artifact but an integral part of the process.
Manufacturers who have such a process already in place therefore bring an essential prerequisite for CRA‑compliant SBOM creation. Those who rely solely on scan tools have a tool but no process.
SBOM template
No gaps in SBOM documentation. Our template covers all CRA requirements — including firmware in purchased parts.
Download template now
Conclusion
The CRA’s SBOM requirement cannot be met by a tool alone. The CRA demands a complete, documented overview of all software components of a product, including firmware in purchased parts that a scanner cannot detect. The foundation for this is a maintained components list in the development process. The scan is a useful means of validation, but it does not replace the process itself.
Manufacturers who understand early on that the SBOM is an output of their development process and not a downstream scan artifact will not only avoid rework during conformity assessment — they will also lay the groundwork for robust vulnerability management across the entire product lifecycle.
