SBOM Requirements for Medical Devices: 2026 Guide

If you sell a cyber device in the U.S., an SBOM is part of FDA compliance. Since October 1, 2023, the FDA has been able to refuse a submission that lacks required cyber materials, and in 2026 that rule is now part of day-to-day device work.

Here’s the short version: if your device has software, connects to a network, and has cyber risk, you likely need a machine-readable SBOM, regular updates after software changes, and records that match your risk file, testing, and threat work. In most cases, that also means using CycloneDX or SPDX, listing direct and transitive components, and adding VEX when known flaws need context.

If I had to boil the full guide down, I’d focus on these points:

• Section 524B applies to FDA-defined cyber devices
• The FDA reviews SBOMs in 510(k), PMA, HDE, and IDE submissions
• PDFs are not enough for FDA SBOM submission needs
• A usable SBOM should list component name, supplier, version, dependency data, IDs like purl/CPE, author, and generation time
• The SBOM should cover more than app code, including firmware, OSs, libraries, COTS, transitive dependencies, cloud-linked services, and AI/ML items
• Every patch, swap, or version change should trigger a new SBOM record
• Hospitals use SBOMs for procurement, device intake, patch planning, segmentation, and CVE triage
• Device lifecycles often run 10 to 15 years, while 75%+ of software may come from third-party code
• Global manufacturers also need to watch the EU Cyber Resilience Act timeline starting September 11, 2026

A few details stand out. The FDA wants traceability across the SBOM, threat model, risk records, and test results. Hospitals want the same source data, but in a form they can use for device fleet review and vulnerability checks. And because 90%+ of modern device software may include open-source components, missing dependencies can turn the SBOM into a weak record fast.

For many teams, the plain answer is this: generate SBOMs in CI/CD, store them as controlled quality records, update them with each release, and match them against CISA KEV and NVD feeds. That gives you a cleaner path for both FDA review and field risk work.

This guide explains what the FDA expects, what a compliant SBOM should contain, how to keep it current, and how healthcare organizations use it after purchase.

FDA SBOM Requirements Explained: What Medical Device Makers Get Wrong

sbb-itb-535baee

Quick Comparison

FDA SBOM Requirements for Medical Devices

Section 524B of the FD&C Act and the FDA's June 2025 final guidance, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions, set the baseline for SBOM compliance. In plain English, this means SBOMs are no longer just a paperwork item. They are part of both regulatory compliance and patient safety.

That leads to three practical issues: when an SBOM is required, how the FDA checks it, and what manufacturers need to share beyond the agency.

Section 524B and Cyber Device Obligations

Section 524B applies to "cyber devices" only. That term covers devices that have software, network connectivity, and cybersecurity exposure. If a device checks all three boxes, an SBOM must be included.

The law says manufacturers must submit an SBOM as part of their premarket package. It also says the SBOM has to be updated after software changes or field patches. Even when a device does not meet the legal definition of a cyber device, the FDA's 2025 guidance still strongly recommends sending an SBOM if the device includes software.

How FDA Reviews SBOMs in Premarket Submissions

The FDA reviews SBOMs across the main submission pathways: 510(k), PMA, HDE, and IDE. Since October 1, 2023, the agency has had the authority to issue a Refuse to Accept (RTA) ruling when a cyber device submission is missing required SBOM materials ^[1].

Reviewers look for traceability across the full cybersecurity record. In other words, the threat model, cybersecurity risk assessment, SBOM, and testing records should line up. If one piece says a component exists and another piece ignores it, that's a problem.

Common gaps include:

• submitting only a PDF instead of a machine-readable file
• leaving out transitive dependencies
• not including VEX documentation for components with known vulnerabilities

What FDA Expects Manufacturers to Share With Healthcare Organizations

FDA submissions and hospital disclosures start from the same source data, but they do different jobs. One is for regulatory review. The other helps hospitals make risk decisions in day-to-day use.

Following IMDRF N73 guidance, manufacturers are more often expected to share SBOM data proactively with healthcare organizations. That gives hospital procurement and clinical engineering teams what they need to assess deployment risk, plan patching, and put compensating controls in place. This matters even more for devices that stay in service for years ^[1].

What a Compliant Medical Device SBOM Should Include

A compliant SBOM only helps if it’s complete, machine-readable, and kept up to date. In practice, that comes down to three things: the right data fields, one of the accepted formats, and full coverage of the software and related assets in the device.

Minimum Data Elements and Baseline Attributes

Once the regulatory baseline is clear, the next step is simple: what does an acceptable SBOM actually need to list? The NTIA minimum baseline includes these seven fields:

These fields reflect the NTIA baseline for medical device SBOMs ^[1].

That baseline is a start, not the whole story. It also helps to include lifecycle details such as support status, end-of-support date, Known Exploited Vulnerabilities (KEV) exposure, and a VEX file that shows whether a listed flaw is exploitable in the device’s actual setup. For hospitals, this matters a lot. EOS dates and KEV references help security teams sort urgent issues from background noise, which ties the SBOM straight into postmarket risk work ^[1].

Accepted Machine-Readable Formats and Why PDFs Fall Short

The FDA accepts three machine-readable formats: CycloneDX, SPDX, and SWID tags. PDFs do not meet this requirement ^[1].

CycloneDX is the recommended option for most medical device submissions because it was built with security in mind and includes native VEX support ^[1]. SPDX still makes sense when license compliance is also part of the job. SWID tags fit best as an extra layer for hospital IT asset tracking.

Why not PDFs? Because a PDF may be easy for a person to read, but it’s a pain for tools to parse, compare, and act on. And that’s the whole point of an SBOM in the first place: fast matching, fast triage, and less guesswork.

Which Assets Must Be Covered in the SBOM

More than 90% of modern medical device software uses open-source components ^[2], so the scope of the SBOM can’t be narrow. A complete SBOM needs to cover proprietary code, firmware, operating systems, system libraries, open-source libraries, COTS software, transitive dependencies, cloud services tied to device function, and AI/ML artifacts ^[1].

Miss part of that stack, and the SBOM stops being much use. Vulnerability response gets slower, affected devices are harder to find, and teams lose time chasing incomplete records. That’s why these assets need to be identified early and updated across releases.

How to Build and Maintain SBOM Processes Across the Device Lifecycle

Knowing what goes into an SBOM is one thing. Keeping it right as software changes over time is the hard part. The goal is simple: build a repeatable process that works for engineering, product security, regulatory, and quality teams across design, development, release, and postmarket support.

Generating SBOMs During Design and Development

Once you've defined the SBOM content, the next step is to make generation and updates part of day-to-day development. In practice, that means automating SBOM generation in CI/CD so every build creates a new SBOM on its own. You also need to capture all build outputs and dependencies, including transitive and runtime components.

Tools like Syft, Trivy, and the CycloneDX CLI are a solid place to start for generation and validation. For legacy systems or third-party black box components (SOUP), use binary analysis tools to identify constituent libraries through signature matching when source code is unavailable ^[2]. It isn't as exact as build-time generation, but it's much better than leaving those components out of the record.

Under ISO 13485, the SBOM should be handled as a controlled DMR artifact. Every component swap, patch, or version update should move through formal change control. Tying SBOM updates to ISO 13485 Clause 7.5.9 (Configuration Management) and Clause 4.2.4 (Document Control) keeps the process auditable and links SBOM governance to the DMR, DHF, and change control.

Keeping SBOMs Current Through Releases and Updates

Every software change - whether it's a patch, swap, or version update - should trigger SBOM regeneration and a new versioned record. That record should stay traceable to the DMR, DHF, the risk management file, the threat model, and testing documentation.

Why does that matter? Because without traceability, reviewers can't tell whether what's listed in the SBOM matches what was tested and approved. And that's where teams can get stuck.

Using SBOMs for Premarket Evidence and Postmarket Response

For premarket evidence, pair the SBOM with VEX and traceability records to show whether listed vulnerabilities are exploitable in the shipped configuration ^[1][2].

After launch, use the SBOM to automate KEV matching and vulnerability triage. Subscribing to the CISA Known Exploited Vulnerabilities (KEV) catalog and cross-referencing it against the current SBOM is a practical way to spot urgent threats before they turn into incidents ^[1]. Internal triage and remediation SLAs also help support reasonable cybersecurity assurance.

It also helps to map each lifecycle stage to a clear owner, artifact set, and control point. That way, no one is left guessing who owns what.

These same lifecycle records also help healthcare organizations assess devices during procurement and post-deployment risk review.

How Healthcare Organizations Use SBOMs in Risk Management

SBOMs matter most when hospitals use them during buying, rollout, and day-to-day device management. That’s the point where compliance stops being a paperwork exercise and starts helping with risk control. For healthcare organizations, an SBOM has the most use when it shapes procurement, deployment, and response decisions.

SBOM Use in Procurement, Deployment, and Vulnerability Triage

Before signing a purchase order, clinical engineering and IT security teams can ask for a machine-readable SBOM in CycloneDX or SPDX format. Then they can check it against the CISA Known Exploited Vulnerabilities (KEV) Catalog and the National Vulnerability Database (NVD), which makes vendor claims easier to verify. A device can show up with known risk already buried in its software stack. If teams catch that during intake, they have time to put compensating controls in place, like network segmentation or firewall rules tuned to that device. That same inventory also helps with deployment controls and incident response.

Once a device is live, current SBOMs can cut response time. If a new critical vulnerability appears, teams with an up-to-date SBOM inventory can spot exposed devices right away instead of waiting for manufacturer advisories. Pair SBOM data with VEX, and the affected-device list gets tighter because teams can see whether a listed vulnerability is actually exploitable in the device’s setup.

Teams should also track component end-of-support dates in the SBOM. That gives clinical engineering time to plan patching, compensating controls, and replacement before software reaches the point where it can’t be patched.

These use cases work even better when SBOM data flows into the systems teams already use for assets and risk.

Connecting SBOM Data to Enterprise and Third-Party Risk Workflows

An SBOM helps only if it feeds operational systems. When SBOM records connect to a Computerized Maintenance Management System (CMMS) or IT asset inventory, they create a living software map of the connected device fleet. So when a new CVE drops, teams can see which devices need attention first based on clinical impact and exploitability. Risk platforms can also tie SBOM findings to third-party and enterprise risk workflows, cybersecurity benchmarking, and collaborative remediation.

The payoff depends on getting current, machine-readable SBOMs from vendors. That’s why the manufacturer duties covered in earlier sections directly support HDO operations.

Conclusion: Key SBOM Priorities for 2026

SBOMs are no longer a nice-to-have. They are a regulatory requirement. Under Section 524B of the FD&C Act, the FDA can issue a Refuse to Accept (RTA) ruling for any cyber device submission that does not include an SBOM, and that authority has been in force since October 1, 2023. ^[1] In plain terms, missing or incomplete SBOMs can slow clearance, affect launch timing, and make vulnerability response harder when issues show up.

For most teams, the best move is to use machine-readable CycloneDX or SPDX SBOMs so security checks can run automatically. That includes vulnerability scanning, CISA KEV matching, and VEX support. CycloneDX is often the best default for medical device security because it supports VEX natively. When you pair an SBOM with a VEX file, you can show which vulnerabilities are actually exploitable in the shipped configuration and which ones are not.

This matters even more because medical devices tend to stay in use for a long time. Many remain in service for 10 to 15 years, and device software is often built with 75%+ external components. ^[1] That’s a lot of moving parts to track over a long lifespan. So the SBOM should be updated with every release and tied directly to CI/CD, ISO 13485 configuration management, and the DMR. Put simply, SBOM upkeep belongs in release control, not in a forgotten folder with other paperwork.

Teams selling into more than the U.S. market also need to line up SBOM work with EU reporting rules. For global manufacturers, the EU Cyber Resilience Act adds vulnerability and incident reporting deadlines starting September 11, 2026. ^[1] If your process only covers FDA submission needs, you may find yourself scrambling later.

Use these four priorities as the 2026 SBOM checklist.

SBOM practice is more than a compliance checkbox. It helps teams spot real vulnerabilities before they reach patients, and it gives healthcare organizations the visibility they need to make informed decisions about every device on their network.

FAQs

How do I know if my device is a cyber device?

Under Section 524B of the FD&C Act, a medical device is a cyber device if it:

• contains software or firmware validated, installed, or authorized by the sponsor
• can connect to the internet or other networks, directly or indirectly
• has features that could expose it to cybersecurity threats

If you're not sure whether your device fits this definition, the FDA recommends getting formal clarification before you submit your application. That step can help you avoid delays in the review process.

What happens if my SBOM is incomplete or outdated?

An incomplete or outdated Software Bill of Materials (SBOM) creates major regulatory and day-to-day risks for medical device manufacturers. In a premarket submission, it can lead to an FDA Refuse to Accept notice or an Additional Information letter. And that can push product clearance back by 3 to 6 months.

It also makes vulnerability tracking and patching much harder. When that happens, legacy devices can stay exposed to known exploits for far too long. The result is more risk of misbranding, market withdrawal, and patient safety problems.

How can hospitals use SBOM data after purchase?

Hospitals use SBOM data after purchase as a living inventory that helps them manage the security of installed medical devices over a 10- to 15-year lifespan.

When that data is available in machine-readable formats like SPDX or CycloneDX, hospitals can use it for automated risk assessment, vulnerability monitoring, and patch or upgrade planning. That matters because these devices often stay in service for years, and keeping track of software components by hand can turn into a mess fast.

SBOM data also helps hospitals apply compensating controls for devices with known risks. Censinet RiskOps™ can support this by centralizing SBOM records, giving teams portfolio-scale visibility, and automating monitoring across third-party vendors and clinical devices.

Related Blog Posts

• FDA Cybersecurity Guidance: Key Updates for 2025
• SBOMs in Medical Device Labels: FDA Expectations
• SBOM vs Traditional Software Documentation: Key Differences
• SBOMs in Medical Device Lifecycle Management