SBOM, firmware and CRA guides for IoT teams
Ten guides written for firmware and product security engineers. Each one starts with the symptom, gives a procedure you can follow this week, states the limits, and links the sources and the matching free tool.
Firmware SBOMs for embedded devices
What a useful firmware SBOM contains, how to generate one from Buildroot or Yocto, and which parts of an embedded build it will still miss.
How to validate CycloneDX and SPDX SBOMs
A practical validation order for CycloneDX JSON and SPDX 2.3: schema first, then component identity, dependency references and query readiness.
Common SBOM validation errors and how to fix them
The schema and quality defects that appear most often in CycloneDX and SPDX files, what causes them, and the fix for each.
How to compare firmware SBOM versions
A repeatable method for diffing a baseline and a new firmware SBOM, reading added, removed and updated components, and knowing what the diff does not prove.
EU CRA requirements for IoT manufacturers
A practical orientation to the Cyber Resilience Act for connected-device makers: scope, roles, dates, vulnerability handling and the evidence you will need.
CRA Annex VII technical documentation: what goes in it
The eight areas Annex VII requires in CRA technical documentation, mapped to the product evidence an IoT manufacturer can produce — and what it does not prove.
Managing supplier SBOMs without losing the origin
How to request, validate and compare supplier SBOMs, keep the supplier-to-product link, and avoid the failure where every inventory looks the same.
Why your SBOM finds zero vulnerabilities
Zero findings usually means the components could not be matched, not that the firmware is clean. Here is how to tell the difference and fix the data.
How to fix missing purl and CPE identifiers
A practical method for adding package URLs and CPE names to embedded components, without inventing identities that break matching.
SBOM validation vs continuous monitoring
Validation answers “is this document usable”, monitoring answers “is this shipped version still affected”. You need both, and they fail in different ways.
Why these are long and narrow
Generic “what is an SBOM” content does not help anyone pass a supplier review. These guides answer a question that appears in real release and procurement work, and they say when the answer does not apply.
Every guide states its limits
What the procedure does not cover, and what a result does not prove.
Every guide cites its sources
Regulation text, specifications and public guidance — linked, not paraphrased into authority.
Every guide ends at a tool
So the next step is a check you can run, not another article.