Most hardware startup supply chain myths come from treating firmware as finished once it ships. In fact, signing alone does not prove safety, SBOMs need not be public, vendor SDKs still need tracking, and updates are part of the product. Here are five myths and what the sources say.
Myth 1: A signed image is a safe image
Fact. A signature shows a key holder approved the file. It says nothing about whether the key was stolen or the code is sound. The Update Framework names key compromise, a properly signed but malicious file, as an attack it aims to limit. Protect the key and plan for replacing it.
Myth 2: We have to publish our SBOM
Fact. Recital 77 of the Cyber Resilience Act says manufacturers should not be obliged to make the SBOM public. Annex I Part II point 1 does speak of drawing up a machine-readable SBOM covering at least top-level dependencies. Keep one, use it, share it when a contract asks.
Myth 3: The chip vendor handles security for the SDK
Fact. The vendor fixes their code. Your product runs your copy, usually edited. Recital 34 points toward checking whether a component receives regular security updates. Track the vendor's advisories and record your version.
Myth 4: We can add updates later
Fact. If a unit has no safe update path, a flaw found after launch cannot be fixed on that unit. The recitals describe products with functions for security updates to be notified, distributed, downloaded and installed. Build the channel in version one.
Myth 5: Small companies are too small to target
Fact. Attackers pick products by how reachable and common they are, not by the size of the maker. A small company with a popular device is a target for the same reasons a large one is. A weak update path or shared default password is useful to any attacker.
A scoreboard
| Belief | Verdict | First action |
|---|---|---|
| Signed means safe | False | Protect and plan to replace keys |
| SBOM must be public | False | Generate it, keep it |
| Vendor owns SDK security | Partly | Record version, follow advisories |
| Updates can wait | False | Test the update path now |
| Too small to matter | False | Close interfaces, unique credentials |
How to use this list
Pick the myth your team believes most and test it. If someone says the update path works, ask for the log from a bench unit that lost power mid-update. If someone says keys are safe, ask where the file is.
Try it yourself
Click through it at your own pace, or open it full screen. See how a finding is judged by whether it can really be exploited.
Quick check
Is any single control enough?
No. Signing, inventory, update testing and closed interfaces cover different failures.
Where do we start if we do nothing today?
Start with the signing key location and the update path test, because they limit the damage from nearly every other mistake.
Sources
Last reviewed: 19 October 2026.
