Know which software is in the delivered product
Your RTOS, bootloader, SDK and libraries affect device security. A Software Bill of Materials, or SBOM, links these components to the delivered product version. That link turns a general vulnerability alert into a product-specific technical assessment.
Assess your SBOM and component inventoryConnect the component inventory to each release
As part of vulnerability handling, the CRA requires an SBOM in a commonly used machine-readable format covering at least top-level dependencies. SPDX and CycloneDX are common options and are recommended here as technical formats. Greater depth is useful where transitive dependencies may conceal security risks.
For new products, the SBOM should be generated through the build process. For legacy firmware, source analysis, existing supplier lists and binary analysis can be combined. Uncertainty remains explicit: an inventory reconstructed from binaries does not guarantee completeness. The CRA does not impose a general obligation to publish the SBOM publicly.
A library alert example
An alert concerns a cryptographic library. The release-specific SBOM identifies the device versions containing that component. The technical assessment then determines whether the vulnerable function is reachable and what remediation is needed. A database match alone establishes neither active exploitation nor a reporting obligation. This is an illustrative example.
What Solvetronix helps you establish
- An SBOM for the agreed scope linked to versions and builds.
- Documented inventory gaps and questions for component suppliers.
- A process for updates, impact assessment and remediation.
Legal basis and sources
General information and technical guidance. The specific assessment depends on the product, role and use. Reviewed 22 October 2026.