Medical Device SBOMs in Pre-Market Submissions
Post Summary
SBOMs (Software Bills of Materials) are now mandatory for medical device premarket submissions. Since October 1, 2023, the FDA enforces this requirement for all "cyber devices" under Section 524B of the FD&C Act. These devices include software, connect to the internet, and are vulnerable to cybersecurity threats. Missing or incomplete SBOMs can lead to Refuse to Accept (RTA) decisions, delaying market approval.
Key Points:
- What is an SBOM? A detailed, machine-readable inventory of all software components in a device.
- Why is it required? To improve cybersecurity, prevent supply chain attacks, and protect patient safety.
- FDA Requirements: SBOMs must include supplier details, component versions, dependencies, timestamps, and vulnerability assessments. Approved formats: SPDX and CycloneDX.
- Timeline: Full enforcement began October 1, 2023. Updates to guidance are expected by June 27, 2025.
- Lifecycle Management: SBOMs must be updated regularly throughout a device's lifespan (10–15 years) with continuous vulnerability monitoring.
SBOMs help manufacturers identify risks early, comply with FDA regulations, and enhance device security. Automating SBOM creation and integrating it into risk management processes ensures compliance and reduces delays in bringing devices to market.
Webinar: FDA Expectations for SBOMs - A Deep Dive with Blue Goat Cyber
sbb-itb-535baee
FDA Requirements for SBOMs
FDA SBOM Requirements Timeline for Medical Device Submissions
What SBOMs Are and Why They're Required
The FDA has made Software Bills of Materials (SBOMs) a critical part of cybersecurity documentation for medical devices. Under Section 524B of the Federal Food, Drug, and Cosmetic (FD&C) Act - introduced through the Consolidated Appropriations Act of 2023 - the FDA now requires a detailed software inventory for every submitted cyber device [8]. This move comes in response to growing concerns about software supply chain attacks, which are expected to cost $81 billion globally by 2026 and affect 45% of organizations worldwide by 2025 [7].
"Section 524B mandates 'reasonable assurance of cybersecurity' for software-enabled medical devices, and requires Software Bills of Materials (SBOMs), secure product development frameworks (SPDFs), and postmarket vulnerability monitoring." – Mike McGuire, Black Duck [7]
The FDA mandates that SBOMs include the NTIA Minimum Elements, such as supplier name, component name, version, unique identifier (like a Package URL or CPE), dependency relationships, SBOM author, and timestamp [1]. These SBOMs must be submitted in machine-readable formats like SPDX or CycloneDX, enabling automated vulnerability assessments [1].
Let’s dive into how the FDA defines and evaluates cyber devices under these new requirements.
FDA Guidelines for Cyber Devices
A device is categorized as a "cyber device" under Section 524B if it meets the following criteria:
- Includes software validated, installed, or authorized by the sponsor
- Connects to the internet, directly or indirectly
- Has technological features that could be exploited by cybersecurity threats [8]
This broad definition applies to a variety of devices, from cloud-based Software as a Medical Device (SaMD) to wireless infusion pumps. It underscores the importance of comprehensive SBOMs to ensure device security.
The requirement for SBOMs spans all major premarket submission pathways, including:
- 510(k) (Traditional, Special, and Abbreviated)
- Premarket Approval (PMA)
- De Novo classification requests
- Humanitarian Device Exemption (HDE)
- Product Development Protocol (PDP) submissions [8]
The FDA’s guidance document, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, provides detailed expectations for these submissions [9]. While FDA guidance is technically non-binding, the agency has the authority to "Refuse to Accept" (RTA) submissions that fail to meet the requirements outlined in Section 524B [8].
"The FDA may refuse to accept premarket submissions that do not provide adequate SBOM and related cybersecurity information." – sbomify [1]
For 510(k) submissions specifically, the eSTAR electronic template includes a dedicated Cybersecurity section. If SBOM attachments are missing or incomplete, the system automatically places the submission on technical hold [8].
Below is a timeline highlighting the key regulatory milestones manufacturers must adhere to.
Key Dates and Enforcement Timeline
The timeline for implementing Section 524B requirements includes several critical milestones:
| Date | Milestone | Significance |
|---|---|---|
| March 29, 2023 | Section 524B Effective Date | Cybersecurity requirements officially became law for all new premarket submissions [8]. |
| September 2023 | Final Guidance Issued | FDA released Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions [1]. |
| October 1, 2023 | Full Enforcement & eSTAR | Submissions missing cybersecurity documentation are now rejected; mandatory eSTAR use for 510(k)s began [8]. |
| June 27, 2025 | Guidance Refresh | FDA plans to update guidance, further refining SBOM expectations [1]. |
In early 2026, a healthcare technology company preparing a 510(k) submission for a cloud-connected SaMD used a CycloneDX SBOM to conduct a thorough vulnerability assessment. By analyzing transitive dependencies - essentially the "software within the software" - the team discovered a critical vulnerability in an obscure library used for diagnostic data processing. This allowed them to file a Vulnerability Exploitability eXchange (VEX) report and fix the issue before submission. As a result, they avoided an RTA ruling from the FDA [3]. This example highlights how detailed SBOM documentation can help manufacturers meet premarket submission requirements while addressing potential risks.
Required Components of an SBOM
NTIA Minimum Elements and FDA Expectations
The FDA mandates that every SBOM (Software Bill of Materials) include the NTIA Minimum Elements. These elements serve as a core set of data points to promote transparency within the software supply chain. At a minimum, an SBOM must include:
- Supplier name
- Component name
- Version string
- Unique identifier (e.g., Package URL or CPE)
- Dependency relationships between components
- SBOM author
- Timestamp marking when the SBOM was created
In addition to these basics, the FDA expects manufacturers to include lifecycle metadata for each software component. This involves specifying the level of support (e.g., actively maintained, legacy, or abandoned) and the end-of-support date, which signals when security patches will no longer be provided. For open-source software without clear support timelines, manufacturers should analyze factors like commit history or community activity to infer the component's status and explain any gaps in support information.
The SBOM must also incorporate a vulnerability assessment. This assessment should identify known vulnerabilities using sources such as CISA's KEV Catalog, detail how vulnerabilities were discovered, assess their impact, and describe any mitigations or controls in place. This detailed approach helps inform both vulnerability scans and risk management efforts.
"The FDA guidance recommends providing a machine-readable SBOM consistent with the minimum elements identified in NTIA's Framing Software Component Transparency, plus additional lifecycle properties." – Viktor Petersson, CEO, sbomify
Documenting Software Components
Expanding on the NTIA Minimum Elements, it's essential to document every software component, including transitive dependencies - those libraries automatically included by other libraries. This ensures a complete and accurate inventory. An audit conducted in 2025 revealed that 64% of open-source components in commercial codebases were transitive dependencies, often overlooked in manual reviews [5].
To ensure accuracy, manufacturers should integrate SBOM creation into their CI/CD pipeline. This ensures the SBOM reflects the actual build being submitted, rather than an outdated snapshot. Additionally, all identifiers must match those listed in the NTIA Minimum Elements to avoid naming conflicts and ensure precise mapping of components to known vulnerabilities.
Once all components are documented, format the SBOM according to FDA standards.
Machine-Readable Formats and Submission Guidelines
After cataloging all necessary details, convert the SBOM into a machine-readable format approved by the FDA. The two accepted formats are:
- SPDX (Software Package Data Exchange)
- CycloneDX
While both formats are valid, CycloneDX is often preferred for medical devices due to its focus on security and ease of use for developers. Regardless of the format chosen, the SBOM must comply with the NTIA Minimum Elements and include the FDA's additional lifecycle metadata.
Submissions should be integrated into the FDA's eSTAR template, which has a section specifically for "Risk Management - Software Bill of Materials (SBOM) and Related Information." While machine-readable files (e.g., JSON or XML) are mandatory for automated scanning, it’s highly recommended to include a human-readable version (e.g., PDF or Excel) to facilitate the review process.
"Include both a human-readable and machine-readable version of your SBOMs in your regulatory submissions. JSON doesn't cut it [for reviewers]." – J. David Giese, Partner, Innolitics
Before submission, validate the SBOM file using tools like cyclonedx-cli or SPDX validators to ensure its structure is correct. Since October 1, 2023, the FDA has had the authority to issue "Refuse to Accept" (RTA) decisions for submissions missing complete SBOM data. Ensuring your SBOM is thorough, accurate, and properly formatted can help avoid unnecessary delays.
How to Prepare an SBOM for Premarket Submission
To align with FDA guidelines, here’s a breakdown of how to prepare your SBOM (Software Bill of Materials) for premarket submission.
Inventorying and Mapping Software Components
Start by determining if your device qualifies as a "cyber device" under FDA regulations. If it includes software and has any connectivity - like USB ports, Bluetooth, Wi-Fi, or internet access - it falls under this category and requires an SBOM [4][2]. Once confirmed, you’ll need to document four key layers of dependencies:
- Language-level libraries: Examples include TensorFlow or React.
- Transitive dependencies: Libraries automatically included by other libraries.
- System dependencies: Such as the Python runtime or Linux kernel.
- Operating system: The OS itself.
To avoid "documentation drift", use automated tools integrated into your CI/CD pipeline. However, manual verification is essential to catch items that automated scanners might miss, like embedded binaries, custom integrations, or build-environment packages [4][5][1].
Your SBOM should also connect directly to your device’s security architecture. This means linking it to data flow diagrams, threat models, and security architecture overviews [10][1]. Creating SBOMs early in the development process can help you identify unsupported or high-risk dependencies before they become a problem [4].
Once your components are mapped, the next step is to evaluate their vulnerabilities.
Assessing Vulnerabilities and Mitigating Risks
With your inventory in hand, you’ll need to verify the security of each component. Cross-check components against resources like the National Vulnerability Database (NVD) and CISA's Known Exploited Vulnerabilities (KEV) Catalog [2][6]. Tools like Common Platform Enumeration (CPE) or Package URL (PURL) can help ensure accurate matches and reduce false positives [1][6]. Use scoring systems like the Common Vulnerability Scoring System (CVSS) for severity and the Exploitability Prediction Scoring System (EPSS) for likelihood of exploitation [6].
For every vulnerability you identify, document its potential impact on device safety, clinical performance, and patient outcomes [2][5]. When submitting to the FDA, explain your vulnerability assessment process to show it meets their "sufficiently robust" standard [2]. If a vulnerability can’t be patched, provide either compensating controls or a justification for why the risk is acceptable [2][6]. You can also include Vulnerability Exploitability eXchange (VEX) statements to clarify whether a known vulnerability is exploitable in your device’s specific context [2].
After completing the vulnerability assessment, organize your findings into the required formats for submission.
Organizing and Submitting SBOM Documentation
Prepare your SBOM in both machine-readable formats (like JSON or XML using SPDX or CycloneDX) and human-readable formats (such as PDF or Excel) [4][5].
"Include both a human-readable and machine-readable version of your SBOMs in your regulatory submissions. JSON doesn't cut it [for reviewers]." – J. David Giese, Partner, Innolitics
Use the FDA’s eSTAR template, which includes a section for "Risk Management - Software Bill of Materials (SBOM) and Related Information" [4][5]. Add a plain-language memo explaining how the SBOM was created, how it’s maintained, and your process for handling vulnerabilities [5]. Include build metadata like the git hash of the source code and a precise generation timestamp to improve auditability [4]. Keep in mind that starting October 1, 2025, the FDA may issue "Refuse to Accept" (RTA) decisions for cyber-device submissions missing required SBOM data [5].
Postmarket Monitoring and SBOM Lifecycle Management
Getting FDA clearance is just the beginning; your SBOM (Software Bill of Materials) needs to keep up with your device over its 10–15 year lifecycle [1]. The FDA expects manufacturers to treat SBOMs as living documents, updated regularly, rather than as one-time compliance artifacts [1].
Continuous Vulnerability Monitoring
Manually updating SBOMs simply doesn’t scale. To keep your software composition current, integrate SBOM generation into your CI/CD pipeline [4]. This ensures that every build reflects the latest data, providing an accurate snapshot of your software components.
Automating the process is key. Regularly cross-reference your SBOM components with resources like the NVD (National Vulnerability Database) and CISA’s KEV (Known Exploited Vulnerabilities) catalog [6]. When new vulnerabilities surface, evaluate them using tools like CVSS for severity, EPSS for exploit likelihood, and the KEV list for active threats [6]. Focus on vulnerabilities that could directly impact patient safety or device performance.
To avoid unnecessary alarms, use VEX (Vulnerability Exploitability eXchange) statements. These clarify whether a specific CVE (Common Vulnerabilities and Exposures) actually affects your device in its unique configuration [2]. This saves healthcare organizations from wasting time on false-positive investigations.
With vulnerabilities under constant review, the next step is ensuring timely and transparent communication with all stakeholders.
Communicating Vulnerabilities to Stakeholders
Once vulnerabilities are identified, effective communication is critical. The FDA has emphasized that simply emailing SBOMs on request isn’t enough. As one FDA Lead Cybersecurity Specialist put it:
"While we acknowledge you have stated a user is able to request the SBOM via email, this documentation should be readily available to the end user at all times" [4].
A better approach is to create a manufacturer portal or Trust Center where healthcare providers can access real-time updates, including current SBOM versions, VEX statements, and security attestations [4].
Develop a clear Vulnerability Disclosure Policy (VDP) to outline how security issues will be communicated to stakeholders [6]. Pair your SBOM with VEX documentation to provide context around CVE exploitability, building confidence with healthcare organizations.
Additionally, ensure your SBOMs remain machine-readable. This makes it easier for healthcare providers to integrate them into their security systems [4]. Many organizations now require continuous access to SBOM and VEX data as part of their purchasing criteria [2].
Once vulnerabilities are communicated, integrate the updates into your broader risk management framework.
Integrating SBOM Updates with Risk Management
Updating your SBOM isn’t just about compliance - it’s a key part of your risk management strategy. Every SBOM update should align with your overall risk framework. For instance, when introducing new software dependencies or applying patches, document how these changes affect your security architecture views and threat models [1]. This level of traceability shows the FDA that you’re proactively managing risks tied to software changes.
Create an SBOM Support Report that tracks the status of each component (e.g., active, legacy, or abandoned) and includes End-of-Support dates [4]. This is an FDA expectation that’s often overlooked but crucial for compliance. Also, maintain detailed records of all vulnerability assessments and stakeholder communications. These audit trails are essential for demonstrating due diligence during FDA inspections or internal reviews [6].
"An SBOM is not the end goal - it is a crucial input to an ongoing cybersecurity risk management process." – Medcrypt [6]
Under Section 524B of the FD&C Act, the FDA has the authority to reject premarket submissions if they don’t include adequate plans for addressing postmarket vulnerabilities [2]. Your lifecycle management process must prove that you’re ready to identify, evaluate, and communicate security risks throughout your device’s operational life.
Conclusion and Key Takeaways
SBOMs are no longer optional for FDA premarket submissions. As of October 1, 2023, the FDA can reject submissions that lack detailed SBOM information, making them a critical component for bringing medical devices to market [2]. Beyond compliance, SBOMs play a key role in protecting patients by helping to quickly identify and address vulnerabilities.
The process of creating an SBOM should start early - during development - not as a last-minute task before submission. Automating SBOM generation within your CI/CD pipeline ensures you consistently capture all required NTIA elements, including supplier name, component name, version, unique identifiers, dependency relationships, author, and timestamp. Submissions should include machine-readable formats like CycloneDX or SPDX as well as human-readable versions for FDA reviewers [2][4]. Additionally, document the support status and end-of-support dates for each component to meet FDA-specific requirements [4].
Think of your SBOM as a living document, not just a one-time deliverable. Medical devices often remain in use for 10–15 years, so ongoing vulnerability monitoring is crucial. Use resources like the NVD and CISA's KEV catalog to stay on top of potential risks [1][2]. Pairing your SBOM with VEX statements can further clarify exploitability, helping to avoid unnecessary distractions from false alarms. This proactive approach aligns with the broader risk management practices discussed earlier.
Making your SBOM accessible also demonstrates a strong commitment to cybersecurity. With hospitals increasingly requiring SBOMs as part of their purchasing decisions, consider providing documentation through a manufacturer portal or Trust Center rather than relying on ad hoc email exchanges [4][2].
"In practice, the SBOM has moved from 'nice-to-have' to essential cybersecurity documentation for medical device submissions" [1].
Integrating SBOMs into your risk management strategy not only helps protect patients but also ensures you maintain market access.
For a more efficient approach to compliance and security, consider tools like Censinet RiskOps™. This solution simplifies SBOM management and helps you continuously address cybersecurity risks, as highlighted earlier.
FAQs
Does my device count as an FDA “cyber device” that needs an SBOM?
If your device is software-enabled and can connect to the internet, it meets the FDA's definition of a "cyber device." These devices must include a Software Bill of Materials (SBOM) in premarket submissions, such as 510(k), De Novo, PMA, PDP, and HDE filings.
How do I ensure my SBOM includes transitive and system-level dependencies?
To make sure your SBOM covers transitive and system-level dependencies, it's crucial to have a thorough inventory of all software components. This includes open source, off-the-shelf, and third-party software. Don’t stop at direct dependencies - be sure to account for transitive ones and system-level components as well.
Some effective practices include:
- Using automated tools to monitor and verify dependencies.
- Regularly updating your SBOM to keep it current.
- Ensuring the SBOM represents the entire software supply chain, which is critical for both cybersecurity and meeting regulatory requirements.
What’s the best way to keep SBOMs and VEX updated throughout the device lifecycle?
Managing SBOMs and VEX effectively means treating them as living documents. This involves consistently updating them with fresh component data, newly discovered vulnerabilities, and the latest security patches. To stay ahead of potential risks, it's crucial to implement continuous monitoring and risk assessment practices that can identify and address threats as they arise.
Automation tools, such as Censinet RiskOps™, can make this process much smoother. They help streamline updates, track vulnerabilities, and ensure alignment with FDA guidelines and established cybersecurity practices. These tools can take a lot of the manual effort out of the equation, making it easier to maintain compliance and keep your systems secure.
