SBOMs in Medical Device Labels: FDA Expectations
Post Summary
SBOMs (Software Bill of Materials) are now a core requirement for medical device manufacturers submitting to the FDA. These documents act as detailed software inventories, listing all components - proprietary, open-source, and third-party - used in a device. Since March 29, 2023, the FDA mandates SBOMs for "cyber devices" in premarket submissions (510(k), PMA, and De Novo). As of October 1, 2023, submissions lacking adequate cybersecurity details, including SBOMs, can be rejected under Section 524B of the FD&C Act.
Key updates include the FDA's June 27, 2025 guidance, which expanded SBOM requirements to include lifecycle metadata (e.g., end-of-support dates) and the use of VEX (Vulnerability Exploitability eXchange) files starting March 2026. These measures aim to improve vulnerability tracking and long-term device security.
Quick Takeaways:
- Why SBOMs Matter: Over 75% of medical device software relies on external components. SBOMs help identify and manage risks tied to these components.
- FDA Requirements: SBOMs must follow NTIA’s "Minimum Elements" and be submitted in machine-readable formats like SPDX or CycloneDX.
- Key Additions: Include known vulnerabilities, lifecycle metadata, and VEX files to clarify exploitability.
- Legal vs. Recommended: SBOMs are legally required for cyber devices but strongly encouraged for other software-based devices.
This shift ensures transparency, strengthens cybersecurity, and helps healthcare facilities manage risks over a device's 10+ year lifespan.
Webinar: FDA Expectations for SBOMs - A Deep Dive with Blue Goat Cyber
sbb-itb-535baee
FDA Requirements for SBOMs in Medical Device Labeling
FDA SBOM Requirements: Cyber Devices vs Other Software Devices Comparison
What SBOMs Are and Why They Matter
A Software Bill of Materials (SBOM) is essentially an inventory of all the software components that make up a medical device, covering everything from proprietary code to open-source libraries. This transparency is critical because modern medical devices often rely on external components for over 75% of their software, including third-party and open-source elements [2]. When a vulnerability is identified in one of these components, healthcare providers need to quickly determine which devices might be at risk.
SBOMs play a key role in managing these risks over the typical 10+ year lifespan of a medical device. Recognizing this, the FDA's June 2025 guidance requires manufacturers to include lifecycle information, such as the "Software Component Support Level" and "End-of-Support Dates" [3]. This helps hospitals prepare for potential software obsolescence and ensures they avoid using devices with unsupported, vulnerable components. Effective risk management requires measuring what matters for cybersecurity to protect patient safety. This understanding sets the stage for the FDA's specific cybersecurity labeling requirements, which are detailed in the next section.
FDA Guidance on Cybersecurity Information in Labeling
The FDA's final guidance, titled "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions" (effective June 27, 2025), makes SBOMs mandatory for cyber devices and strongly recommends them for other software-based devices [2]. The guidance builds on the NTIA Minimum Elements (July 2021), which serve as the baseline for SBOM content. These elements include details like the supplier name, component name, version string, unique identifiers (e.g., purl or CPE), dependency relationships, SBOM author, and a timestamp [2].
In addition to these baseline elements, the FDA requires manufacturers to enhance transparency by documenting known vulnerabilities (CVEs), referencing the CISA Known Exploited Vulnerabilities (KEV) Catalog, and providing details on any mitigations [2]. This level of disclosure helps healthcare facilities evaluate and address cybersecurity risks across their device inventories. Furthermore, starting in March 2026, manufacturers must include Vulnerability Exploitability eXchange (VEX) files with SBOMs. These files help determine whether identified vulnerabilities are exploitable in the specific configuration of a device [2].
"For devices that qualify as 'cyber devices,' an SBOM is legally required under Section 524B(b)[4]." - MedDeviceGuide [2]
The next section sheds light on the difference between what is legally required and what is recommended under FDA guidance.
Required vs. Recommended SBOM Practices
For devices classified as cyber devices - those containing software, connecting to a network, and exposed to cybersecurity threats - providing an SBOM is a legal obligation under Section 524B of the FD&C Act [2]. For instance, in early 2026, a healthcare technology company used CycloneDX SBOM data to address a critical vulnerability before submitting for premarket approval [2].
For other software-based devices, SBOMs are not legally required but are strongly encouraged. The FDA's guidance uses advisory language like "should", signaling that while not mandatory, following these recommendations can improve the likelihood of premarket approval [3]. Additionally, SBOMs must be in machine-readable formats - such as CycloneDX, SPDX, or SWID tags - to facilitate automated vulnerability scanning [2].
| Feature | Required (Cyber Devices) | Recommended (Other Software Devices) |
|---|---|---|
| Legal Basis | FD&C Act Section 524B | FDA Guidance (June 2025) |
| SBOM Status | Mandatory | Strongly recommended |
| Format | Machine-readable (SPDX/CycloneDX) | Machine-readable preferred |
| Vulnerability Info | Required (CVEs/Mitigations) | Recommended |
SBOM Technical Standards: NTIA Elements and Format Requirements
NTIA Minimum Elements for SBOMs
The FDA specifically highlights the NTIA's "Minimum Elements for a Software Bill of Materials" as the baseline for SBOM content in premarket submissions [1]. These seven core elements are essential for creating a complete software inventory, which healthcare facilities can use to track vulnerabilities and manage risks effectively.
| Element | Description |
|---|---|
| Supplier Name | Identifies the entity supplying the component. |
| Component Name | The name of the software component. |
| Version | The version identifier for the component. |
| Unique Identifier | Examples include Package URL (purl) or Common Platform Enumeration (CPE). |
| Dependency Relationship | Describes how the component interacts with other software elements. |
| Author of SBOM Data | Indicates who or what created the SBOM. |
| Timestamp | Records when the SBOM data was generated. |
In addition to these elements, the FDA expects manufacturers to include lifecycle metadata, such as the component's support status (active, legacy, or unsupported) and its end-of-support dates. This information is especially important for healthcare environments, where medical devices often remain operational for over a decade [1]. Including these details helps hospitals prepare for component obsolescence and reduce risks associated with outdated or unsupported software.
"FDA may refuse to accept premarket submissions that do not provide adequate SBOM and related cybersecurity information." - Viktor Petersson, CEO, Sbomify [1]
Next, let’s explore the standardized formats that make compliance more efficient.
Machine-Readable Formats: SPDX and CycloneDX
To meet FDA recommendations, SBOMs should be submitted in two standardized, machine-readable formats: SPDX (Software Package Data Exchange) and CycloneDX [1]. Both formats are fully compatible with the NTIA's minimum elements and widely accepted by regulators.
- SPDX: Developed by the Linux Foundation, this format is rooted in license compliance and open-source software management.
- CycloneDX: Known for its lightweight design, CycloneDX focuses on security and supply chain transparency.
These formats enhance automation by using unique identifiers (like Package URL or CPE) to match components with vulnerability databases such as Google OSV and Dependency Track. By integrating SBOM generation into CI/CD pipelines, manufacturers can maintain up-to-date software inventories throughout the device lifecycle [1].
Not only do these formats streamline vulnerability scanning, but they also integrate seamlessly into broader cybersecurity risk management strategies.
Why Standard Formats Matter for Healthcare Organizations
Standardized SBOM formats offer healthcare organizations a way to automate vulnerability monitoring across their entire device inventory. When new vulnerabilities arise, machine-readable SBOMs enable security tools to pinpoint affected devices quickly, eliminating the need for time-consuming manual reviews. This is particularly valuable for devices with operational lifespans exceeding 10 years, as it supports proactive planning for replacements or compensating controls near the end of a component's support period.
Using these formats also reduces the risk of premarket submission rejections by the FDA. Under Section 524B of the FD&C Act, the FDA can reject submissions for "cyber devices" that lack sufficient SBOM and cybersecurity documentation. By adopting SPDX or CycloneDX, manufacturers align with FDA expectations, improve regulatory review efficiency, and strengthen cybersecurity practices throughout the device lifecycle [1].
Connecting SBOMs with Vulnerability Assessments and Risk Management
Managing cybersecurity risks effectively goes beyond listing software components. Manufacturers need to document vulnerabilities, lifecycle data, and how these elements integrate into the overall security framework.
Documenting Known Vulnerabilities and Mitigations
An SBOM should be paired with a detailed assessment of unresolved vulnerabilities in its components [1]. This means identifying CVEs (Common Vulnerabilities and Exposures) across commercial, open-source, and off-the-shelf software, along with outlining the measures in place to reduce the risk of exploitation. These measures could include network segmentation, disabling risky features, or adding stronger authentication layers [1][5]. The FDA requires this documentation to show that vulnerabilities are addressed at the design level.
VEX (Vulnerability Exploitability eXchange) documents complement SBOMs by clarifying which CVEs pose real risks. They categorize CVEs as "Not Affected", "Affected", "Fixed", or "Under Investigation", making it easier to filter and prioritize vulnerabilities [5].
"VEX documents are machine readable. Meaning, they enable automatic generation by medical device manufacturers, seamless sharing with the FDA and hospitals, and efficient ingestion for summarizing vulnerability risk data." - Joe Mistretta, Manifest [5]
This level of documentation helps lay the groundwork for integrating risk management into the device's lifecycle and security architecture.
Providing Component Lifecycle and Support Information
Manufacturers also need to provide lifecycle metadata for every software component. This includes whether the component is actively supported, considered legacy, or no longer supported, along with its end-of-support date [1]. Additionally, sharing planned security update schedules for third-party and open-source components allows healthcare facilities to plan for risk management. This ensures they can implement compensating controls or upgrades when needed [1].
Linking SBOMs to Security Architecture and Threat Models
Once vulnerabilities are documented, manufacturers must integrate this information into the broader security framework. The FDA's June 2025 guidance emphasizes the need to link SBOMs to threat models, risk assessments, and test documentation [2]. This connection shows how each component contributes to the device's overall risk profile.
If a component has a known vulnerability, its SBOM entry should link to the threat model, demonstrating how the device's design mitigates its exploitability [1]. This traceability provides FDA reviewers with confidence that manufacturers understand how software risks impact patient safety, aligning with ISO 14971 standards [2].
"SBOMs must be traceable to security architecture views and threat models that FDA reviewers evaluate." - Viktor Petersson, CEO, Sbomify [1]
Manufacturers should also create a traceability matrix. This matrix maps each SBOM component to its respective security controls in the Security Risk Management Report [2]. This approach gives healthcare organizations the context they need to make informed decisions about deploying and monitoring medical devices.
Keeping SBOMs Current Throughout the Device Lifecycle
Keeping a Software Bill of Materials (SBOM) up-to-date is critical for effective vulnerability assessment and risk management. Since SBOMs reflect the current state of software, any change - whether it’s a patch, replacement, or update - must be promptly documented. The FDA’s guidance for June 2025 underscores the importance of treating SBOMs as "living documents" that are maintained through formal configuration management processes [2].
Updating SBOMs When Components Change
To streamline updates, integrate SBOM generation into your CI/CD pipeline. This allows for automatic creation of updated, machine-readable SBOMs with every build. Tools like Syft, Trivy, and FOSSA can scan source code and containers to simplify this process [2][6].
Each software modification should trigger an SBOM update through a structured Engineering Change Order (ECO) workflow. This ensures that technical changes are consistently linked to documentation updates. By doing so, the SBOM remains accurate and ready for vulnerability assessments whenever needed.
Sharing Updated SBOMs with Healthcare Facilities
Once updated, SBOMs must be shared promptly to help healthcare facilities maintain cybersecurity oversight. The FDA has moved away from outdated "request-by-email" methods. In August 2024, an FDA Lead Cybersecurity Specialist stated, "While we acknowledge you have stated a user is able to request the SBOM via email, SBOMs must be accessible to end users immediately" [6]. This means manufacturers should provide instant access to SBOMs, ideally through an online portal or as part of device labeling. Platforms like Censinet RiskOps™ enable secure, real-time sharing of updated SBOMs, ensuring healthcare organizations have the visibility they need.
When distributing SBOMs, manufacturers should also include Vulnerability Exploitability eXchange (VEX) files to clarify whether new vulnerabilities in components affect the device [2]. Additionally, SBOM components should be regularly cross-referenced with vulnerability databases like the National Vulnerability Database (NVD) and CISA’s Known Exploited Vulnerabilities (KEV) catalog [2].
Aligning SBOM Updates with ISO 13485 and Configuration Management
An SBOM should be treated as part of the device's configuration identity and included in the Device Master Record (DMR) during design transfer, as outlined in ISO 13485 Clause 7.3.8. Under Clause 4.2.4, SBOM versions must be managed as controlled documents with clear revision histories and approval workflows. By aligning with Clause 7.5.9 (Configuration Management), every software change can follow a controlled process [2].
Cybersecurity risks tied to SBOMs should also be a regular topic in Management Reviews (Clause 5.6), ensuring executive-level attention to supply chain vulnerabilities. Additionally, SBOMs play a key role in post-market surveillance (Clause 8.2.1), supporting automated monitoring and complaint analysis throughout the device’s lifecycle, which often spans 10–15 years [2]. Regular SBOM maintenance is essential for maintaining security and compliance in the regulated environment.
SBOM Compliance Implementation Checklist
To meet FDA requirements and ensure transparency in cybersecurity, manufacturers must create an SBOM (Software Bill of Materials) that adheres to strict regulatory and technical standards. Before submitting your medical device for FDA approval, it's critical to confirm that your SBOM is both complete and accurate. The FDA began enforcing its authority to reject submissions without an adequate SBOM on October 1, 2023 [2].
Checking SBOM Completeness and Accuracy
Your SBOM must include all minimum elements outlined by the NTIA, along with lifecycle metadata such as software support levels (active, legacy, or unsupported), end-of-support dates, and end-of-life dates [2].
A comprehensive SBOM should account for proprietary software, open-source libraries, commercial off-the-shelf (COTS) software, transitive dependencies (the "software within the software"), and embedded firmware [2]. Since most modern medical device software incorporates over 75% external components, thorough scanning is a must [2]. Automated tools like Syft, Trivy, or FOSSA, integrated into your CI/CD pipeline, can help ensure no components are overlooked [2].
Cross-check all listed components against vulnerability databases and include CVSS v4.0 scores along with mitigation plans for any vulnerabilities found [2]. Additionally, include VEX (Vulnerability Exploitability eXchange) artifacts to clarify whether identified vulnerabilities are exploitable in your device’s specific configuration. This step can help avoid deficiency letters from the FDA [2].
Lastly, ensure your SBOM adheres to the FDA’s specific guidance requirements.
Confirming Compliance with FDA Guidance
The SBOM must be in a standardized, machine-readable format like CycloneDX or SPDX and should be directly linked to your security documentation. A traceability matrix is essential - it should connect the SBOM to your device’s threat model, cybersecurity risk assessment, and security architecture, as these links are typically reviewed by the FDA [2].
Your SBOM management should align with your Quality Management System (QMS) processes. Under ISO 13485 Clause 4.2.4, SBOMs must be treated as controlled documents with clear revision histories and approval workflows [2]. Additionally, they should be included in the Device Master Record (DMR) during the design transfer phase, as specified in ISO 13485 Clause 7.3.8 [2].
Simulated vulnerability exercises are another useful practice. These exercises can help identify and address critical medical device security risks before submission, reducing the risk of receiving an FDA Refuse to Accept ruling [2].
Finally, establish a robust system for ongoing SBOM updates and version control.
Setting Up Version Control and Update Procedures
Implement a formal version control system where any software modification triggers an SBOM update through your Engineering Change Order (ECO) workflow [2]. Incorporate SBOM generation into your CI/CD pipeline to enable automatic updates with every software change [2].
Establish clear procedures for sharing updated SBOMs with healthcare facilities. Tools like Censinet RiskOps™ can facilitate secure, real-time sharing, ensuring healthcare providers have access to the latest documentation and the cybersecurity insights they need.
Each SBOM update should also be linked to your ISO 14971 risk management file. Document how changes in component versions could affect your hazard analysis. Since medical devices often remain operational for 10 to 15 years or more, maintaining strong version control and update processes is crucial for ensuring security and compliance throughout the product’s lifecycle [2].
Conclusion
SBOMs have become a required part of cybersecurity documentation for medical device manufacturers. This shift promotes greater transparency, allowing healthcare organizations to evaluate risks before purchasing devices, stay informed about new vulnerabilities, and plan updates over a device's 10- to 15-year lifespan [2]. These changes set a standard for informed, transparent cybersecurity practices throughout the lifecycle of medical devices.
The FDA mandates that SBOMs include the NTIA Minimum Elements - such as Supplier Name, Component Name, Version, Unique Identifier, Dependency Relationship, Author, and Timestamp - in machine-readable formats like CycloneDX or SPDX. With over 75% of modern medical device software sourced externally, manufacturers should use automated tools in their CI/CD pipelines to ensure all dependencies are accounted for. Additionally, the FDA increasingly looks for Vulnerability Exploitability eXchange (VEX) artifacts to clarify whether identified vulnerabilities are exploitable in a device's specific setup [2].
"The SBOM has moved from 'nice-to-have' to essential cybersecurity documentation for medical device submissions."
– Viktor Petersson, Sbomify [1]
Each software update must prompt an SBOM revision, with every update tied to the ISO 14971 risk management file and the ISO 13485 configuration management process [2]. This approach not only satisfies FDA requirements but also simplifies the process of addressing evolving cybersecurity threats. For healthcare providers, accurate and regularly updated SBOMs are critical to safeguarding patient safety and ensuring uninterrupted clinical operations. Tools like Censinet RiskOps™ support real-time access to updated SBOM data, providing healthcare organizations with the insights they need to stay secure.
In 2026, a healthcare technology company successfully avoided a potential FDA rejection by using CycloneDX SBOM data to identify and fix a major vulnerability before submission [2]. This example highlights how strong SBOM practices not only meet regulatory expectations but also help stakeholders make better decisions about device security and patient safety.
FAQs
Does my device count as an FDA “cyber device” under Section 524B?
Your device qualifies as an FDA "cyber device" under Section 524B if it includes software that has been validated, installed, or authorized by the sponsor and has the capability to connect to the internet or other networks. This connectivity exposes the device to potential cybersecurity risks.
What’s the easiest way to keep an SBOM updated after every software change?
Keeping a Software Bill of Materials (SBOM) up-to-date is simplest with automated tools that sync with the device's development and deployment processes. These tools can automatically create and refresh SBOMs in machine-readable formats like SPDX or CycloneDX, ensuring they always capture the most current software components, versions, and vulnerabilities. This method not only reduces manual work but also aligns with FDA guidelines for maintaining cybersecurity transparency.
How should VEX files be used with SBOMs for FDA submissions?
Combining VEX files with SBOMs in a machine-readable format, such as SPDX or CycloneDX, enhances clarity and functionality. This approach boosts transparency, facilitates better vulnerability management, and helps meet FDA cybersecurity labeling and risk assessment requirements.
