Before first shipment, a hardware startup needs a machine-readable SBOM for the firmware image and a separate one for the companion app, each listing at least direct dependencies with name, version and supplier. Generate it from the build, store it with the release, and keep it private unless a customer asks.
What the rules actually say
The EU Cyber Resilience Act (Regulation 2024/2847) is the clearest public statement of what an SBOM duty looks like for connected products. Annex I, Part II, point 1 says manufacturers must identify and document vulnerabilities and components, including by drawing up a software bill of materials in a commonly used and machine-readable format, covering at least the top-level dependencies. Recital 77 adds that manufacturers should not be obliged to make the SBOM public.
Two lessons follow. First, the bar is a real, machine-readable file, not a spreadsheet someone maintains by hand. Second, the SBOM is something you keep and use for vulnerability handling. Publishing it is a choice. Whether the regulation applies to your product is a question for your own counsel.
What goes in a startup SBOM
| Layer | Examples | Common miss |
|---|---|---|
| Bootloader | Open-source bootloader, vendor ROM patches | Forked version not recorded |
| RTOS or Linux base | Kernel, C library, init system | Config options that change what is built |
| Vendor SDK | Radio stack, driver pack, HAL | Binary blobs with no version string |
| Libraries | TLS, JSON, compression, protocol parsers | Copied source files, not packages |
| Companion app | Mobile libraries, analytics, crash SDKs | Transitive dependencies |
| Cloud tooling | Device backend packages | Treated as someone else's problem |
How to build one without a security team
- Pick one format, CycloneDX or SPDX, and stay with it. Both are widely used and both have tooling.
- Generate the SBOM in the build, not afterwards. A file made from the exact build inputs is more trustworthy than one reconstructed from memory.
- Record vendor blobs by hand if you must: supplier, version, hash, and where the vendor publishes advisories.
- Name the SBOM after the release. Firmware 1.4.2 gets an SBOM 1.4.2, kept in the same artifact store.
- Re-check old SBOMs when new advisories land. A shipped device is as safe as the list you can search is complete.
Where startups trip
The common failure is a firmware SBOM that lists the open-source packages from the package manager and nothing else. The risky code is often a vendor SDK dropped into the tree and edited. If a file was copied and patched, say so in a notes field, because a scanner cannot see it.
The second failure is treating the SBOM as a launch task. The value shows up eighteen months later when an advisory lands and you need to answer "are we affected?" in an hour, not a week.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how direct and transitive dependencies are separated.
Safeguard's SBOM and dependency scanning covers the companion app and cloud repositories you point it at, and you can try a free scan at gold.safeguard.sh/scan. It does not replace the hand-kept record of vendor blobs in your firmware.
Quick check
Do we have to publish our SBOM?
Recital 77 of the CRA says manufacturers should not be obliged to make the SBOM public. You still need to have one and use it. Customer contracts may ask for it separately.
One SBOM or two?
Two is cleaner. Firmware and the companion app have different dependency ecosystems, release cadences and owners.
Sources
Last reviewed: 19 October 2026.
