Section 01 · Regulatory Context
Why FDA cares about SBOMs
Section 524B requires an SBOM and other statutory content for covered cyber-device submissions. Missing required content may affect acceptance under the applicable pathway; an inventory gap does not automatically determine the review outcome.
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. Required Section 524B content is assessed under applicable acceptance rules; guidance recommendations remain nonbinding.
- Health-system procurement. Buyers may request an SBOM and security disclosures. MDS2 is a separate disclosure questionnaire, not an SBOM.
- Threat reality. Component vulnerabilities such as Log4Shell illustrate why manufacturers should assess their actual software inventory and device exposure.
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.
Statutory duties and supporting recommendations
- For covered cyber-device submissions, Section 524B requires an SBOM. Industry-accepted machine-readable formats are recommended; no universal format version floor is specified.
- Demonstrate a vulnerability management process - not just a policy document, but evidence it actually runs.
- Submit a vulnerability plan including coordinated disclosure and related procedures for covered submissions; a public contact is one implementation choice.
- Plan for postmarket updates, including how patches will be delivered to fielded devices.
Section 03 · The Five Artifacts
Five SBOM evidence areas to consider
These five evidence areas are our organizing framework, not five required separate files or a measured delay prediction. Assess statutory content and risk-based supporting evidence for the actual submission.
| # | Artifact | Format | Common gap |
|---|---|---|---|
| 1 | Machine-readable SBOM | Supported CycloneDX or SPDX; no FDA version floor | Hand-edited JSON; missing hashes or transitive deps |
| 2 | Component support status | Table or appendix | Missing recommended support level or end-of-support information; EOL tracking is an additional company practice |
| 3 | Known-vulnerability assessment; VEX optional | Documented assessment; optional VEX | Stale assessment or unsupported device-specific vulnerability conclusions |
| 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
Section 524B requires an SBOM for covered submissions. Guidance §V.A.4(a)-(b) recommends NTIA minimum elements, component support level and end-of-support date, plus known-vulnerability assessment. Missing information can be explained in an addendum. EOL tracking is an additional company practice; VEX is optional.
NTIA minimum elements recommended by FDA guidance
- Supplier name
- Component name
- Version of the component
- Other unique identifiers (PURL, CPE, or SWID)
- Dependency relationship
- Author of the SBOM data
- Timestamp
Guidance recommendations (§V.A.4) and service practices
- FDA support-level examples: actively maintained, no longer maintained, or abandoned
- Recommended end-of-support date, interpreted according to the supplier’s stated support policy
- Optional EOL tracking: when the supplier stops shipping the component entirely
- Device-specific known-vulnerability assessment; optional VEX using valid format-specific statuses and evidence
- 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 is an inventory snapshot. New vulnerability disclosures may affect listed components; evaluate device-specific relevance through a risk-justified monitoring process.
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.
An illustrative company monitoring workflow
- 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
The following records are company evidence examples. Tailor retention, review schedules, and supporting records to applicable obligations, the device, and documented quality-system policies.
Example evidence records; not a prescribed five-file package
- 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
- Documented vulnerability assessments with technical justification; VEX optional
- 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
Review component coverage against shipped software and explain inventory gaps. Do not infer an automatic acceptance decision from a top-level list alone.
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
Provide a current device-specific assessment of known vulnerabilities and applicable controls, together with the ongoing monitoring process. The process does not replace the current assessment.
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
An illustrative implementation sequence for a single device line. Compliance depends on applicable requirements, device-specific evidence, and manufacturer decisions, not elapsed days.
| 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. Assess remaining evidence and applicable obligations; completion does not establish compliance. |
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
- Draft VEX statements for evidence-backed human review; the manufacturer owns affectedness and risk decisions
- 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.