Article
SBOM Hygiene for Medical Devices: A Practical 2026 Playbook
Key takeaways
- An SBOM produced by hand or only at submission time is the single most common cause of postmarket cybersecurity surprises.
- SPDX and CycloneDX are both acceptable to FDA; pick one, generate it from the build, and stop debating format.
- SOUP analysis is where most submissions fail review, not SBOM generation itself.
- Reviewers cross-check submitted SBOMs against the CISA KEV catalog and the NVD; unaddressed criticals draw deficiencies.
- Your postmarket monitoring is only as good as the SBOM it queries against, so the same artifact has to live past clearance.
Why this matters
Since FDA gained Refuse-to-Accept authority under Section 524B of the FD&C Act, the SBOM has moved from a nice-to-have appendix to a load-bearing artifact in every premarket submission. In 2025, across the 250+ submissions my team at Blue Goat Cyber cleared, weak SBOMs and thin SOUP analyses were the most common single reason a package came back with deficiencies.
The deeper problem is that the SBOM is also the foundation of postmarket cybersecurity. When a new critical CVE lands against a library you embedded eighteen months ago, the speed of your response is gated entirely by whether your SBOM is accurate, current, and queryable. Teams that treat the SBOM as a submission artifact discover this the hard way; teams that treat it as a living engineering asset respond in hours, not weeks.
What does FDA actually expect in a medical device SBOM?
FDA expects a machine-readable SBOM (SPDX or CycloneDX) that lists every software component shipped on the device or in companion software, including operating system, drivers, libraries, embedded RTOS, third-party SDKs, open-source dependencies, and any binary blobs from chipset vendors. Each entry should carry name, version, supplier, and a unique identifier (PURL or CPE) sufficient to map against vulnerability databases.
The FDA premarket cybersecurity guidance is explicit that the SBOM must be accompanied by a vulnerability assessment and a plan for ongoing monitoring. A list of components without that wrapper is not an SBOM in the regulatory sense; it is a parts manifest.
Where should the SBOM actually be generated?
In the build pipeline, not in a spreadsheet, and not at submission time. Tools like Syft, CycloneDX Maven/Gradle/npm/PyPI plugins, and SPDX generators integrate into CI in an afternoon. The output should be versioned alongside the build artifact so every released firmware image has a corresponding SBOM hash bound to it.
When reviewers ask, 'Does this SBOM represent the device under review?' you want to answer with build provenance, not a story. Sign the SBOM with the same key chain you use for firmware signing whenever the device threat model allows it.
How do you handle SOUP and third-party components properly?
Software of Unknown Provenance is the category most teams underestimate. Any component you did not author and cannot fully audit is SOUP: open-source libraries, vendor SDKs, embedded RTOS kernels, chipset firmware, machine learning model weights. AAMI TIR57 expects you to document the rationale for using each SOUP component, its known vulnerabilities, the residual risk it introduces, and the mitigations you applied.
A defensible SOUP analysis ties every component to (1) a supplier of record, (2) a current vulnerability scan, (3) a justification for inclusion, and (4) a fallback plan if the supplier goes away or the component becomes unsupported. The fallback plan is the part teams skip; reviewers notice.
How do you keep the SBOM current after release?
The SBOM has to be regenerated whenever the codebase changes (every release, every hotfix) and re-scanned against vulnerability feeds on a defined cadence. Monthly is the minimum credible cadence for active products; weekly is better for high-risk surface (network-connected, wireless, exposed services).
The operational pattern that works: a scheduled job pulls the current SBOM for every supported firmware version, queries the NVD and the CISA Known Exploited Vulnerabilities Catalog, and opens a triage ticket the moment a new CVE matches a component in the bill of materials. The triage decision (patch now, patch in next release, accept with compensating control, retire) is logged against the device record, not the engineer's inbox.
What format should you pick: SPDX or CycloneDX?
Either. Both are accepted by FDA, both are machine-readable, and both have mature tooling. CycloneDX has slightly richer vulnerability and pedigree extensions; SPDX has slightly broader legal and license tooling. Pick the one your toolchain produces natively and stop holding meetings about it.
What matters is consistency across the product portfolio. If you have three product lines each producing a different format, your postmarket monitoring has to speak three dialects, and that is where errors creep in.
How does the SBOM connect to international submissions?
The same SBOM, with minor metadata additions, satisfies EU MDR, the EU Cyber Resilience Act, MDCG 2019-16, IMDRF principles, TGA expectations, and the maturing NMPA and PMDA cybersecurity requirements. The cost of producing a high-quality SBOM is amortized across every jurisdiction you launch into, which is why the math favors investing in the pipeline once.
Map your SBOM and SOUP analysis to the strictest jurisdiction in your roadmap. Back-mapping documentation later is almost always more expensive than over-engineering it once at the start.
How Christian approaches this
At Blue Goat Cyber we build the SBOM into the client's CI pipeline before we write a single line of the premarket package. The SBOM becomes the source of truth for the threat model, the vulnerability report, the postmarket plan, and the labeling. Every artifact in the submission references the same component manifest, with the same version pins, signed by the same build.
The approach is documented in my 2026 book, Medical Device Cybersecurity: An In-Depth Guide (see the chapter overview). The chapter on SBOM and SOUP is the one I get the most questions about from product teams, because it is the one that changes day-to-day engineering practice the most.
Related guides: Threat modeling connected medical devices, Postmarket vulnerability management, and What the FDA actually wants in a 2026 premarket submission.