The EU Cyber Resilience Act (CRA) requires manufacturers of digital products to maintain a complete Software Bill of Materials – SBOM – for every product they place on the market. For IoT manufacturers, this presents a particular challenge: connected devices typically combine proprietary firmware, open-source libraries, and third-party components within a single product.
What Is an SBOM and Why Does the CRA Require One?
A Software Bill of Materials is a machine-readable inventory of all software components contained in a product. This includes operating systems, libraries, frameworks, drivers, and every other dependency – including transitive dependencies.
The CRA mandates the SBOM because it forms the foundation for effective vulnerability management. Without a complete overview of all deployed components, it is impossible to quickly assess whether your product is affected when a new security vulnerability is disclosed. The SBOM does not need to be publicly available, but must be producible for market surveillance authorities within 24 hours upon request.
For IoT manufacturers, this is especially critical. A typical smart home sensor can contain dozens of open-source packages, many of which bring their own dependencies. Without systematic SBOM management, teams quickly lose track.
Choosing the Right SBOM Format: SPDX vs CycloneDX
The two established SBOM formats are SPDX (Software Package Data Exchange) and CycloneDX. Both are accepted under the CRA, but they differ in their strengths.
SPDX is an ISO standard (ISO/IEC 5962:2021) with its roots in license management. It is particularly suitable when you need to address open-source license compliance alongside security. SPDX supports JSON, XML, YAML, RDF, and tag-value formats.
CycloneDX was developed by the OWASP community specifically for security use cases. It natively includes fields for vulnerabilities, security ratings, and dependency graphs. CycloneDX is more compact and directly supported by many CI/CD tools.
For most IoT manufacturers, CycloneDX is the recommended primary format, as it aligns more closely with the CRA's security requirements. Important: Document your format choice in your technical documentation and ensure you can convert to the other format if required.
Step by Step: Creating an SBOM for Your IoT Product
The SBOM creation process for IoT products differs from pure software projects because you need to account for hardware-adjacent components, firmware, and often real-time operating systems.
Step 1: Inventory all software components. Start with a complete stocktake. This includes the operating system (e.g., FreeRTOS, Zephyr, embedded Linux), all libraries and frameworks, bootloader and firmware components, drivers for peripherals and sensors, and cryptography libraries. Use automated scanners for your source code and supplement manually for what scanners miss – such as binary blobs from chip manufacturers.
Step 2: Resolve dependencies. Determine transitive dependencies for each component. A single npm package can bring hundreds of indirect dependencies. For CRA compliance, you must fully document at least direct dependencies. Best practice is to include transitive dependencies up to the second or third level.
Step 3: Capture metadata. For each component, you need at minimum the package name, exact version, supplier or author, license, and a unique identifier (e.g., CPE or PURL). This metadata is essential for automated matching against vulnerability databases such as NVD or OSV.
Step 4: Generate and validate. Generate the SBOM in your chosen format and validate it against the respective schema. Check for completeness: Are any components missing that you identified in Step 1? Are all version numbers correct?
Step 5: Integrate into your development process. An SBOM is not a one-time document. Integrate SBOM generation into your CI/CD pipeline so that an up-to-date SBOM is automatically produced with every build. This ensures the SBOM always reflects the actual shipped product state.
Common SBOM Mistakes to Avoid
In practice, many manufacturers fail not at the principle of SBOMs, but at typical pitfalls during implementation.
The most common mistake is incomplete capture. Automated scanners often miss firmware blobs, statically linked libraries, or components included as binary files. Always plan for a manual review step.
Another frequent error is failing to keep the SBOM updated. The CRA requires the SBOM to reflect the current state of the product – including after updates and patches. If your SBOM only covers the initial release but does not track security updates, that is a compliance risk.
Finally, many manufacturers underestimate the effort required for third-party components. If you use purchased modules such as WiFi modules or Bluetooth stacks, you need to request SBOM data from your suppliers. Start this process early, as not all suppliers can provide this information immediately.
How Kunnus Simplifies the SBOM Process
Manual SBOM creation and maintenance is time-consuming and error-prone – especially when managing multiple product lines with different software stacks. Automated tools significantly reduce the effort and minimize the risk of incomplete documentation.
Kunnus helps IoT manufacturers automatically generate SBOMs, match them against known vulnerabilities, and manage all CRA documentation in one place. This gives you a clear overview across all product versions, allowing you to demonstrate within minutes which components are contained in which product.
Beyond the SBOM, a functioning vulnerability management process and the correct conformity assessment are central building blocks of CRA compliance.
Want to know where you currently stand with CRA compliance? Our free CRA readiness assessment shows you in just a few minutes what steps are still needed – including an evaluation of your current SBOM process.