Ultimate Guide to SBOMs for FDA-Regulated Devices
Post Summary
Section 524B of the FD&C Act mandates including SBOMs in premarket submissions for all cyber devices, effective March 29, 2023, with Refuse to Accept enforcement for incomplete submissions since October 1, 2023. A device qualifies as a cyber device if it includes validated software installed or authorized by the sponsor, can connect to the internet directly or indirectly, and has features making it susceptible to cyber threats. The requirement applies to submissions through 510(k), PMA, De Novo, HDE, and PDP pathways. Devices without software or internet connectivity are generally excluded. Products submitted before March 29, 2023 are grandfathered unless modified. The June 2025 FDA guidance clarified SBOM content and format requirements, with 510(k) submissions requiring the eSTAR electronic template.
Supplier Name identifies the organization behind each component, enabling tracing of third-party risk origins. Component Name specifies the supplier-assigned name essential for inventory control and vulnerability matching. Version indicates the specific software version for distinguishing between patched and vulnerable code. Unique Identifiers such as Package URL or CPE enable automated cross-referencing with CVE databases. Dependency Relationship maps how components interact and how vulnerabilities in one part can affect the entire device. Author of SBOM Data establishes accountability for accuracy and reliability of the SBOM record. Timestamp marks when the SBOM was created to confirm it reflects the current software state.
The FDA requires documentation of Software Component Support Level for every component — classified as active or full support, security-fixes-only or legacy, or unsupported or abandoned. End-of-Support dates must be specified for every component, marking when the supplier will stop providing updates — critical for devices with 10 to 15 year operational lifespans. A detailed vulnerability assessment must identify known vulnerabilities using resources such as the CISA Known Exploited Vulnerabilities catalog, describe how vulnerabilities were discovered through automated tools, manual review, or penetration testing, explain the potential impact on device safety and performance, and document mitigation or compensating controls implemented for each vulnerability. For open-source components without clear EOS dates, manufacturers must infer support status from commit history or registry updates and provide written justification to the FDA when exact dates are unavailable.
The FDA recognizes three machine-readable formats: SPDX backed by the Linux Foundation, CycloneDX developed by OWASP, and SWID tags. SPDX is widely used for its detailed licensing documentation capability. CycloneDX focuses on security use cases and excels at vulnerability identification with Vulnerability Exploitability eXchange support. Both SPDX and CycloneDX support JSON and XML outputs compatible with automated vulnerability management tools. Every component must include a Package URL as a standardized identifier enabling FDA reviewer verification. SBOM generation should be automated within CI/CD pipelines using tools such as Syft, Trivy, or Snyk for every build, with manual checks retained for embedded binaries and custom integrations before submission.
SBOMs must be treated as living documents updated with every software release, with each version cryptographically linked to its specific build for an accurate audit trail. Continuous vulnerability monitoring using databases such as Google OSV or Dependency Track scans archived SBOMs for newly discovered CVEs in legacy devices. The NTIA Dependency Relationship field reveals how a vendor's subcontractors introduce fourth-party risks — exposing vulnerabilities in components of components that manual tracking cannot surface. Trust Centers or SBOM hubs replacing email distribution provide secure, centralized access for FDA reviewers, auditors, and healthcare providers to current and historical SBOMs. SBOM management must be incorporated into the ISO 13485 quality management system and assigned clear team ownership for ongoing updates and vulnerability monitoring.
Healthcare delivery organizations managing large inventories of medical devices and vendor relationships cannot track SBOM-based vulnerability status across their portfolios through manual processes. Censinet RiskOps™ automates SBOM assessments and vendor evaluations, centralizes risk data visualization through a command center that identifies devices with vulnerable components, and prioritizes vendor assessments by risk. The platform supports continuous monitoring of SBOM findings across third-party vendors, supply chains, and medical device inventories — providing the portfolio-scale visibility that enables healthcare organizations to respond to newly disclosed CVEs affecting deployed devices rather than discovering vulnerabilities only through incident.
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:
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
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:
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:
NTIA Baseline Attribute
Description
Importance for FDA Compliance
Entity that creates/defines the component
Identifies the origin of third-party risk
Designation assigned by the supplier
Essential for inventory and vulnerability matching
Identifier for a specific software change
Distinguishes between patched and vulnerable code
Lookup keys like purl or CPE
Enables automated cross-referencing with CVE databases
How components relate to each other
Maps the impact of upstream vulnerabilities on the device
Entity that created the SBOM record
Establishes accountability for the data's accuracy
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
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
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
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
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.
Related Blog Posts
- IoT Device Compliance: FDA Postmarket Audit Guide
- FDA Cybersecurity Guidance: Key Updates for 2025
- Best Practices for FDA IoT Cybersecurity Compliance
- FDA Guidance: Incident Response for Medical Device Exploits
{"@context":"https://schema.org","@type":"FAQPage","mainEntity":[{"@type":"Question","name":"Does my device count as an FDA “cyber device”?","acceptedAnswer":{"@type":"Answer","text":"<p>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 <strong>Software Bill of Materials (SBOMs)</strong> and lifecycle security measures to meet compliance standards.</p>"}},{"@type":"Question","name":"What makes an SBOM “FDA-compliant” beyond NTIA minimum elements?","acceptedAnswer":{"@type":"Answer","text":"<p>An SBOM that meets FDA compliance goes beyond the NTIA's basic requirements by incorporating critical lifecycle information. This includes details like <strong>end-of-support dates</strong>, <strong>software versioning</strong>, and <strong>comprehensive component data</strong>. Additionally, it must provide a complete picture of the software supply chain, covering open-source and third-party components, with fields for <strong>creator</strong>, <strong>license</strong>, and <strong>supplier</strong> information.</p> <p>The FDA also stresses the importance of maintaining <strong>dynamic and regularly updated SBOMs</strong>, which should be integrated into cybersecurity plans. This approach ensures proactive management of vulnerabilities and promotes transparency throughout the software's lifecycle.</p>"}},{"@type":"Question","name":"How often should we update and share SBOMs after release?","acceptedAnswer":{"@type":"Answer","text":"<p>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 <em>maintenance</em>, <em>software updates</em>, and even <em>end-of-life planning</em>. 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.</p>"}}]}
Key Points:
What is the FDA's SBOM regulatory framework and what are the consequences of incomplete or missing SBOM documentation?
- Section 524B as the statutory SBOM mandate — Section 524B of the FD&C Act, introduced through the 2023 Consolidated Appropriations Act, mandates that all cyber device premarket submissions include machine-readable SBOMs listing every software component. This requirement applies to 510(k), PMA, De Novo, HDE, and PDP submission pathways — covering the full range of premarket clearance and approval routes used by medical device manufacturers.
- Refuse to Accept enforcement converting SBOM from guidance to market access gate — Effective October 1, 2023, the FDA issues Refuse to Accept notifications for cyber device submissions lacking complete SBOM documentation. This enforcement mechanism converts SBOM compliance from a regulatory preference into a market access requirement — a submission without an adequate SBOM does not proceed through review, it is rejected at intake.
- AI letters delaying clearance by 3 to 6 months for incomplete SBOMs — Incomplete SBOMs — those that technically accompany a submission but lack required elements — trigger Additional Information letters that delay FDA clearance by 3 to 6 months. The delay cost of an incomplete SBOM substantially exceeds the preparation cost of completing one correctly before submission, establishing thoroughness as the economically rational approach.
- June 2025 FDA guidance clarifying format and content requirements — The FDA's June 27, 2025 guidance titled "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions" provided updated detail on required SBOM content and format, including the eSTAR template requirement for 510(k) submissions. Missing attachments or inaccurate responses in the cybersecurity section of the eSTAR template can result in a technical screening hold.
- Grandfathering limited to pre-March 2023 unmodified submissions — Devices submitted before March 29, 2023 are grandfathered under prior rules only if they are not subsequently modified. Any modification to a previously submitted device triggers the Section 524B SBOM requirement — making ongoing device modification decisions a compliance trigger that product teams must evaluate against the SBOM readiness requirement.
- Cyber device definition requiring affirmative three-factor assessment — A device qualifies as a cyber device only if it includes validated software installed or authorized by the sponsor, can connect to the internet directly or indirectly, and has features making it susceptible to cyber threats. Manufacturers uncertain whether their device qualifies should seek FDA clarification before submission — misclassification causes delays equivalent to or greater than those caused by SBOM omission.
What are the seven NTIA baseline attributes and what operational role does each play in FDA-compliant vulnerability management?
- Supplier Name enabling third-party risk tracing — The Supplier Name identifies the organization that created or defined each software component — the foundational data element for tracing third-party risks to their origin. When a vulnerability is disclosed for a specific supplier's software, Supplier Name enables manufacturers to identify which of their devices contain that supplier's components without manually reviewing every device's software inventory.
- Component Name and Version together identifying the specific vulnerable artifact — Component Name alone is insufficient for vulnerability tracking — the same component from the same supplier may be vulnerable in one version and patched in another. The combination of Component Name and Version precisely identifies the specific software artifact that is or is not affected by a disclosed CVE, enabling accurate affected device determination rather than precautionary over-remediation.
- Unique Identifiers enabling automated CVE database cross-referencing — Package URL and Common Platform Enumeration identifiers enable automated cross-referencing with the National Vulnerability Database and other CVE sources without requiring manual component matching. The automation dependency created by Unique Identifiers makes their accuracy the most consequential data quality requirement in the SBOM — an incorrect purl means the component will not be matched during automated vulnerability scanning.
- Dependency Relationship field revealing fourth-party risk — The Dependency Relationship field maps how components depend on other components — exposing the fourth-party risk created when a component in the device depends on a subcomponent from a vendor's subcontractor. This field is the only SBOM element that makes subcontractor-level supply chain risk visible without direct subcontractor engagement, enabling manufacturers to identify vulnerabilities two or more tiers down the supply chain from their direct component suppliers.
- Author of SBOM Data establishing accountability for record accuracy — The Author of SBOM Data identifies who is responsible for the accuracy and reliability of each SBOM record. During FDA review or post-market vulnerability investigation, this field identifies who must be contacted to verify or update specific component records — establishing a clear accountability chain for SBOM data quality management.
- Timestamp confirming SBOM currency at submission and postmarket — The Timestamp confirms that the SBOM reflects the software state at the time of build — a verification requirement that becomes critical when multiple SBOM versions exist for a device across its lifecycle. An SBOM without a timestamp, or with a timestamp that does not match the build date, cannot be verified as accurate for the specific device version under review.
What FDA-specific SBOM requirements exceed the NTIA baseline and why are they particularly important for devices with long clinical lifespans?
- Software Component Support Level as the lifecycle risk classification — Classifying each component as active or full support, security-fixes-only or legacy, or unsupported or abandoned creates a lifecycle risk map of the device's software inventory at any point in its operational life. A component classified as active at submission may be reclassified as legacy or unsupported years into the device's deployment — a change that the FDA's postmarket surveillance framework requires manufacturers to track and disclose.
- End-of-Support dates as the predictive vulnerability planning tool — EOS dates identify the specific future point at which each component will cease receiving security patches. For devices with 10 to 15 year operational lifespans, components whose EOS dates fall within the device's clinical life create known future vulnerability windows that must be addressed through replacement planning or compensating controls — a proactive risk management requirement that point-in-time vulnerability assessments cannot satisfy.
- Open-source component EOS inference requirement — Many open-source components do not publish formal EOS dates, requiring manufacturers to infer support status from commit history, registry update frequency, or community activity patterns. The FDA requires written justification when exact EOS dates are unavailable — a documentation requirement that incentivizes manufacturers to select components with clear support commitments and to actively monitor the support status of components that lack them.
- CISA KEV integration for active exploitation prioritization — Identifying known vulnerabilities using the CISA Known Exploited Vulnerabilities catalog — not only the NVD — distinguishes between theoretical vulnerability exposure and confirmed active exploitation in real-world attacks. CVEs appearing in the CISA KEV list require accelerated remediation because they represent active attacker behavior rather than disclosed but unexploited vulnerabilities.
- Mitigation and compensating control documentation for every vulnerability — For each identified vulnerability, manufacturers must document the specific mitigation or compensating control implemented. This documentation requirement converts vulnerability identification from a passive listing exercise into an active risk management record — establishing that the manufacturer has not merely identified vulnerabilities but has taken documented action to address them.
- Vulnerability discovery method documentation enabling assessment quality verification — Documenting whether vulnerabilities were discovered through automated tools, manual review, penetration testing, or other methods enables FDA reviewers to assess the depth and rigor of the manufacturer's vulnerability identification process. A vulnerability assessment relying solely on automated scanning may miss vulnerabilities that manual review or penetration testing would identify — a quality dimension the discovery method documentation makes visible.
How should manufacturers create, format, and submit FDA-compliant SBOMs and what makes SPDX and CycloneDX the preferred formats?
- Comprehensive software inventory as the SBOM creation foundation — Creating an FDA-compliant SBOM begins with inventorying every software component in the device — commercial off-the-shelf products, open-source libraries, proprietary code, and third-party elements — with particular attention to hidden dependencies that manual reviews frequently miss. This inventory must be complete before vulnerability analysis begins, as components excluded from the inventory will not be assessed.
- SPDX for licensing transparency and CycloneDX for security focus — SPDX, backed by the Linux Foundation, is widely used in the medical device industry for its detailed licensing documentation capability — enabling manufacturers to track not only security status but also license obligations across their component inventory. CycloneDX, developed by OWASP, focuses on security use cases and supports Vulnerability Exploitability eXchange documents that clarify which listed vulnerabilities do not affect the specific device — reducing the burden on healthcare facilities that must otherwise investigate every listed CVE independently.
- Package URL as the mandatory component identifier — Every component in the SBOM must include a Package URL as a standardized identifier enabling FDA reviewer verification of component origin and CVE database cross-referencing. A component identified only by name without a purl cannot be automatically matched against vulnerability databases — creating a manual review requirement that slows FDA processing and increases rejection risk.
- CI/CD pipeline integration ensuring per-build SBOM accuracy — Automating SBOM generation through CI/CD pipelines using tools such as Syft, Trivy, or Snyk ensures that every software build produces an accurate, current SBOM reflecting the exact components in that specific version. Manual SBOM creation from documentation is not an adequate substitute because it cannot reliably capture all components, particularly transitive dependencies introduced by package managers.
- eSTAR template placement and vulnerability memo requirement — For 510(k) submissions, the SBOM belongs in the cybersecurity section of the eSTAR template — typically Section J for software documentation. A memo accompanying the SBOM must outline the vulnerability management process, including how vulnerabilities above specific CVSS thresholds are handled, patch cycle timelines, and how identified risks relate to device safety. Missing this memo is a common cause of technical screening holds.
- Manual checks for embedded binaries before submission — Automated SBOM generation tools may not capture all software components in devices with embedded binaries or custom integrations. Manual review of automated SBOM outputs before submission is required to identify components that automated tools missed — a verification step that distinguishes adequate from inadequate SBOM preparation processes.
How should manufacturers manage SBOMs postmarket and how does the Dependency Relationship field address fourth-party supply chain risk?
- SBOM as a living document updated with every software release — An SBOM created at initial submission and never updated does not satisfy FDA postmarket surveillance obligations. Every software release must generate a new versioned SBOM cryptographically linked to that specific build, creating an unbroken audit trail of software composition across the device's full operational lifecycle. SBOMs that cannot be connected to a specific build cannot serve as postmarket vulnerability management tools.
- Continuous monitoring using Google OSV and Dependency Track for legacy device CVE scanning — Legacy devices — those whose active development has ended but that remain in clinical use — accumulate vulnerability exposure as new CVEs are disclosed against their components after the last software update. Continuously scanning archived SBOMs against Google OSV and Dependency Track identifies newly disclosed vulnerabilities in legacy components, enabling manufacturers to assess patient safety risk and issue advisories or compensating control guidance without waiting for clinical incidents to surface the exposure.
- Fourth-party risk visibility through the Dependency Relationship field — The Dependency Relationship field makes visible the subcontractor-level supply chain risks that direct supplier assessments cannot reach. When a component in the device depends on a library from a vendor's subcontractor, the Dependency Relationship field in the SBOM reveals that dependency — enabling manufacturers to assess vulnerability risk two or more tiers down their supply chain without requiring direct engagement with every subcontractor.
- Trust Centers replacing email for SBOM distribution — Email-based SBOM distribution creates version control problems, access control gaps, and audit trail deficiencies that professional compliance management requires eliminating. Trust Centers and SBOM hub platforms provide controlled access for FDA reviewers, auditors, and healthcare providers to both current and historical SBOMs — with access logging, version control, and authentication that email distribution cannot provide.
- ISO 13485 QMS integration as the organizational accountability mechanism — Incorporating SBOM management into the ISO 13485 quality management system assigns documented responsibility for SBOM updates, vulnerability monitoring, and disclosure processes within the organization's existing quality governance structure. Without QMS integration, SBOM management is an informal activity dependent on individual knowledge rather than a controlled process that survives personnel changes.
- Vulnerability disclosure and stakeholder notification as formal postmarket obligations — When new vulnerabilities are discovered in postmarket SBOM monitoring, manufacturers must follow a formal disclosure and resolution process — notifying stakeholders about potential risks and fixes rather than addressing vulnerabilities silently. This disclosure obligation applies throughout the device's clinical life, making postmarket SBOM monitoring a patient safety function as well as a regulatory compliance activity.
How does Censinet RiskOps™ support SBOM-based vulnerability management and fourth-party supply chain risk for healthcare delivery organizations?
- HDO scale challenge requiring portfolio-level SBOM management — Healthcare delivery organizations managing hundreds or thousands of medical devices from dozens of manufacturers cannot track SBOM-based vulnerability status across their full device portfolio through manual processes. When a new CVE is disclosed for a software component present in multiple device types from multiple manufacturers, manual assessment of each affected device's SBOM is operationally infeasible at HDO portfolio scale.
- Centralized SBOM analysis automating vulnerable device identification — Censinet RiskOps™ automates SBOM assessment across the device portfolio, enabling HDOs to identify which specific devices contain components affected by newly disclosed CVEs without manually reviewing each device's SBOM. This automation converts the critical-hours response that patient safety requires into an operationally achievable workflow rather than a manual effort that takes days or weeks.
- Command center visualizing risk across devices, supply chains, and vendors — The platform's command center visualizes risk data across medical devices, supply chains, and third-party vendors simultaneously — providing the integrated risk picture that allows HDOs to understand not only which devices have vulnerable components but also which vendor relationships and supply chain dependencies are contributing to the risk, and to prioritize remediation and vendor engagement accordingly.
- Vendor evaluation automation supporting FDA-required postmarket surveillance — FDA postmarket surveillance requirements for cyber devices include ongoing monitoring of the vendor relationships that supply device software components. Censinet RiskOps™ automates vendor evaluations aligned with postmarket surveillance obligations, ensuring that vendor security posture changes — including disclosed vulnerabilities in vendor-supplied components — are identified and assessed in real time rather than at annual review intervals.
- Fourth-party dependency risk at portfolio scale — The fourth-party risk revealed by SBOM Dependency Relationship fields creates a tracking challenge that is multiplicative rather than additive at portfolio scale — each device's dependency graph may have dozens of fourth-party relationships, and tracking them manually across a large device portfolio is infeasible. Censinet RiskOps™ maps and monitors these dependency relationships at portfolio scale, providing the visibility into subcontractor-level supply chain risk that fourth-party risk management requires.
- Integration supporting the full SBOM lifecycle from submission through decommissioning — Effective SBOM management spans from premarket submission through every postmarket software update and ultimately through device decommissioning. Censinet RiskOps™ supports the full SBOM lifecycle by maintaining centralized SBOM records, tracking vulnerability status updates, and connecting SBOM findings to the vendor assessment and risk prioritization workflows that convert SBOM data into actionable remediation plans throughout the device's operational life.
