FDA SBOM Requirements for Medical Devices
Post Summary
The FDA now requires medical device manufacturers to include a Software Bill of Materials (SBOM) in premarket submissions. An SBOM is a detailed inventory of all software components in a device, including third-party and open-source software. This helps identify and mitigate cybersecurity risks, especially for devices connected to the internet.
Key points:
- SBOM Mandate: Enforced since March 29, 2023, for "cyber devices."
- Submission Pathways: Applies to 510(k), PMA, De Novo, and HDE submissions.
- Required Details: Must include supplier names, component versions, dependencies, and lifecycle metadata.
- Accepted Formats: CycloneDX, SPDX, or SWID Tags (machine-readable).
- Non-Compliance: Submissions missing an SBOM face rejection.
Maintaining and updating the SBOM post-submission is critical. This includes monitoring vulnerabilities, tracking software lifecycle changes, and ensuring alignment with FDA’s cybersecurity guidance. Tools like CycloneDX or automated platforms can simplify compliance and streamline updates.
Webinar: Managing Compliance with the FDA's SBOM Requirements
sbb-itb-535baee
Medical Devices and Submissions Covered by FDA SBOM Requirements
This section breaks down which medical devices and submission types are impacted by the FDA's SBOM mandate.
What Qualifies as a Cyber Device
Not every medical device falls under the FDA's SBOM requirements - only those classified as a "cyber device" under Section 524B(c) of the FD&C Act. According to the FDA, a device is considered a cyber device if it meets all three of the following criteria:
- Includes software that is validated, installed, or authorized by the sponsor, whether it's part of or embedded in the device.
- Connects to the internet - either directly or through another system or network.
- Has technological features that could make it vulnerable to cybersecurity risks [1][5].
The FDA takes a broad view of what constitutes "internet connectivity." This can include Wi-Fi, Ethernet, Bluetooth, or even a USB port [7][2]. A helpful rule of thumb is:
"If your device has software and a network interface, assume Section 524B applies." - Blue Goat Cyber [7]
Devices that often fall into this category include infusion pumps, cardiac monitors, MRI and CT imaging machines, connected glucose monitors, wearables, and Software as a Medical Device (SaMD). If a manufacturer is uncertain about their product's classification, it's best to consult the FDA for guidance before submitting [1][2].
Submission Pathways Requiring an SBOM
The SBOM mandate applies to all major premarket submission pathways for cyber devices. The table below outlines the covered pathways, including whether supplements and modifications are included:
| Submission Type | Covers Supplements/Modifications? |
|---|---|
| 510(k) (Traditional, Special, Abbreviated) | Yes |
| PMA (Premarket Approval Application) | Yes - including PMA supplements |
| De Novo (Automatic Class III Designation) | N/A - new classification pathway |
| HDE (Humanitarian Device Exemption) | Yes - including HDE supplements |
| PDP (Product Development Protocol) | Yes |
It's important to note that the SBOM requirement is not retroactive. Devices authorized before March 29, 2023, are not automatically subject to this rule. However, if an authorized cyber device undergoes a change that requires a new premarket submission, it must comply with the SBOM requirements [1][4].
For 510(k) submissions, the FDA's eSTAR electronic template - mandatory for all 510(k) submissions as of October 1, 2023 - includes a specific Cybersecurity section. Missing or incomplete SBOMs will result in a Technical Screening hold, delaying the review process [1].
Key Elements of an FDA-Compliant SBOM
FDA SBOM Accepted Formats: CycloneDX vs SPDX vs SWID Tags
Required SBOM Data Fields
The FDA uses NTIA's Minimum Elements as the baseline for every software component listed in an SBOM. These fields ensure consistency and completeness. Here's a breakdown of what must be included:
| NTIA Minimum Element | Description | Example |
|---|---|---|
| Supplier Name | The organization responsible for creating or identifying the component | "Apache Software Foundation" |
| Component Name | The commonly recognized name of the software or library | "log4j-core" |
| Version String | The specific version or release identifier | "2.17.1" |
| Unique Identifier | A globally unique ID like a PURL or CPE | "pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1" |
| Dependency Relationship | The connection between components | "log4j-core depends on log4j-api" |
| SBOM Author | The entity responsible for generating the SBOM | "Acme Medical Devices" |
| Timestamp | The date and time when the SBOM was created | "2026-05-27T10:00:00Z" |
In addition to these elements, the FDA expects manufacturers to provide lifecycle metadata for each component. This includes details like whether the component is actively maintained, its end-of-support date, and its end-of-life date. Known vulnerabilities (CVEs) must also be documented and cross-referenced with CISA's Known Exploited Vulnerabilities (KEV) Catalog [6].
Documenting Software Scope and Dependencies
Under Section 524B of the FD&C Act, manufacturers must account for all software components, whether commercial, open-source, off-the-shelf (OTS), proprietary, or firmware-based [1]. This comprehensive inventory is critical because even minor omissions can create cybersecurity risks.
A common pitfall in submissions is neglecting transitive dependencies - those "hidden" libraries that third-party components rely on. These nested dependencies can harbor vulnerabilities that go unnoticed without thorough documentation. To tackle this, automated tools integrated into the CI/CD pipeline are essential for mapping out complete dependency trees before submission [6].
The SBOM must also go beyond simple lists of components. It should explicitly outline relationships, such as "Component A depends on Component B." This level of detail provides the traceability needed for accurate risk assessment [6].
"The FDA's 2025 guidance explicitly calls for 'traceability between the threat model, cybersecurity risk assessment, SBOM, and testing documentation.'" - MedDeviceGuide [6]
If lifecycle or support information for an open-source component isn't available, don't leave the field blank. Instead, include a written explanation of how risks associated with that component are being managed. This proactive approach can prevent unnecessary delays during the regulatory review process.
Machine-Readable Formats and Metadata
The FDA requires SBOMs to be submitted in machine-readable formats, ensuring compatibility with automated analysis tools and vulnerability management systems [2].
| Format | Primary Focus | VEX Support | FDA Acceptance |
|---|---|---|---|
| CycloneDX | Focused on security and vulnerability tracking | Built-in support | Accepted (Recommended) |
| SPDX | Centered on license compliance and transparency | Requires separate VEX profile | Accepted |
| SWID Tags | Designed for IT asset management | Not supported | Accepted (Supplemental) |
For medical device submissions, CycloneDX is the preferred format due to its native support for Vulnerability Exploitability eXchange (VEX) files. VEX files clarify whether a known vulnerability is actually exploitable within the device's specific configuration [6]. While SPDX is another acceptable option, it requires extra steps to integrate VEX, making it less streamlined for this purpose.
"FDA anticipates SBOMs to be produced and delivered in a machine-readable form. This enables it to be analyzed automatically and be more readily integrated with vulnerability management tools." - Qualysec [2]
Regardless of the format chosen, an SBOM must include all NTIA minimum fields, an accurate timestamp, and the SBOM author. Missing any of these elements could result in a "Refuse to Accept" (RTA) ruling or a Technical Screening hold in the eSTAR system - a regulatory authority the FDA has exercised since October 1, 2023 [6].
How to Build and Validate an SBOM
Building the SBOM
Creating an SBOM starts with a detailed inventory of your software. This involves scanning all source code, binaries, containers, and build environments. The inventory should capture every component, including top-level and nested dependencies, firmware, Software of Unknown Provenance (SOUP), and commercial off-the-shelf (COTS) software.
Once you’ve compiled this inventory, cross-check each component with the National Vulnerability Database (NVD) and CISA's Known Exploited Vulnerabilities (KEV) Catalog. This helps assess how vulnerabilities might affect your device. Afterward, export the inventory into a machine-readable format like CycloneDX or SPDX. Be sure to include lifecycle details, such as whether a component is actively supported, considered legacy, or has reached its End-of-Life (EOL). Finally, package everything: combine the machine-readable SBOM with a human-readable summary and, if applicable, VEX documentation. Submit these materials in the eSTAR cybersecurity section.
For hardware-based devices, where source code for firmware or third-party binaries may not be accessible, binary analysis tools can help. These tools use signature matching and hash comparison to identify components, meeting the FDA’s traceability requirements.
Once the SBOM is complete, the next step is validation to ensure compliance with all relevant regulations.
Validation and Consistency Checks
Validation is just as critical as building the SBOM. Start by confirming that the SBOM meets the NTIA’s minimum requirements. This means verifying that all seven essential fields - supplier name, component name, version, unique identifier, dependency relationship, SBOM author, and timestamp - are accurate and complete. Additionally, ensure that Package URLs (PURLs) or CPE identifiers are correct, as vulnerability scanners depend on these identifiers to pull accurate data from sources like the NVD and CISA KEV Catalog. Errors here could result in missed vulnerabilities.
FDA reviewers also look for consistency across documents. Your SBOM must align with related files such as the Software Architecture Design (SAD), Threat Model, and Risk Management File. Any inconsistencies could lead to a Technical Screening hold in eSTAR. To test readiness, conduct a "new CVE" drill to ensure your SBOM and processes can quickly respond to emerging vulnerabilities.
"An SBOM that is generated once for regulatory submission and then filed away provides compliance but not security." - Sakara Digital [8]
To maintain ongoing accuracy, integrate SBOM generation into your CI/CD pipeline. Each new build should produce an updated SBOM that reflects the latest software release. Cryptographic hashes should also be applied to each component to detect unauthorized changes. For healthcare organizations, tools like Censinet RiskOps™ can simplify this process by combining SBOM monitoring with broader risk management workflows.
Choosing the Right SBOM Format
The FDA accepts several machine-readable SBOM formats, including CycloneDX, SPDX, and SWID Tags, but the choice of format can affect your workflow. CycloneDX is often preferred for medical device submissions due to its built-in VEX support and security-focused features. SPDX is another option, particularly for teams already using it for open-source license tracking, though VEX integration may require extra effort. SWID Tags, while useful as a supplemental format, are not recommended as a primary choice.
"We recommend the CycloneDX format. It has good tooling support and its specification is short and more developer friendly." - J. David Giese, Partner, Innolitics [9]
Whichever format you choose, ensure your tools support all NTIA-required fields and VEX integration. Commercial platforms like Snyk ($5,000–$25,000/year), FOSSA ($10,000–$40,000/year), and Synopsys Black Duck ($15,000–$50,000/year) can provide advanced features like license compliance tracking, automated VEX generation, and deeper CI/CD integration.
Managing SBOMs After Submission
Keeping the SBOM Current and Monitoring for Vulnerabilities
Managing an SBOM doesn't end once you've submitted it. Maintaining device security and meeting regulatory requirements is an ongoing responsibility.
Even after FDA clearance, SBOM management remains critical. Many devices depend on external software, which brings with it the constant risk of new vulnerabilities. With the sheer volume of vulnerabilities reported annually, manual tracking is impractical. Automated monitoring becomes essential.
One effective approach is subscribing to automated feeds like the National Vulnerability Database (NVD) and CISA's Known Exploited Vulnerabilities (KEV) Catalog. Cross-referencing these feeds with your SBOM components helps identify relevant vulnerabilities. When a new CVE is identified, a paired VEX file can document whether that vulnerability impacts your device based on its specific configuration. Tools like Censinet RiskOps™ simplify this process, helping manufacturers provide timely updates to Healthcare Delivery Organizations (HDOs).
Another critical task is tracking the End-of-Life (EOL) status of every software component listed in your SBOM. When a library or component is no longer supported by its vendor, planning its replacement ahead of time is crucial. This proactive approach prevents situations where an unfixable vulnerability forces immediate action. By maintaining this level of oversight, manufacturers can align post-market activities with premarket SBOM validation, ensuring continued FDA compliance.
Version Control and Change Management
Proper version control and change management are essential to staying compliant in the long term.
Every modification - whether it's a patch, a component replacement, or a version update - requires a new SBOM version. According to ISO 13485 Clause 7.5.9 (configuration management), all changes must go through a formal change control process before updating the SBOM. Additionally, Clause 4.2.4 (document control) mandates that each version of the SBOM includes a revision history and follows an approval workflow.
Here’s a breakdown of key ISO 13485 requirements for post-market SBOM management:
| Post-Market Activity | ISO 13485 Clause | Requirement |
|---|---|---|
| Change Control | Clause 7.5.9 | All updates or patches must trigger a new SBOM version |
| Document Control | Clause 4.2.4 | SBOMs must include revision histories and follow an approval process |
| Design Transfer | Clause 7.3.8 | The SBOM must be incorporated into the Device Master Record (DMR) |
| Post-Market Surveillance | Clause 8.2.1 | SBOM data should support vulnerability monitoring and complaint analysis |
Integrating SBOM updates with your Engineering Change Order (ECO) workflow ensures no technical changes go undocumented. Additionally, cryptographically tying each SBOM version to its corresponding software release creates a secure audit trail. For enhanced traceability, consider linking version histories not just to software releases but also to individual device serial numbers. This level of detail is increasingly expected by both FDA reviewers and HDOs.
"Every software change (version update, patch, component swap) must update the SBOM and go through change control." - MedDeviceGuide [6]
Common SBOM Compliance Gaps and How to Avoid Them
Common SBOM Deficiencies
When it comes to creating and validating Software Bill of Materials (SBOMs), there are several recurring compliance gaps that manufacturers often encounter. These issues can lead to significant delays or rejections during regulatory submissions, making it essential to address them proactively.
One major issue is incomplete dependency mapping. While many teams focus on listing direct libraries, they often overlook transitive dependencies - those deeper layers of code that modern software relies on. This is a critical gap given that over 90% of medical device software incorporates open-source components [8]. Vulnerabilities are frequently buried several layers down, making thorough mapping essential for accurate risk assessment.
Another common pitfall is submitting SBOMs in the wrong format. Submissions in formats like PDFs or spreadsheets are not acceptable, as regulatory bodies like the FDA only accept machine-readable formats such as SPDX or CycloneDX. Similarly, missing lifecycle metadata - such as End-of-Life (EOL) or End-of-Support (EOS) dates - can raise red flags. The FDA evaluates long-term risks, especially for devices with operational lifespans of 10–20 years, so this information is crucial [2][3].
A subtle but critical issue is listing raw Common Vulnerabilities and Exposures (CVEs) without providing exploitability context. Simply enumerating vulnerabilities isn’t enough; manufacturers need to include Vulnerability Exploitability eXchange (VEX) data to explain the actual risk posed by each vulnerability.
"The FDA has explicit authority to refuse any submission it considers deficient in cybersecurity content." - Christian Espinosa, CEO, Blue Goat Cyber [7]
The table below highlights some of the most frequent gaps, their consequences, and how to address them:
| Common Deficiency | Impact on Submission | Recommended Fix |
|---|---|---|
| Missing transitive dependencies | Incomplete risk assessment; deficiency letters | Use automated tools (e.g., Syft, CycloneDX) for deep dependency mapping [7][8] |
| PDF or spreadsheet format | Refuse to Accept (RTA) hold | Submit in SPDX or CycloneDX (JSON/XML) [7] |
| Missing EOL/EOS dates | Delayed review; long-term risk concerns | Include lifecycle metadata for every component [2][3] |
| Raw CVE list without VEX | Deficiency letters; review delays | Provide VEX files to explain exploitability context [10] |
| SBOM inconsistent with other documents | Credibility issues with reviewers | Cross-check against architecture diagrams and risk assessments [2][3] |
These challenges underscore the importance of a thorough and methodical approach to SBOM preparation. Addressing these issues early can save manufacturers from delays and compliance headaches.
Best Practices for SBOM Compliance
To address these gaps effectively, automation and rigorous validation are key. Automating SBOM generation ensures accuracy and consistency, especially as software components evolve. Manual processes are prone to errors and often fail to keep up with changes between builds. Tools like Syft or Trivy can automatically generate SBOMs during the build process, capturing the exact components used and cryptographically linking the SBOM to a specific software release [3][8].
For older or closed-source components, binary analysis tools can help uncover hidden dependencies and vulnerabilities that might otherwise go unnoticed.
"An SBOM that is generated once for regulatory submission and then filed away provides compliance but not security." - Amie Harpe, Sakara Digital [8]
Including VEX documentation alongside your SBOM is becoming increasingly important. For example, in March 2026, a SaMD manufacturer used a CycloneDX SBOM to identify a hidden transitive dependency vulnerable to Remote Code Execution, avoiding an RTA ruling. This case highlights the practical value of pairing SBOMs with exploitability context from the outset.
Additionally, ensure that your SBOM aligns with other submission documents, such as software architecture diagrams, threat models, and ISO 14971 risk assessments. Any discrepancies can draw extra scrutiny from FDA reviewers [2][3].
To streamline the process further, consider integrating SBOM management into a broader risk management platform. For instance, tools like Censinet RiskOps™ (https://censinet.com) can consolidate SBOM data with other cybersecurity assessments, offering a unified approach to both regulatory and security requirements.
Conclusion: Meeting FDA SBOM Requirements
Staying compliant with the FDA's SBOM requirements is not a one-and-done task - it’s an ongoing commitment that spans the entire lifecycle of a medical device. Since October 1, 2023, the FDA has had the authority to issue "Refuse to Accept" rulings for submissions that lack proper cybersecurity documentation[4][6]. With modern medical device software relying on 75% or more external components, ensuring your SBOM is accurate and complete has never been more critical[6].
To meet these requirements, focus on the basics: confirm your device qualifies as a "cyber device", maintain a full inventory of dependencies, use machine-readable formats like CycloneDX or SPDX, and include VEX documentation to provide vulnerability context. Additionally, integrate your SBOM into your ISO 13485 configuration management process and Design History File. This ensures your documentation will withstand FDA scrutiny and supports both premarket and postmarket compliance[6].
"SBOM is not a document that is created once and never updated again as a compliance document, but as an element of a bigger, more comprehensive cybersecurity strategy." - Pabitra Kumar Sahoo, Qualysec[2]
Compliance doesn't stop at submission. To maintain long-term adherence, automate SBOM updates with every software build, continuously monitor the National Vulnerability Database (NVD) and CISA's Known Exploited Vulnerabilities (KEV) catalog, and track end-of-support timelines for every component across the device’s 10–15 year lifecycle[6]. Tools like Censinet RiskOps™ (https://censinet.com) can simplify this process by centralizing SBOM data and integrating it into broader cybersecurity workflows, reducing the operational strain of ongoing compliance.
While the FDA's requirements are tightening, international standards are also advancing. The EU Cyber Resilience Act (CRA), for example, will mandate SBOMs for all products with digital elements by December 11, 2027. This highlights that software transparency is no longer just an FDA issue - it’s becoming a global expectation[3][6]. Starting early, automating processes, and treating your SBOM as a dynamic security tool rather than a static document can help you avoid costly delays and stay ahead of evolving regulations.
FAQs
Does my device count as a “cyber device” under FDA rules?
A device falls under the category of a cyber device if it meets these three criteria outlined in Section 524B of the FD&C Act:
- It includes sponsor-validated software as part of its functionality.
- It has the capability to connect to the internet.
- It contains technological features that could be vulnerable to cybersecurity threats.
If you're uncertain about whether your device qualifies as a cyber device, it's a good idea to reach out to the FDA for clarification.
For those navigating compliance challenges, platforms like Censinet's RiskOps can offer valuable support in managing and addressing associated risks.
What’s the fastest way to generate an FDA-ready SBOM with full dependencies?
The fastest and most dependable method to generate an FDA-ready SBOM with all dependencies is to automate the process within your CI/CD pipeline. Tools such as Syft, Trivy, or Snyk can accurately identify software components and their dependencies in the final binary.
Make sure the SBOM is in a machine-readable format, like SPDX or CycloneDX, and incorporates the NTIA's minimum required elements. These include details such as the supplier name, component version, and dependency relationships to meet compliance standards.
How do I keep my SBOM updated after FDA clearance?
Keeping your SBOM up-to-date is essential. Think of it as a living document that evolves with every software release, not as a static snapshot. Whenever components are updated or patches are applied, the SBOM should reflect those changes. By integrating SBOM generation into your CI/CD pipeline, you can create accurate, versioned inventories automatically.
Pair this with continuous vulnerability monitoring linked to your SBOMs. This approach helps you address risks proactively throughout the device's lifecycle. Tools like Censinet RiskOps can streamline and support this ongoing effort.
