A Guide to FDA's SBOM Requirements for Medical Devices (2026 Update)

María Eugenia Gómez -

Section 524B of the FD&C Act requires Software Bills of Materials for cyber devices. Most teams know they need one. Very few know how to actually create one that works.

The common approach: build the software, generate an SBOM before FDA submission, discover critical vulnerabilities in components you've been using for months, then spend months in remediation mode. By the time you're ready to submit, your timeline has increased significantly.

There's a better way. But it requires understanding what FDA actually requires versus recommends, why they want it, and how to build SBOM generation into your development process from day one.

The 2026 update aligned the cybersecurity guidance with the new Quality Management System Regulation (QMSR), which replaced the old Quality System Regulation (QSR) and incorporates ISO 13485. This matters for SBOM because it explicitly frames SBOM as part of configuration management under ISO 13485, not a standalone requirement.

Translation: SBOM requirements didn't get stricter. But the FDA made clearer that SBOM is part of your quality system, not separate paperwork.

Here's what most teams miss: for some devices, SBOMs are required. For others, they're recommended. The difference comes down to whether your device qualifies as a "cyber device" under Section 524B.

A cyber device meets three criteria: it includes software validated by you as the manufacturer, it has the ability to connect to the internet, and it contains technological characteristics vulnerable to cybersecurity threats.

The "ability to connect" phrase is where confusion starts. FDA is explicit: if your device has the technical capability to connect to the internet through any means at any point, it qualifies. This includes Wi-Fi, Bluetooth, USB ports, ethernet, or serial ports. Even if you never intended internet connectivity, if the capability exists, your device likely qualifies.

For cyber devices, providing an SBOM isn't best practice, it's a requirement under Section 524B(b)(3). Failure to provide it is a prohibited act under Section 301(q) of the FD&C Act.

What FDA Actually Requires

The NTIA minimum elements are table stakes: component name, supplier, version, unique identifier, dependency relationships, and SBOM author. The FDA wants more.

You need the software support level for each component. Is it actively maintained, in maintenance mode, or abandoned? You need end-of-support dates when known. And critically, you must identify vulnerabilities in CISA's Known Exploited Vulnerabilities Catalog, these are vulnerabilities actively being exploited in the wild.

For each known vulnerability, you must describe how it was discovered, provide safety and security risk assessments, and detail your risk controls. The SBOM must be machine-readable (SPDX or CycloneDX format) so it can be queried quickly when new vulnerabilities emerge.

Here's what teams often miss: your SBOM isn't just for FDA. You should make it available to users on a continuous basis. Healthcare facilities need this to manage cybersecurity risks within their own frameworks. When you update components, users need updated SBOM information.

The Right Way vs. The Way Most Teams Do It

Most teams select components based on functionality and developer familiarity, write code for months, then generate an SBOM for the first time during submission prep. That's when they discover a core library reached end-of-life six months ago, or a dependency has critical vulnerabilities, or licensing terms are incompatible with medical device distribution.

The better approach treats component evaluation as a gated decision before adding anything to your codebase. Check the National Vulnerability Database, GitHub Advisory Database, and CISA's Known Exploited Vulnerabilities Catalog. Verify support status and end-of-life timelines. Check licensing. Assess the supplier's security track record. Document this as part of your design rationale.

This isn't about when you generate the SBOM file. It's about when component security becomes part of decision-making.

The Hard Problems Nobody Talks About

Everything above assumes complete visibility into your software supply chain. In practice, you often don't have it.

Third-party software where vendors won't share SBOMs: The solution starts with procurement contracts. Before committing to a vendor's component, your agreement should require SBOM disclosure, not just their SBOM, but SBOMs for components they're using, plus commitments to notify you of vulnerabilities and provide security updates within defined timeframes. If a vendor refuses, that's critical risk information.

Deep dependency trees: Your SBOM must capture "upstream dependencies", the software your software depends on, and that your dependencies depend on. Automated tools can traverse these for common package managers, but they're not perfect. For critical paths where vulnerabilities could directly impact patient safety, manual verification is worth the effort.

Unknown support status: For open-source projects, commit frequency and issue response times serve as proxies for support level. But you may need to document status as "unknown" and make a risk-based decision about acceptability. If it's a critical component with unknown support that you can't replace, that's a risk you're accepting and documenting.

Components you can't replace: You're using a library with a known vulnerability, but no alternative exists, or replacing it requires fundamental architecture changes. You're looking at compensating controls: isolating the vulnerable component, adding authentication layers, implementing exploitation monitoring. Document these in your cybersecurity risk assessment. Communicate residual risk clearly in device labeling.

When you can't provide complete information: If you cannot provide complete SBOM information to FDA, you must justify why. This isn't a free pass, you need a compelling reason and the FDA will assess whether your inability creates unacceptable risk.

What This Actually Prevents

When Log4Shell was announced, teams without SBOMs spent weeks conducting code archaeology, checking every dependency, searching build configurations, hoping they didn't miss anything. Teams with SBOMs queried for Log4j, knew their status in minutes, and focused on remediation instead of discovery.

When a vendor announces component end-of-life, an SBOM gives immediate impact assessment. You know which products are affected and can plan migration as a scheduled update rather than an emergency.

When CISA adds vulnerabilities to its Known Exploited Vulnerabilities Catalog, your SBOM lets you assess impact immediately. These are vulnerabilities being actively exploited. Your response speed could prevent a security incident affecting patient safety.

Getting Started

For new devices, integrate SBOM generation from day one. Choose your format, set up tooling, establish component evaluation including CISA KEV Catalog checks, and make SBOM maintenance part of your definition of done.

For existing devices, start with automated tools to generate a baseline, then manually verify. Focus on components in critical paths. Document support status. Remediate anything in CISA's Known Exploited Vulnerabilities Catalog. Then establish ongoing maintenance so your SBOM stays current.

For cyber devices, remember: SBOM is a legal requirement under Section 524B(b)(3), not optional. For all other software-containing devices, FDA strongly recommends it as part of demonstrating safety and effectiveness.

The teams that handle SBOMs well don't see them as submission paperwork. They see them as operational intelligence that makes software more maintainable, risks more manageable, and FDA submissions more straightforward. Treat your SBOM as living documentation, not a compliance artifact.

Where This Is Headed

The February 2026 guidance update isn't the end of FDA's SBOM requirements. It's the beginning of a broader shift in how medical device cybersecurity is regulated.

By requiring SBOMs for cyber devices and tying them to ISO 13485 configuration management, FDA is moving from "tell us what's in your device" to "show us you can manage what's in your device throughout its lifecycle." This aligns with international regulatory trends. The EU's Medical Device Regulation has similar expectations. Other regulatory bodies are watching FDA's approach.

The teams that will thrive in this environment aren't the ones looking for minimum viable compliance. They're the ones who recognize that SBOM infrastructure solves real operational problems by faster vulnerability response, clearer supply chain visibility, easier security questionnaires, and better risk management.

Build your SBOM processes now while you have time to do it thoughtfully. The regulatory expectations will only increase, and retrofitting is expensive. The question isn't whether you need robust SBOM infrastructure. It's whether you build it proactively or reactively.