SBOM Requirements for Connected Medical Devices: What FDA Expects and How to Stay Compliant

SBOM Requirements for Connected Medical Devices: What FDA Expects and How to Stay Compliant

If your medical device connects to a network, communicates via Bluetooth, integrates with a hospital system, or exchanges data with any external platform, the FDA now expects you to know exactly what software is running inside it — down to every open-source library and third-party component. That expectation has a name: the Software Bill of Materials, or SBOM.

As of March 29, 2023, the Consolidated Appropriations Act of 2023 amended the Federal Food, Drug, and Cosmetic Act (FD&C Act) to add Section 524B, formally titled "Ensuring Cybersecurity of Medical Devices." This legislation codified SBOM requirements into law for the first time, making them a mandatory element of premarket submissions for any device that meets the definition of a "cyber device." If you are submitting a 510(k), De Novo, or PMA for a connected device and you are not addressing SBOMs, your submission will be placed on hold.

What Is an SBOM and Why Does It Matter for Medical Devices?

An SBOM is a formal, machine-readable inventory of all software components within your device — including proprietary code, open-source packages, commercial off-the-shelf software, and third-party libraries. Think of it as a nutritional label for your device's software stack.

The reason FDA cares is straightforward: you cannot secure what you cannot see. Vulnerabilities like Log4Shell (CVE-2021-44228) devastated organizations globally because they did not know they were running the affected library. In a medical device context, that kind of blind spot is not just an IT problem — it is a patient safety problem. An SBOM gives manufacturers, healthcare delivery organizations (HDOs), and regulators visibility into the attack surface of a device so that vulnerabilities can be identified and remediated before they result in harm.

The Regulatory Framework You Need to Know

Several overlapping regulatory documents define current expectations. Understanding which ones apply to your submission is essential:

• Section 524B of the FD&C Act: The statutory authority. Requires manufacturers of cyber devices to submit a plan for monitoring, identifying, and addressing cybersecurity vulnerabilities post-market, as well as an SBOM for premarket submissions made on or after March 29, 2023.
• FDA Guidance — "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions" (September 2023): This is your primary operational document. It specifies that SBOMs should include component name and version, supplier name, unique identifiers, dependency relationships, and the SBOM author. FDA recommends formats such as SPDX (ISO/IEC 5962:2021) or CycloneDX.
• FDA Guidance — "Postmarket Management of Cybersecurity in Medical Devices" (December 2016): While predating the 2023 legislation, this guidance established the foundation for coordinated vulnerability disclosure and remains relevant to your ongoing SBOM management obligations.
• 21 CFR Part 820 / ISO 13485: Your Quality Management System must support SBOM generation and maintenance as part of design controls (21 CFR 820.30) and risk management. SBOM updates triggered by software changes must flow through your change control process.

What FDA Actually Expects in Your Premarket Submission

Based on the September 2023 guidance and real-world submission feedback, here is what a defensible SBOM submission looks like:

• Machine-readable format: SPDX or CycloneDX are the FDA-preferred formats. A PDF list of components is not sufficient for modern cybersecurity review.
• Complete dependency mapping: Transitive dependencies — the libraries your libraries depend on — must be included. This is where most manufacturers fall short. Tools like Syft, Black Duck, or Dependency-Track can automate this.
• Version specificity: Component versions must be precise. Ranges or approximate versions are not acceptable.
• Known vulnerability disclosure: Your submission should cross-reference your SBOM against the NIST National Vulnerability Database (NVD) and disclose any known CVEs, along with your risk assessment and remediation plan under your Software as a Medical Device (SaMD) risk framework or equivalent.
• SBOM maintenance plan: Describe how your SBOM will be updated when software changes occur, how you will monitor for newly disclosed vulnerabilities in existing components, and how you will communicate with customers (HDOs) when a relevant vulnerability is identified.

Common Mistakes That Trigger FDA Refusals to Accept

After the March 2023 effective date, FDA began issuing Refuse to Accept (RTA) letters for submissions that failed to address cybersecurity requirements — including SBOM gaps. The most frequent issues we see include:

• Submitting an SBOM for only the manufacturer's proprietary code while omitting open-source and COTS components
• Failing to include transitive (indirect) dependencies
• Providing no vulnerability assessment against the submitted SBOM
• Missing a postmarket monitoring and patching plan tied to SBOM versioning
• Treating SBOM as a one-time document rather than a living artifact within the design history file

Building SBOM Compliance Into Your Development Lifecycle

The most effective approach is to integrate SBOM generation into your CI/CD pipeline from day one rather than retrofitting it before submission. Automated tooling can generate a fresh SBOM artifact with every build, making it trivial to produce an accurate, up-to-date inventory at submission time. Pair this with a formal Software Composition Analysis (SCA) process within your QMS — one that assigns ownership, defines review cadence, and connects to your Corrective and Preventive Action (CAPA) process when vulnerabilities are discovered.

For teams operating under a Secure Product Development Framework (SPDF), as recommended in FDA's 2023 guidance, SBOM management should be a defined control within that framework with documented procedures, metrics, and executive accountability.

The Bottom Line

SBOM requirements are not a future consideration — they are a present compliance obligation for any connected medical device seeking FDA clearance or approval today. Manufacturers that treat SBOMs as a checklist item rather than a living security artifact will face submission delays, RTA letters, and postmarket enforcement risk. Those who build it into their development culture will move faster, respond to vulnerabilities more effectively, and demonstrate to FDA the kind of cybersecurity maturity that accelerates review.

At ADB Consulting & CRO Inc., we help medical device startups and established manufacturers build cybersecurity programs — including SBOM strategy, premarket submission content, and postmarket monitoring frameworks — that meet FDA's current expectations without slowing down your path to market.

Ready to make sure your connected device submission is cybersecurity-ready? Book a free discovery call with Andre Butler and the ADB Consulting team at adbccro.com. We will review your current SBOM posture, identify submission gaps, and build a clear action plan — at no cost to you.