The Medical Device SBOM Field Guide

Why this matters

An SBOM is only as valuable as your ability to keep it accurate and act on it. The FDA's February 2026 guidance recommends a machine-readable SBOM and a device-specific assessment of known vulnerabilities. Section 524B requires a postmarket vulnerability plan for covered submissions. Daily monitoring and VEX are Blue Goat Cyber^℠ implementation choices, not FDA-prescribed requirements. This field guide is the operating manual: which tools, which formats, which workflows, and where teams typically fail.

Key takeaway: The most common SBOM failure mode is not technical - it's organizational. No single owner, no daily monitoring cadence, no VEX discipline. Fix the operating model first; tools second.

Choose your format and stick to it

• CycloneDX 1.5 - default for medical devices (native VEX, ML-BOM, services)
• SPDX 2.3+ - generate when downstream tooling requires it; keep CycloneDX as source of truth
• Both formats are FDA-acceptable; pick one as canonical and document why
• The FDA recommends a machine-readable SBOM in an industry-accepted format; the guidance does not establish categorical PDF or spreadsheet rejection

Tool selection by device class

• SaMD / cloud - Syft, cdxgen, Trivy, language-native plugins (npm, pip, maven, go)
• Mobile companion app - cdxgen for iOS (CocoaPods/SwiftPM) and Android (Gradle)
• Embedded firmware - Syft + binary analysis (Binwalk, Ghidra, BLINT, EMBA)
• Containers - Syft or Trivy at build time, integrated with your registry
• Hardware with vendor firmware - request vendor SBOMs; document gaps

Binary analysis for firmware (the hard part)

• Extract filesystems with Binwalk; identify components by signature + string analysis
• Reconcile binary findings with build-system bill of materials
• Capture statically linked libraries that don't appear in package manifests
• Document confidence level per component (high = build-system, medium = binary match)

PURL + hash discipline

• Every component gets a Package URL (purl) - reviewers use these to map CVEs
• SHA-256 minimum for binary components; SHA-512 preferred
• Include supplier, version, and SPDX license identifier on every component
• Validate with cyclonedx-cli or spdx-tools before publishing

What's in the full PDF

• Tool matrix with strengths/weaknesses per device class
• Step-by-step firmware extraction + binary analysis workflow
• VEX operating model with five worked justification examples
• Distribution patterns: MDS2 alignment, NTIA minimum elements (superseded by CISA's 2026 Minimum Elements for an SBOM, published July 29, 2026), customer portal
• Common review-letter findings and how to pre-empt them