Medical Device SBOMs Simplified - with Examples & Checklist

SBOMs have become essential to medical device cybersecurity. Learn what SBOMs are, why they matter, and how to stay compliant. Explore the requirements and download our FDA-ready checklist to get started.

What is a medical device SBOM?

A medical device SBOM lists all of its software. It helps manufacturers, users, and regulators understand which software the device uses to operate and link with other systems. That, in turn, helps them find vulnerabilities and strengthen cybersecurity.

A software bill of materials (SBOM) is exactly what it sounds like — a software version of a traditional bill of materials that lists the parts in a manufactured product. SBOMs do the same thing for software: they tell anyone using the product what it’s made of and what vulnerabilities its software components may have. 

In medical devices, the SBOM covers all the software the device uses to function or connect with other systems, such as electronic health records (EHRs), patient portals, cloud platforms, and connected tools.

The FDA and NTIA, the two agencies that interact to define SBOM requirements for medical device manufacturers, use the generic term “component” when describing SBOM entries, as do other official resources. In its foundational 2021 document “Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM),” the NTIA outlines basic SBOM elements and defines key terms. Here, they define  components as “units of software defined by suppliers or authors.” In other words, it’s up to the SBOM author to decide what counts as a component. Still, it’s usually an individual software element — like a library, package, or tool — that works together with others to make the device function.

Key Takeaways

• SBOMs are essential for identifying known vulnerabilities, tracking software risks, and protecting patient safety in increasingly connected healthcare environments.
• The FDA requires manufacturers to include an SBOM in premarket submissions for any “cyber device” — devices with software that connect to the internet — and to keep it updated as part of their postmarket.
• Cybersecurity responsibilities.
• A compliant SBOM must include NTIA-defined baseline attributes — like version, supplier name, and unique identifier — and either include or reference known vulnerabilities and end-of-support data.
• Comprehensive SBOMs go beyond FDA requirements by including every software dependency and using machine-readable formats.
• You can download a sample SBOM and FDA checklist to see exactly what information to include, how to format it, and what potential best practices to adopt.
  
  

How do medical device SBOMs help with FDA compliance?

The FDA requires an SBOM for any “cyber device” — a medical device that has software and connects to the internet. Without it, the FDA won’t review the application, and the manufacturer can’t move forward with approval to sell the device.

In September 2023, the U.S. Food and Drug Administration (FDA) updated its cybersecurity guidelines for medical devices. As part of the update, the FDA officially began requiring SBOMs in premarket submissions for “cyber devices.” 

This move reflected the industry’s growing focus on cybersecurity and the increasing connectivity of medical devices to systems like hospital networks and cloud-based servers. As a result, vulnerabilities in connected devices can affect not just the individual device but also the safety of patients and the stability of healthcare systems. SBOMs are just one part of the FDA’s broader effort to strengthen device cybersecurity as healthcare systems become more connected.

That means any medical device manufacturer that wants FDA approval for commercial use must include an SBOM and other required materials. The rule applies to all premarket submissions, including 510(k), 513, 515(c), 515(f), and 520(m) applications. This new requirement went into effect in October 2023 and put SBOMs in the spotlight for medical device makers.

What does an SBOM in healthcare look like?

Most SBOMs appear as machine-readable code, usually in JSON or XML. Conceptually, they look like a hierarchical tree — each branch is a software component with details like version, license, and known vulnerabilities. The structure stays the same, but the components vary by software.

Machine-readable SBOMs are the industry standard because computers can automatically scan and analyze them. In healthcare, common formats include SPDX, CycloneDX, and SWID. These formats may look complex to non-experts, but the key is the detailed software information they contain.

The National Telecommunications and Information Administration (NTIA) describes an SBOM as follows in the same 2021 document mentioned earlier: “An SBOM is effectively a nested inventory: a list of ingredients that make up software components.” The “nested” structure means that an SBOM doesn’t just list top-level software components — it also shows what those components rely on, and what those rely on, forming a multi-layered map of dependencies. That description can help visualize what information an SBOM contains and how it’s structured.

For example, the image below, from the same 2021 NTIA document, shows conceptual representations of how SBOMs organize components and the relationships between them. As the NTIA says, “these are conceptual representations and not specific formats like SPDX, CycloneDX, or SWID.”

Scope of the FDA’s SBOM mandate and which medical devices must comply

The FDA requires SBOMs for “cyber devices”—medical devices with software, internet access, and cybersecurity risk. The SBOM must list all software: in-house, third-party, open-source, plus any other software that those components depend on.

In its final guidance, “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions,” from September 2023, the FDA outlines its new cybersecurity requirements for premarket medical device applications. Here, the agency clearly states that “cyber devices” require an SBOM. These are a specific subset of devices that:

1. Include software
2. Can connect to the internet
3. Have features that could be vulnerable to cybersecurity threats.

That means that manufacturers of devices that have software but don’t connect to the internet don’t need to submit an SDBOM as part of their application.

The FDA also specifies that the 2023 cybersecurity requirements do not apply to any application that a manufacturer submitted before March 29, 2023, or to previously authorized cyber devices. However, if the manufacturer needs to make a change to the device that requires a premarket review by the FDA, the 2023 cybersecurity requirements would apply, including the requirement to provide an SBOM for any cyber devices.

Although the requirements technically apply only to cyber devices, most medical device manufacturers already keep some form of an SBOM and may submit one even if it’s not a strict requirement. That’s because tracking your software has been a good practice among software producers for years.

"Requiring SBOMs in FDA submissions mostly formalizes a practice software teams already follow," says Micah Spieler, Chief Product Officer at Strike Graph. 

 Doug Shaw owner of DShaw Consulting LLC, reiterates this sentiment: “A lot of companies create SBOMs for devices that fall outside of the FDA’s ‘cyber devices’ requirement.” Shaw says that this is because for manufacturers, SBOMs are essential for security — they aren’t just a compliance checkbox. “Any device with software, whether it’s connected to the internet or not, can carry risk,” he says. “I’ve seen standalone lab instruments infected through something as simple as a USB drive.”

He continues, “If you’re thinking about your full risk profile, it makes sense to document software components across the board — even if the device isn’t technically a ‘cyber device’ under FDA rules. You can flag low-risk components or limited-access systems, but they should still be included. Otherwise, you’re leaving potential attack paths off the table.”

Key pillars of FDA’s SBOM requirement

The FDA has both pre-market and post-market SBOM requirements. Premarket, manufacturers must include specific data fields, cover both in-house and third-party software, and list known vulnerabilities. Postmarket, they must monitor the software and update SBOMs as vulnerabilities change.

The FDA has both pre-submission and postmarket requirements for SBOMs. The pre-submission guidelines explain how to prepare your SBOM, what it must include, and how to present it. The FDA’s eSTAR submission template includes a cybersecurity section where manufacturers can upload or reference their SBOM as part of the application.

Once the FDA approves your device and you begin distribution, the postmarket guidelines apply. For SBOMs, the FDA requires ongoing monitoring for new threats and clear communication with users if you update the SBOM or identify a new vulnerability.

Here’s a closer look at the FDA’s SBOM requirements:

Premarket submission (What goes into the SBOM): 

1. Include NTIA “baseline attributes” for all components
   The FDA requires every SBOM to include baseline attributes that clearly identify each software component and show how the components relate to one another.
   
   To define these baseline attributes, the FDA refers to the NTIA’s 2021 document “Framing Software Component Transparency,” where they define the minimum data fields every SBOM needs.
   
   The FDA also makes it clear that manufacturers must include these data fields for all software in the device, not just the code they wrote. That includes manufacturer-developed components, third-party licensed software, and open-source tools.
   
   
2. Additional information
   Alongside the baseline attributes, the FDA also requires the manufacturer to include the following information, either as part of the SBOM or in an additional document:
   • Level of support: How often the manufacturer still actively fixes bugs, provides updates, or monitors for security issues.
   • Software end-of-support date: The date when the original developer will stop providing updates or fixes.
     
     
3. Identify all known vulnerabilities
   The FDA also requires that the medical device manufacturer identify all the “known vulnerabilities” associated with the device and its software components, including those in CISA’s Known Exploited Vulnerabilities Catalog, also called the KEV catalog.
   
   Most SBOMs don’t include vulnerability data directly within the file. Instead, most manufacturers provide it as a separate addendum. The FDA allows either approach, stating that the information can appear within the SBOM or in a separate document.
   
   For example, many software developers use a VeX (Vulnerability Exploitability eXchange) statement to report the status of known vulnerabilities. A VeX is a standardized security document that indicates whether a known vulnerability affects the product and explains how the manufacturer is addressing it.
   
   For each known vulnerability, the FDA requires manufacturers to include the following:
   
   • Explain how they found the vulnerability:
     Describe the methods you used to identify the issue to help the FDA see if you used strong, reliable ways to search for vulnerabilities, such as automated scanning tools or a vulnerability assessment.
   • Risk assessment:
     Explain how the vulnerability could impact patient safety and device security.
   • Risk response:
     In this section, manufacturers must explain how they are responding to the vulnerability or why they have determined it does not pose a risk. This may include security controls added to reduce exposure.
     
     Suppose the manufacturer can’t fix the issue directly because it involves third-party software that they cannot control. In that case, they should describe any compensating controls, such as isolating the component, blocking network access, or adding extra monitoring to detect potential misuse.
     
     

Post-market requirements (Updating and monitoring the SBOM)

The FDA guidance doesn’t explicitly require ongoing SBOM monitoring. However, it does mandate post-market surveillance of cybersecurity vulnerabilities and updates to affected software. Most experts agree that updating the SBOM — and notifying users of any changes — is necessary to meet these broader post-market obligations.

“Once your device is on the market, your cybersecurity obligations don’t stop,” explains Aude Chetwynd, owner of Technical and Professional Services LLC. Chetwynd has over 20 years of experience in the medical device industry, with extensive experience in implementing software development to help companies comply with regulations from agencies such as the FDA. 

“In fact, your post-market plan needs to show how you’ll track new vulnerabilities, notify users, and deploy patches,” she says. “If you’re distributing kits to multiple customers, that includes having a reliable communication process — so when a security issue comes up, everyone gets notified if you change your SBOM.”

Chetwynd continues, “The post-market plan should reference the same cybersecurity framework you built during pre-market development. It’s a continuation, not a new start. You also need to track response metrics: how long it takes to identify a vulnerability, how quickly you notify customers, and how fast you implement a fix. That performance data goes into your annual report to the FDA.”

Download our free FDA SBOM Compliance Checklist to see exactly what your medical device SBOM needs to include.

What are the baseline attributes for a medical device SBOM?

The seven baseline attributes for a medical device SBOM give each software component a unique identity. They include an identifying code, timestamp, supplier name, and more. These fields show how components connect to each other, so users know exactly what software the device includes.

In its 2023 requirements, the FDA specifies that the SBOM must include “baseline attributes” that the NTIA identified in its 2021 document “Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM).” These are the details that must be in the SBOM, no matter the format. According to the NTIA, the purpose of these baseline attributes is to “identify components and their relationships.”

Here’s a table of the required data fields and their definitions, directly from the NTIA:

What does a comprehensive medical device SBOM include?

A comprehensive SBOM lists every piece of software that the device depends on to function. It also includes licensing information for each component. The SBOM should use a machine-readable format so manufacturers can easily update, manage, and scale it throughout the software’s lifecycle.

A standard SBOM with only baseline attributes includes the minimum required fields to identify software components, such as name, version, supplier, and unique identifiers. It also includes other information that the FDA requires, such as details about the level of support. This type of SBOM meets FDA premarket requirements for “cyber devices,” but only at the most basic level.

In contrast, a comprehensive medical device SBOM offers a full picture of all software components, their interdependencies, and additional information that supports risk assessment and lifecycle management. It typically appears in a machine-readable format and supports automation, traceability, and real-time response. It also includes SBOM best practices that go above and beyond the minimum requirements and allow for more advanced use cases.

Here’s what comprehensive medical device SBOMs should include and support:

• Automation support (machine-readable formats)
  Machine-readable SBOMs allow automated systems to scan, analyze, and integrate software data across large ecosystems. The NTIA’s 2021 guidance, “Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM),” describes machine-readable formats as a requirement for SBOMs in general.
  
  In contrast, the FDA does not formally require machine-readable SBOMs, but they strongly recommend — or, in many cases, even expect a machine-readable format. For smaller companies with simpler devices, generating a machine-readable SBOM can be costly, so a well-organized spreadsheet may be enough to meet the FDA’s basic expectations.
  
  “Whether the FDA expects or even requires a machine-readable SBOM depends on the device,” says Shaw. “If it's a low-risk device with just a few software scripts and limited distribution, the FDA is unlikely to penalize you for submitting a human-readable SBOM, like a spreadsheet. But once the software stack gets deeper — if there are multiple layers of code, third-party integrations, or remote connectivity — the expectation shifts toward automation and standardization.”
  
  Chetwynd adds, “Machine-readable formats just aren’t practical for some devices that only use a handful of custom scripts. Building and maintaining that structure takes real effort, especially if you need to set up tooling or train staff. But when the software is simple and unlikely to have complex vulnerabilities or layered dependencies, that investment doesn’t offer much return.”
  
  
• Dependencies
  Basic SBOMs usually only list top-level software components, and don’t include the deeper structure and context.
  
  “When we talk about ‘complete’ or ‘comprehensive’ SBOMs, what most people mean are SBOMs that capture every dependency, all the way down to the lowest-level code,” explains Spieler. “A complete SBOM doesn’t just include direct dependencies — what your software directly relies on — but also transitive ones. If your software depends on Component A, and Component A depends on Component B, and B depends on Component C, a complete SBOM includes B and C as well.”
  
  Spieler continues with an example from Strike Graph’s software.
  
  “In our software at Strike Graph, we use a Node rich text component for our commenting feature. That makes this component a direct dependency, since we didn’t build it ourselves; we just integrate it into our system. But this rich text component didn’t build everything from scratch either — it relies on its own direct dependencies, which we technically rely on, too. From our perspective, those are transitive dependencies. And those tools might have their own dependencies. So, if we were building a complete SBOM for Strike Graph, we’d include everything — direct dependencies like the rich text component, plus all the transitive ones, all the way down to the lowest-level code.”
  
  

• License information
  SBOMs can include data about the licenses for each component. This data can also allow the user or purchaser to know if the software can be used as a component of another application without creating legal risk.
  
  

Role of SBOMS in medical device risk management

Medical device makers use SBOMs to manage security risks, respond to incidents, and support software updates. Before release, they can assess vulnerabilities and reduce risk. After release, they can track threats, update devices, and notify users. SBOMs also help manage software licenses and protect intellectual property.

Here are some core medical device SBOM use cases:

• Pre-market risk management:
  One of the most important uses of a medical device SBOM is assessing cybersecurity risk before the device goes to market. SBOMs include known vulnerability data that helps the FDA evaluate supply chain risks before a device enters the medical facilities. This information answers key questions: Are there known vulnerabilities? How serious are they? Is any software unsupported or lacking security measures? These details support proactive risk analysis and help the FDA decide whether the device is safe to approve for the market.
  
  
• Post-market risk management:
  After a device enters the market, the manufacturer may discover a new or emerging vulnerability. An SBOM helps them quickly identify which devices are affected and notify users to protect patient safety. If the device is critical — like a pacemaker — expediting this process is critical.
  
  “Known vulnerabilities are only half the story,” explains Chetwynd. “Unknown vulnerabilities require proactive work — things like threat modeling, where you walk through different attack scenarios based on how you build and use your system.”
  
  

Benefits of SBOM adoption for healthcare

SBOMs help improve cybersecurity, which is key to keeping patients safe in today’s connected healthcare systems. They let device makers and hospital IT teams find and fix problems faster and help stop security issues from spreading across systems.

The increasing connectivity of the healthcare sector has brought real benefits for patients — faster results, improved diagnoses, and more coordinated care. But as more patient data flows between medical devices and clinical software, cybersecurity threats have also grown. In its 2023 guidance “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions,” the FDA writes:

“Cybersecurity incidents have rendered medical devices and hospital networks inoperable, disrupting the delivery of patient care across healthcare facilities in the U.S. and globally. Such cyber attacks and exploits may lead to patient harm as a result of clinical hazards, such as delay in diagnoses and/or treatment.”

For the FDA, SBOMs play a critical role in strengthening the healthcare ecosystem’s resilience to cyber incidents. SBOMs do more than support regulatory compliance — they offer tangible operational and clinical benefits:

• Faster response to healthcare cyber-attacks:
  SBOMs give IT and security teams a clear picture of what software is running on each device. When a new vulnerability appears, they can quickly pinpoint affected devices and act fast.
  
  “Once your device is on the market, your cybersecurity responsibilities don’t stop,”  Chetwynd says. “An SBOM makes it much easier to respond when a new vulnerability shows up. It gives you a clear picture of what software is in each device, so you can quickly figure out which ones are affected. If you’ve shipped the device to multiple customers, the SBOM helps you target your response.”
  
  
• Improved software development and testing:
  By mapping dependencies early, SBOMs help developers spot potential conflicts or security concerns before they reach production.
  
  “SBOMs help you manage and even build around known vulnerabilities,” explains Shaw. “Once you’ve documented all your software components, you can match them against public databases to see which ones have known security issues. This is one of the most straightforward benefits of SBOMs: They let you connect the dots between what's running in your system and what’s already been flagged elsewhere.”
  
  
• Better understanding of legacy systems:
  In many hospitals, devices may run on outdated or poorly documented software. SBOMs help identify what’s still in use, what needs updating, and where unsupported or vulnerable components might still be active. Even an incomplete SBOM supports safer long-term device management.
  
  
• Increased transparency
  While most stakeholders don’t review SBOMs daily, having one available ensures that when regulators or IT staff need answers, they can quickly find out what software is in a device and how any security events might affect the device.
  
  
• Helps identify risks in third-party components
  "There’s an adage in software security that your biggest risks aren’t in the code you wrote — they’re in the third-party components you used to write that code,” says Spieler. “An SBOM helps you track what’s in your software and stay aware of any known vulnerabilities in the supply chain, even if it isn’t part of the code you wrote yourself.”
  
  In a healthcare setting, even a small oversight could seriously affect patient safety. SBOMs provide much-needed visibility into potential threats before they become real risks.
  
  
• Helps plan for software end-of-life
  “In medical devices, software can’t just be installed and forgotten — it impacts patient care, and sometimes it’s even implanted into a person’s body,” explains Spieler.
  
  “Monitoring SBOMs over time helps manufacturers keep track of their software inventory. We sometimes call it ‘software lifecycle management.’ For example, if an SBOM reveals that a critical component that was written in 1999 is nearing end-of-life or has a known vulnerability, the team can start planning for an update before it becomes a risk or liability.”
  
  
• Track licensing information
  Medical devices often rely on complex software ecosystems. Without clear tracking, manufacturers may unknowingly include software with restrictive licenses. An SBOM helps identify licensing terms and avoid unintentional legal violations.
  
  

Different formats for medical device SBOMs

Most medical device SBOMs use machine-readable formats, usually in JSON. The main standards are CycloneDX and SPDX. Some teams also use SWID tags to help track vulnerabilities. In rare cases, like when a small company submits a device with very few components, the FDA may accept a spreadsheet format instead.

Here's a list of the different formats for medical device SBOMs:

• CycloneDX

• • Best for: Security-focused use cases
    CycloneDX was designed for cybersecurity workflows and supports rich metadata about component relationships, vulnerabilities, and licensing. CycloneDX is common in healthcare settings because it integrates well with vulnerability management tools and supports a detailed software inventory.
    
    
  • Example: View CycloneDX JSON on GitHub
    
    

• SPDX (Software Package Data Exchange)
  • Best for: License and compliance tracking
    SPDX was developed by the Linux Foundation to document software licenses and components across complex supply chains. Use SPDX when you’re managing license obligations or combining proprietary and open-source components.
  • Example: View SPDX Example
    
     

• SWID (Software Identification) Tags

• • Best for: Enhancing vulnerability and asset tracking
    SWID isn’t a full SBOM format on its own — it’s a standardized tagging system that helps identify software components and link them to known vulnerabilities. Some tools generate SWID tags alongside CycloneDX or SPDX to improve tracking.
    
    

• Spreadsheet
  • Best For: Simple SBOMs with very few components
    This format may be acceptable for basic FDA submissions for early-stage device manufacturers, but it doesn’t support automated vulnerability tracking or integration with security tools. Use only when machine-readable formats aren’t practical.

Download our sample SBOM to see what a medical device SBOM looks like in a simple spreadsheet

This fictitious example includes all the key fields — including version numbers, license info, and known vulnerabilities — so you can understand the structure at a glance.

Easiest way to monitor medical SBOMs and manage vulnerabilities to strengthen cybersecurity

Strike Graph’s SBOM Manager automatically scans your software components for known vulnerabilities, alerts you to new threats, and helps you document your response. It supports a key part of FDA compliance by keeping your SBOM up to date and making it easier to share changes.

Medical device teams need strong risk management and fast incident response. Strike Graph’s SBOM Manager helps strengthen your medical device cybersecurity by keeping your SBOM active and up to date, so you can meet FDA expectations and respond quickly to new threats.

The SBOM Manager automatically scans your software components every day, checking them against trusted vulnerability databases. When it finds a high or critical risk, it alerts you and recommends actions to update your SBOM or reduce the threat.

After you upload your SBOM, you’ll see a complete visual breakdown of your software tree and a summary of the vulnerabilities detected. With built-in integrations, you only need to upload your SBOM once. The system continues monitoring it for you.

Strike Graph’s SBOM Manager helps you stay compliant, act quickly, and turn your SBOM into a tool that strengthens your device’s security.