Every premarket submission for a cyber device now legally requires a software bill of materials, and missing it can get your submission refused outright. Building a compliant medical device SBOM isn’t optional under Section 524B of the FD&C Act, enforced since October 2023. This isn’t a recommendation from a guidance document or a best practice from an industry working group. It’s federal law.
Most device engineering teams understand the concept: a structured inventory of software components, their versions, and their dependencies. Where teams consistently fall short is understanding what the FDA actually expects inside that document, which formats qualify as machine-readable, and how to keep the inventory current after clearance. This guide covers each of those layers in detail: regulatory mandate, required content, format selection, generation tooling, and postmarket maintenance. At Blue Goat Cyber, we’ve built submission-ready software bills of materials for manufacturers across hundreds of premarket submissions, and the patterns in deficiency letters are consistent enough to be instructive.
What a medical device SBOM actually is
An SBOM is a complete, structured inventory of every software component inside a device, proprietary code, open-source libraries, third-party packages, commercial off-the-shelf software, and the full dependency tree beneath each of those components. The closest analogy is a nutrition label. It tells every stakeholder, including the FDA, hospital security teams, and your own engineers, exactly what’s inside the product so vulnerabilities can be tracked and managed systematically.
The FDA’s definition of a “cyber device” under Section 524B is specific: any device that contains software and can connect to the internet, thereby posing potential cybersecurity risk. Not every medical device falls into this category, but most connected, networked, or software-driven products do. Infusion pumps, cardiac monitors, imaging systems, wearables, and networked hospital equipment all qualify. If your device has software and a network interface, assume Section 524B applies.
Regulators care about software transparency for a straightforward reason. Untracked third-party libraries and open-source components are the most common entry point for cybersecurity vulnerabilities in medical devices. A software bill of materials gives the FDA and manufacturers a mechanism to identify, monitor, and respond to newly discovered CVEs across the full product lifecycle. Without one, postmarket vulnerability management becomes essentially impossible to perform in any systematic way. Pairing SBOMs with automated testing and static application security testing (SAST) improves vulnerability discovery and remediation, see our guide on SBOM and SAST for practical integration patterns.
The FDA mandate: what changed in 2023 and what it means now
The Consolidated Appropriations Act of 2023 amended the FD&C Act by adding Section 524B, which codified software bill of materials requirements into federal law for the first time. Manufacturers submitting 510(k), De Novo, PMA, or similar applications for cyber devices must now include this documentation as a required element, not a best practice, not a recommendation. The FDA has explicit authority to refuse any submission it considers deficient in cybersecurity content.
The timeline matters for planning. Requirements apply to submissions on or after March 29, 2023, and the FDA’s authority to refuse non-compliant submissions took effect October 1, 2023. The February 2026 final guidance (“Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions“) reinforced and expanded these expectations in Section V.A.4 and Appendix 4. That guidance is technically non-binding, but practically speaking, submissions with weak or incomplete documentation face delays and deficiency letters consistently. For a focused walkthrough of these expectations and format implications, see our post on FDA SBOM requirements for medical devices.
To understand how significant the shift is, consider the earlier posture. The 2014 and 2022 guidance documents recommended software bills of materials without requiring them, so engineering teams could treat generation as a documentation afterthought and still get through a submission. An incomplete inventory is now grounds for refusal, and there’s no ambiguity in the current framework about that.
What your medical device SBOM must include
The FDA references the NTIA minimum elements as the baseline for content. These seven fields are required for any submission:
- Supplier name: the organization providing the component
- Component name: the identified name of the software component
- Component version: the specific version string
- Unique identifier: a Package URL (PURL) or Common Platform Enumeration (CPE) for precise matching
- Dependency relationships: how components relate to and depend on one another
- SBOM author: who created the document
- Timestamp: when it was assembled
The FDA expects more than the NTIA baseline for medical devices. Required additions include support and lifecycle metadata for each component, specifically whether the component is actively supported, in legacy status, or unsupported. End-of-support and end-of-life dates must be documented. The FDA also expects vulnerability assessments that identify known CVEs against each component, along with documented mitigations and a risk mitigation plan tied to postmarket monitoring. These additions reflect the FDA’s focus on the total product lifecycle, not just the snapshot at submission time.
Which software components must be captured
A question that comes up often is scope. The answer is all of it. Proprietary firmware, commercial off-the-shelf software, open-source libraries, third-party SDKs, bootloaders, and operating system components all belong in the inventory. The depth of documentation scales with the device’s cyber-risk tier. Low-risk devices require a complete component list with vulnerability scanning. Moderate-risk devices require a full dependency tree plus CVE mapping. High-risk devices require end-to-end documentation including build tools. At every tier, a partial list is not acceptable.
Choosing a format: SPDX, CycloneDX, and what the FDA accepts
The FDA recognizes three machine-readable formats: SPDX, CycloneDX, and SWID tags. SWID tags are less commonly used as standalone outputs. The practical decision for most manufacturers comes down to SPDX versus CycloneDX. The FDA does not mandate a specific format, but both must be machine-readable and accompanied by a human-readable summary document.
SPDX vs. CycloneDX: which is right for your device
SPDX is maintained by the Linux Foundation and is the more established standard overall. It excels at license tracking across open-source components, which makes it useful for organizations managing intellectual property compliance alongside cybersecurity. CycloneDX is purpose-built for security use cases. It has native support for vulnerability data through VEX documents, stronger dependency relationship mapping, and tighter integration with CVE databases. For most connected medical device manufacturers, CycloneDX is the stronger choice. Teams with significant open-source licensing obligations may prefer SPDX or run both formats in parallel.
The machine-readable requirement has a specific operational meaning. The file must be in a structured format, JSON, XML, or RDF, that automated tools can parse, query, and compare against vulnerability databases. A spreadsheet or PDF does not meet this standard. A human-readable summary is a required companion document, not a substitute for the structured file. For practical strategies on meeting the FDA’s format and content expectations, this guide to complying with FDA SBOM requirements provides vendor-agnostic recommendations and common pitfalls to avoid.
How to generate and maintain your SBOM across the device lifecycle
Generation for embedded medical devices requires tools suited to firmware and RTOS environments. Standard application-layer scanners miss components that live deeper in the stack. Syft works well for container and embedded Linux builds, producing SPDX or CycloneDX output. Yocto’s create-spdx class generates inventories automatically during image creation, which makes it a natural fit for teams already using Yocto for embedded Linux. Snyk covers open-source dependency scanning and vulnerability assessment. Keysight SBOM Manager uses binary analysis for deeply embedded components where source access is limited, particularly valuable for devices built on legacy or proprietary firmware.
Integrating SBOM generation into your development pipeline
The most efficient approach is to integrate generation directly into the CI/CD pipeline so every release produces an updated, versioned file automatically. This removes the manual step that causes documentation to drift out of sync with the actual codebase. Each version should be cryptographically tied to a specific software release for traceability. EOL and EOS status should be tracked continuously, not just at submission time. A centralized repository, not email, is the right distribution mechanism for sharing current and historical versions with the FDA, healthcare providers, and internal teams.
The FDA treats these documents as living records, not one-time submissions. Every patch, dependency update, or component removal requires an update. To close the loop with postmarket surveillance, feed component data into vulnerability databases like Google OSV or Dependency Track. Filter CVEs by device configuration and version to eliminate false positives and document a formal remediation and disclosure process. Continuous postmarket cybersecurity monitoring is part of the ongoing obligation the FDA expects manufacturers to maintain after clearance. The FDA’s own cybersecurity FAQs are a helpful reference for reviewers’ expectations around postmarket obligations and documentation.
How Blue Goat Cyber builds submission-ready SBOMs for device manufacturers
The most common deficiencies we see in FDA submissions follow predictable patterns. Incomplete dependency trees that miss transitive dependencies are the most frequent issue. Missing lifecycle metadata for third-party components is a close second. Inventories submitted in non-machine-readable formats, PDFs or spreadsheets, generate immediate deficiency letters. The absence of a documented vulnerability management plan is the gap that tends to create the longest delays. All of these issues are avoidable if you know what FDA reviewers are looking for before the submission goes in.
Blue Goat Cyber handles the full build under a done-for-you model: component discovery and dependency mapping, format selection, metadata population, vulnerability assessment, and final documentation. The output is an eSTAR-ready package aligned with the February 2026 FDA final guidance, IMDRF N73 principles, and NTIA minimum elements. Engineering teams provide access to their codebase and build environment. Blue Goat Cyber delivers a submission-ready package built specifically for FDA review, not a generic enterprise software inventory. Learn more about our FDA-compliant SBOM services for MedTech and what the engagement looks like.
SBOM compliance for medical devices is not the same as standard enterprise software inventory management. The FDA’s cyber device framework, the medical-device-specific metadata requirements, and the postmarket surveillance integration layer all require regulatory expertise that general IT security firms or internal engineers without that background rarely have. Blue Goat Cyber has navigated this process across a wide range of device categories and submission types, and that depth of experience translates directly into fewer deficiencies and faster clearance.
Get SBOM compliance right from the start
The FDA mandate is real and actively enforced. An incomplete or missing software bill of materials will stall a submission. The core requirements are clear: NTIA baseline fields, FDA-specific lifecycle and vulnerability additions, machine-readable formats in SPDX or CycloneDX, and ongoing maintenance after clearance. None of these can be assembled at the last minute without risk.
Manufacturers who build medical device SBOM generation into their development lifecycle from the start, rather than treating it as a documentation task at submission time, move through premarket review faster and have a defensible postmarket surveillance process in place from day one. That’s a meaningful operational advantage over teams that bolt compliance on at the end.
If your team is preparing a premarket submission, responding to a cybersecurity deficiency, or building a postmarket maintenance program for a cleared device, Blue Goat Cyber can handle the full process.