Ultimate Guide to SBOMs for FDA-Regulated Devices
Post Summary
SBOMs (Software Bill of Materials) are now a must-have for FDA-regulated medical devices. Since March 29, 2023, manufacturers must include SBOMs in premarket submissions for "cyber devices." These inventories detail every software component, from third-party libraries to proprietary code, ensuring transparency and security. Starting October 1, 2025, submissions missing SBOMs risk rejection, delaying product approvals.
Key Takeaways:
- What is an SBOM? A machine-readable list of all software components in a device, like an "ingredient label" for software.
- Why it matters: SBOMs help identify medical device security risks, and comply with FDA cybersecurity requirements.
- FDA compliance: SBOMs must follow NTIA's minimum elements (e.g., supplier name, version, dependencies) and include lifecycle details like support levels and vulnerability management.
- Timeline: FDA began requiring SBOMs in March 2023, with stricter enforcement starting October 2025.
- Best practices: Automate SBOM creation using tools like SPDX or CycloneDX, integrate updates into CI/CD pipelines, and maintain documentation throughout the device lifecycle.
SBOMs are no longer optional - they’re critical for securing medical devices and meeting FDA standards.
Webinar: Managing Compliance with the FDA's SBOM Requirements
FDA SBOM Requirements: What You Need to Know
FDA SBOM Requirements Timeline and Compliance Deadlines for Medical Devices
The FDA's requirements for Software Bill of Materials (SBOM) are rooted in federal law and can impact the timeline for market clearance. To avoid delays or rejections, it's essential to understand the legal framework and determine which devices fall under this mandate. This framework forms the foundation for the SBOM requirements discussed later.
Section 524B of the FD&C Act Explained
Section 524B of the Federal Food, Drug, and Cosmetic (FD&C) Act mandates including cybersecurity details - like SBOMs - in premarket submissions. This section, introduced via the 2023 Consolidated Appropriations Act, officially took effect on March 29, 2023 [5].
The rule applies to several submission types, including 510(k), PMA, De Novo, HDE, and PDP pathways. For any "cyber device" submitted through these channels, a machine-readable SBOM listing all software components must be provided [5].
The grace period for compliance ended on October 1, 2023. After this date, submissions missing complete SBOM documentation risk rejection [5][6].
"Beginning October 1, 2023, the FDA expects that sponsors of cyber devices will have had sufficient time to prepare premarket submissions that contain information required by section 524B of the FD&C Act." – FDA [5]
On June 27, 2025, the FDA released updated guidance titled "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions." This document clarified the required content and format for SBOMs. For submissions through the 510(k) pathway, manufacturers must use the eSTAR electronic template. Missing attachments or inaccurate responses in the cybersecurity section of this template can result in a technical screening hold [5].
Which Devices Must Include SBOMs
Knowing which devices qualify as "cyber devices" is key to complying with this requirement.
Not all medical devices need an SBOM. Only those meeting the "cyber device" criteria outlined in Section 524B are subject to this mandate. A device qualifies if it meets these three conditions:
- Software Use: The device includes validated software installed or authorized by the sponsor.
- Internet Connectivity: It can connect to the internet, either directly or indirectly.
- Cybersecurity Risks: The device has features that make it susceptible to cyber threats.
Devices without software or internet connectivity are generally excluded from this rule [5].
Products submitted before March 29, 2023, are grandfathered under the previous rules unless they are modified [5].
If you're unsure whether your device qualifies as a cyber device, the FDA advises reaching out for clarification before submitting your application. Misclassifying your product could lead to delays in market approval.
Required Elements in FDA-Compliant SBOMs
The FDA points to the NTIA Minimum Elements as the core framework for creating SBOMs (Software Bill of Materials) in premarket submissions. These seven key attributes form what the NTIA describes as a "minimum viable SBOM", balancing practical use for manufacturers with the technical requirements needed to ensure traceability throughout the software supply chain.
However, the FDA goes beyond the NTIA guidelines by requiring additional lifecycle and vulnerability details. This is particularly important for medical devices, which often remain in operation for over a decade. Such extended information is vital for maintaining safety in healthcare environments [7].
NTIA Baseline Attributes
To meet FDA standards, every SBOM must include seven foundational attributes for each software component. Here's a breakdown of these attributes and their role in compliance:
- Supplier Name: Identifies the organization behind the component, helping trace the origin of third-party risks.
- Component Name: Specifies the name assigned by the supplier, aiding in inventory control and vulnerability tracking.
- Version: Indicates the specific software version, crucial for distinguishing between updated and vulnerable code.
- Unique Identifiers: Uses keys like purl or CPE to automate cross-referencing with vulnerability databases.
- Dependency Relationship: Maps how components interact, showing how vulnerabilities in one part can affect the entire device.
- Author of SBOM Data: Establishes responsibility for the accuracy and reliability of the SBOM details.
- Timestamp: Marks when the SBOM was created, ensuring it reflects the software's current state.
| NTIA Baseline Attribute | Description | Importance for FDA Compliance |
|---|---|---|
| Supplier Name | Entity that creates/defines the component | Identifies the origin of third-party risk |
| Component Name | Designation assigned by the supplier | Essential for inventory and vulnerability matching |
| Version | Identifier for a specific software change | Distinguishes between patched and vulnerable code |
| Unique Identifiers | Lookup keys like purl or CPE | Enables automated cross-referencing with CVE databases |
| Dependency Relationship | How components relate to each other | Maps the impact of upstream vulnerabilities on the device |
| Author of SBOM Data | Entity that created the SBOM record | Establishes accountability for the data's accuracy |
| Timestamp | Date/time of SBOM assembly | Ensures the SBOM reflects the current build version |
These elements form the foundation, but the FDA also requires additional details to address lifecycle management and risk evaluation.
FDA-Specific SBOM Requirements
The FDA's expectations go further by requiring documentation of the Software Component Support Level for each component. This includes classifying the support as active/full, security-fixes-only (legacy), or unsupported/abandoned. Additionally, manufacturers must specify the End-of-Support (EOS) Date, which marks when the supplier will stop providing updates.
Another critical requirement is a detailed vulnerability assessment. This involves identifying known vulnerabilities (using resources like CISA's Known Exploited Vulnerabilities (KEV) Catalog), describing how vulnerabilities were discovered (e.g., automated tools, manual checks, or penetration testing), and explaining their potential impact on device safety and performance. For each vulnerability, manufacturers must outline the mitigation or compensating controls implemented to address the issue.
"The SBOM has moved from 'nice-to-have' to essential cybersecurity documentation for medical device submissions." – Viktor Petersson, CEO, Sbomify
When dealing with open-source components that lack clear end-of-support dates, manufacturers are advised to infer support status based on commit history or registry updates. If exact dates are unavailable, they must provide a justification to the FDA.
sbb-itb-535baee
How to Create and Manage FDA-Compliant SBOMs
To create an FDA-compliant Software Bill of Materials (SBOM), start by building a comprehensive software inventory. This means listing every software component in your device, including commercial off-the-shelf (COTS) products, open-source libraries, proprietary code, and third-party elements. Pay special attention to identifying hidden dependencies - these are often missed during manual reviews.
Once you’ve cataloged your components, conduct a vulnerability analysis. Use reliable vulnerability databases to pull the latest Common Vulnerabilities and Exposures (CVE) data and assess each vulnerability using the Common Vulnerability Scoring System (CVSS). Link this analysis to your SBOM to show how you’ve identified and addressed cybersecurity risks. Be sure to export the SBOM in a machine-readable format, like SPDX or CycloneDX, and include a clear explanation of your vulnerability triage process. Following this process aligns with FDA guidelines for regulatory submissions.
Automating SBOM generation through your CI/CD pipeline can save time and improve consistency. Tools like Syft, Trivy, or Snyk can help you create accurate SBOMs for every build. However, manual checks are still necessary for embedded binaries or custom integrations before submission [4][9].
SBOM Formats: SPDX and CycloneDX
The FDA recognizes three machine-readable SBOM formats: SPDX (Software Package Data Exchange), CycloneDX, and SWID (Software Identification) tags. SPDX, backed by the Linux Foundation, is widely used in the medical device industry, especially for its ability to document complex licensing details. CycloneDX, developed by OWASP, focuses on security and excels in identifying vulnerabilities while supporting Vulnerability Exploitability eXchange (VEX) [4][9].
Both SPDX and CycloneDX support JSON and XML outputs, making them compatible with automated tools for vulnerability management. Choosing between the two often depends on your priorities: SPDX is ideal for detailed licensing transparency, while CycloneDX is better suited for security-focused use cases and VEX integration. Whichever format you choose, ensure every component includes a Package URL (purl) - a standardized identifier that helps FDA reviewers verify the component's origin and check for vulnerabilities [9].
"Any device with software, whether it's connected to the internet or not, can carry risk." – Doug Shaw, DShaw Consulting LLC [8]
After generating the SBOM in the appropriate format, integrating it into your regulatory submission becomes a straightforward process.
How to Include SBOMs in Premarket Submissions
For FDA premarket submissions, include your SBOM in the cybersecurity section of the eSTAR template (usually Section J for software documentation). Alongside the SBOM, provide a memo that outlines your vulnerability management process. For example, explain how you handle vulnerabilities with CVSS scores of 7 or higher, such as implementing a 30-day patch cycle, and describe how these risks relate to the device’s safety [3][4].
"Requiring SBOMs in FDA submissions mostly formalizes a practice software teams already follow." – Micah Spieler, Chief Product Officer, Strike Graph [8]
Under Section 524B of the FD&C Act, the FDA can issue a "Refuse to Accept" (RTA) notification for any cyber-device submission missing a complete, machine-readable SBOM starting October 1, 2025 [3][4]. Incomplete SBOMs can also lead to Additional-Information (AI) letters, delaying FDA clearance by 3 to 6 months [4]. To avoid these issues, ensure your SBOM includes all NTIA minimum elements and FDA-specific metadata, such as support levels and end-of-support dates, before submission.
Updating SBOMs After Market Release
SBOMs are not static documents - they need ongoing updates to reflect new vulnerabilities and software changes.
"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." – Qualysec [1]
Because medical devices often remain in use for 10 to 15 years [2], maintaining SBOMs over time is critical for both patient safety and regulatory compliance.
Set up continuous vulnerability monitoring by checking archived SBOMs against databases like Google OSV or Dependency Track to identify newly discovered CVEs in legacy devices [2]. Every software release should have a versioned SBOM that is cryptographically linked to that specific build, ensuring an accurate audit trail throughout the device’s lifecycle [2]. When new vulnerabilities are found, follow a formal process for disclosure and resolution, and notify stakeholders about potential risks and fixes [1].
Many manufacturers are moving toward using dedicated Trust Centers or SBOM hubs instead of email to share SBOMs. These platforms provide secure, up-to-date access for FDA reviewers, auditors, and healthcare providers [2]. To maintain compliance, assign clear responsibility within your team for updating SBOMs and monitoring vulnerabilities. Incorporate SBOM management into your ISO 13485 quality management system [1][3]. This approach helps ensure regulatory compliance while effectively managing cybersecurity risks.
SBOMs and Supply Chain Risk Management
SBOMs (Software Bill of Materials) are not just about post-market security; they are essential for managing the complex web of software dependencies that extend far beyond direct suppliers. A single device can include numerous third-party libraries, each of which may bring in additional components from subcontractors - creating fourth-party risks that are nearly impossible to manage manually. SBOMs provide a detailed inventory of all software components, whether they’re commercial, open-source, or off-the-shelf (OTS).
One key element of SBOMs, the "Dependency relationship" field (outlined in the NTIA minimum elements), shows how different components are interconnected. This transparency helps identify risks stemming from a vendor’s subcontractors. With this information, manufacturers can perform known vulnerability assessments for each component and determine whether their device design mitigates third-party vulnerabilities [2]. This level of insight is crucial for effective risk tracking, as discussed below.
Tracking Third-Party and Fourth-Party Risks
Automated tools make it easier to monitor supply chain risks by embedding SBOM generation directly into CI/CD pipelines. This ensures that every software release is cryptographically tied to its specific build, allowing manufacturers to trace which third-party components are included in each version. Continuous monitoring further enhances security by scanning archived SBOMs for newly discovered vulnerabilities (CVEs), enabling proactive risk management.
By using machine-readable formats like SPDX or CycloneDX, manufacturers ensure compatibility with automated analysis tools commonly used by healthcare providers. Instead of relying on email or manual file transfers to share SBOMs, many manufacturers now use Trust Centers - secure, centralized portals that provide controlled access to both current and historical SBOMs. These portals are invaluable for FDA reviewers, auditors, and healthcare delivery organizations, offering a professional and efficient alternative to outdated sharing methods while ensuring stakeholders have the most up-to-date cybersecurity information.
Using Censinet RiskOps™ for SBOM Management
Advanced platforms like Censinet RiskOps™ are revolutionizing SBOM management by providing centralized solutions tailored to the needs of healthcare delivery organizations. These organizations often manage a vast inventory of medical devices and vendor relationships, making streamlined SBOM analysis essential. Censinet RiskOps™ automates SBOM assessments and vendor evaluations, helping organizations monitor risks across medical devices, supply chains, and third-party vendors. The platform includes a command center that visualizes risk data, making it easier to pinpoint devices with vulnerable components and prioritize vendor assessments effectively.
Conclusion
SBOMs have shifted from being optional documentation to becoming a requirement for medical device manufacturers. Under Section 524B, the FDA now holds the authority to reject premarket submissions that lack sufficient SBOM details, making these inventories critical for regulatory approval [2].
Medical devices often remain in use for 10 to 15 years, leaving them susceptible to evolving cybersecurity threats during their lifespan. Software vulnerabilities that emerge over time can directly impact patient safety [2]. SBOMs play a vital role in identifying these vulnerabilities, enabling manufacturers to address risks promptly through patches and other security measures. Given the complexity of these challenges, automating SBOM management has become a necessity.
"In practice, the SBOM has moved from 'nice-to-have' to essential cybersecurity documentation for medical device submissions." - Viktor Petersson, sbomify [2]
Automated and integrated SBOM management systems are now indispensable. Incorporating automated SBOM generation into CI/CD pipelines ensures compliance with FDA standards while enabling continuous monitoring. Tools like Censinet RiskOps™ help healthcare organizations centralize SBOM analysis, monitor vendor risks, and assess threats across their medical device inventory. This kind of centralized, real-time oversight is essential for managing cybersecurity effectively.
SBOMs should be treated as living documents, updated throughout a device's lifecycle to maintain security. Manufacturers that adopt machine-readable formats like SPDX or CycloneDX, automate vulnerability tracking, and establish secure distribution channels will not only meet FDA compliance but also strengthen patient safety and cybersecurity measures [2][3].
FAQs
Does my device count as an FDA “cyber device”?
A device is considered an FDA "cyber device" if it incorporates software or internet connectivity and is subject to FDA cybersecurity regulations. These rules mandate safeguards such as Software Bill of Materials (SBOMs) and lifecycle security measures to meet compliance standards.
What makes an SBOM “FDA-compliant” beyond NTIA minimum elements?
An SBOM that meets FDA compliance goes beyond the NTIA's basic requirements by incorporating critical lifecycle information. This includes details like end-of-support dates, software versioning, and comprehensive component data. Additionally, it must provide a complete picture of the software supply chain, covering open-source and third-party components, with fields for creator, license, and supplier information.
The FDA also stresses the importance of maintaining dynamic and regularly updated SBOMs, which should be integrated into cybersecurity plans. This approach ensures proactive management of vulnerabilities and promotes transparency throughout the software's lifecycle.
How often should we update and share SBOMs after release?
An SBOM (Software Bill of Materials) isn't a one-and-done document - it needs to evolve alongside the device it supports. Regular updates are critical during key stages like maintenance, software updates, and even end-of-life planning. Why? Because staying current allows for more effective vulnerability tracking and helps with proactive risk management. By keeping your SBOM up to date, you're better equipped to address potential security issues as they arise.
