An autonomous vehicle or mobile robot runs software from many suppliers: operating systems, drivers, perception libraries, communication stacks and update clients. A firmware SBOM lists those components with versions, so when a library is found vulnerable you can tell within hours which machines carry it, rather than finding out from a customer.
What is different about machines?
On a server, you patch and move on. A machine in the field has a long service life, limited connectivity and safety consequences. The software inside was assembled by a chain of suppliers, and the manufacturer may not know every library in a component it bought.
NIST SP 800-161 states the underlying problem: organisations have limited visibility into how the technology they acquire is built and deployed, and products may contain malicious functionality or be vulnerable because of poor development practices. For a fleet, that lack of visibility multiplies by the number of units.
What should a firmware SBOM contain?
CISA describes an SBOM as a nested inventory, a list of the ingredients that make up software components. For firmware, aim for:
- The product, hardware revision and firmware version it describes.
- Each component with name, version and supplier.
- Nested components, including libraries inside binaries supplied by tier one and tier two suppliers.
- Hashes or identifiers that let you match a component across releases.
- The date and tool that produced it.
CISA's minimum elements guidance has been updated for 2026, so check its current list. Formats such as SPDX and CycloneDX are common, and NTIA has highlighted both alongside SWID.
Why firmware SBOMs are harder
Much firmware is compiled into one binary with static linking, so there is no package manager to read. Tools must analyse the binary or the build. Suppliers also differ in whether they will share what is inside. Build the requirement into contracts early.
How does this connect to standards?
ISA/IEC 62443 includes a part on secure product development lifecycle for suppliers and another on technical requirements for components, aimed at industrial automation. That family is relevant to robots used in industrial settings, and ISO 10218-1:2025 for industrial robots reportedly adds cybersecurity requirements to the extent they affect safety. Road vehicles have their own regulations and standards. We did not fetch them for this post, so check the rules that apply to your product and market directly.
What do you do with the list?
An SBOM is only useful if connected to vulnerability data and to a process. Match components to advisories. Decide which are reachable in your product, as a flaw in a library that your code never calls is a different case from one in a network parser. Then plan the update path: how fast can you ship a fix to a vehicle in the field, and what testing does it need?
A machine that cannot be updated safely is a risk that grows each year. Treat the ability to ship a signed update as a safety feature.
What to do
- Require an SBOM from every software and firmware supplier, in a machine readable format, per release.
- Generate your own SBOM for each firmware build and store it with the release.
- Match components against vulnerability advisories on a schedule and when new ones appear.
- Assess reachability for the findings that matter and record the decision.
- Test the update path: signing, staged rollout, rollback and offline recovery.
- Define how long you support each model with fixes, and tell customers.
Quick check
Is an SBOM the same as a vulnerability list?
No. It is an inventory. You combine it with vulnerability data to see which components have known issues.
Can a firmware SBOM be generated automatically?
Often from the build system, which is more accurate than analysing a finished binary. Binary analysis can fill gaps for third-party blobs.
Sources
- CISA SBOM
- NTIA Software Bill of Materials
- NIST SP 800-161 Rev. 1
- ISA/IEC 62443 series overview
- ANSI Blog on ISO 10218-1:2025
Last reviewed: 18 October 2026.
