Section 01 · Regulatory Context
Why FDA cares about SBOMs
If you've sold a connected medical device in the last decade, your software stack has quietly become a regulatory artifact. The FDA no longer treats third-party components as someone else's problem - under the 2023 omnibus authority (Section 524B of the FD&C Act), if you can't tell the agency exactly what's running inside your device and how you're monitoring it for vulnerabilities, your submission can be rejected outright.
The Software Bill of Materials (SBOM) is the regulatory artifact that makes this possible. It is, at its simplest, a structured inventory of every software component shipped with your device - open source, proprietary, and everything in between.
Three forces are converging
- FDA enforcement. Cybersecurity is now a refuse-to-accept criterion, not a recommendation.
- Health-system procurement. Hospitals increasingly demand SBOMs as a condition of purchase, often using the MDS2 form.
- Threat reality. Ripple-20, Log4Shell, and Curl CVE-2023-38545 each affected hundreds of medical device models. Manufacturers without SBOMs spent weeks just figuring out if they were exposed.
Section 02 · The Rule Itself
What the Section 524B RTA rule actually requires
The FDA's guidance "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions" (February 3, 2026 final, superseding the June 2025 and September 2023 finals) is the authoritative document reviewers apply today. The rule applies to any device that meets the statutory definition of a "cyber device" - software-containing, internet-capable, and presenting a cybersecurity risk. In practice, that's the vast majority of modern Class II and Class III submissions.
Four concrete obligations
- Submit an SBOM in a machine-readable format (SPDX, CycloneDX, or SWID) with every premarket submission.
- Demonstrate a vulnerability management process - not just a policy document, but evidence it actually runs.
- Provide a coordinated disclosure plan with a public point of contact for security researchers.
- Plan for postmarket updates, including how patches will be delivered to fielded devices.
Section 03 · The Five Artifacts
What every premarket submission needs
FDA reviewers look for five distinct artifacts. Missing any one of them is a common cause of additional information (AI) requests that delay clearance by 60-90 days.
| # | Artifact | Format | Common gap |
|---|---|---|---|
| 1 | Machine-readable SBOM | CycloneDX 1.5+ / SPDX 2.3+ | Hand-edited JSON; missing hashes or transitive deps |
| 2 | Component support status | Table or appendix | Missing Level-of-Support (LOS), End-of-Support (EOS), or End-of-Life (EOL) per component |
| 3 | Known-vulnerability list + VEX | VEX (CycloneDX VEX or CSAF) | Stale CVE lookup; no VEX status at submission |
| 4 | Safety & security rationale | Narrative per finding | Generic 'not exploitable' with no device or patient-harm context |
| 5 | Update mechanism description | SPDF + architecture view | No evidence patches reach fielded devices |
Section 04 · Building It
An SBOM that won't get flagged
A conforming SBOM starts with the seven NTIA minimum elements. The FDA's February 2026 final premarket cybersecurity guidance requires more on top: Level-of-Support (LOS), End-of-Support (EOS), and End-of-Life (EOL) metadata for every component, plus a known-vulnerability list with a device-specific safety and security rationale.
NTIA minimum elements (all seven, required)
- Supplier name
- Component name
- Version of the component
- Other unique identifiers (PURL, CPE, or SWID)
- Dependency relationship
- Author of the SBOM data
- Timestamp
FDA additions (Feb 2026 guidance, Appendix 4)
- Level-of-Support (LOS): actively maintained, limited support, or unsupported. The FDA's three-tier taxonomy
- End-of-Support (EOS) date: when the supplier stops issuing security patches
- End-of-Life (EOL) date: when the supplier stops shipping the component entirely
- Known-vulnerability list with VEX status (affected, not_affected, fixed, under_investigation) and justification
- Safety and security risk rationale per finding, tied to the device's patient-harm pathway
Passing → professional
- Cryptographic hash of each binary (SHA-256+)
- License declaration with SPDX identifier
- Source location for build reproducibility
- Known unknowns: what you couldn't resolve, and why
Section 05 · Monitoring
Continuous monitoring without the noise
An SBOM submitted at clearance is a snapshot. By the time your device ships, half a dozen new CVEs likely affect components in it. By the time it's been in the field a year, that number is often in the hundreds.
The compliance question isn't "are there CVEs?" - there always are. It's whether you have a defensible process for finding them, evaluating them, and acting on the ones that matter.
What "defensible" looks like
- Automated daily ingestion from NVD, GitHub Security Advisories, and vendor-specific feeds
- Component-to-CVE matching using PURL/CPE - not just package name string matching
- Device-context triage: is the affected component reachable, on a network interface, and exercising the vulnerable code path?
- Exploitability scoring using EPSS and CISA KEV in addition to CVSS
- Documented decisions for every CVE - patch, mitigate, or accept (with rationale)
Section 06 · Evidence
The postmarket evidence trail auditors look for
In a postmarket inspection or AI request, FDA doesn't want to hear that you have a process - they want to see it. The evidence trail should be reproducible from raw data with no manual reconstruction.
The five evidence artifacts
- Versioned SBOMs for every released firmware/software build, retained for the device's supported life
- CVE triage log - each finding, when it was detected, who reviewed it, and the disposition rationale
- VEX statements documenting non-exploitable findings with technical justification
- Patch deployment records - what shipped, to whom, and confirmation of installation
- Annual security review summarizing posture, incidents, and trend data
Section 07 · Pitfalls
Common mistakes (and how to avoid them)
After working on dozens of medical-device cybersecurity submissions, the same mistakes appear again and again. Here are the ones most likely to bite you.
Treating the SBOM as a one-time deliverable
It's a living artifact. Generate it on every build, store it with the build, and diff it across releases.
Only listing top-level dependencies
FDA expects transitive dependencies too. A 'shallow' SBOM is one of the fastest ways to fail RTA.
Ignoring firmware and embedded OS components
Yes, that includes the BusyBox in your bootloader and the OpenSSL inside your TLS stack. Both have shipped with major CVEs.
Submitting CVE lists from a single point in time
By the time the reviewer reads it, it's stale. Document your monitoring process instead - that's what they actually want.
Outsourcing without auditing
If your contract manufacturer or SDK vendor provides components, you are still responsible for their SBOM data. Get it in writing.
Confusing CVSS with risk
A 9.8 CVSS in a component you don't actually invoke is lower priority than a 5.4 in your authentication path. Document the difference.
Section 08 · Roadmap
A 90-day SBOM compliance roadmap
If you're starting from zero, ninety days is enough to reach defensible compliance for a single device line. Here's the sequence we use with clients.
| Phase | Days | Outcome |
|---|---|---|
| 1. Discover | 0-15 | Inventory build systems, identify all third-party components and firmware blobs, choose SBOM format (CycloneDX recommended). |
| 2. Generate | 15-35 | Integrate SBOM generation into CI/CD. Validate completeness against build artifacts. Produce VEX baseline. |
| 3. Monitor | 35-60 | Stand up daily CVE ingestion against the SBOM. Define triage criteria, severity thresholds, and escalation paths. |
| 4. Evidence | 60-80 | Implement versioning and retention. Document the process in a Cybersecurity Management Plan section of your DHF. |
| 5. Operate | 80-90 | Run a tabletop exercise on a simulated CVE. Refine the playbook. You are now defensibly compliant. |
Section 09 · Next Steps
How GoatWatch fits in
GoatWatch by Blue Goat Cyber is the SBOM risk management platform built specifically for medical device manufacturers. We do exactly what Sections 5 and 6 of this playbook describe: automated ingestion, device-context triage, VEX-ready evidence, EOL/EOS/LOS tracking, without the noise.
What you get
- Daily CVE matching against your live SBOMs (CycloneDX & SPDX)
- Device-context impact triage that filters out non-exploitable findings
- VEX statements generated automatically with reviewer-ready rationale
- Versioned, audit-ready evidence retained for the device's supported life
- Senior MedTech security experts on call - not a ticket queue
This guide is provided for educational purposes and does not constitute legal or regulatory advice. Always consult your regulatory affairs team and qualified counsel for submission-specific guidance.