What Is a Software Bill of Materials (SBOM)? Complete 2025 FDA Guide

Beng Ee Lim
2 days ago
9 min read

Software Bill of Materials (SBOM) is now firmly on the FDA’s “must-have” checklist for any connected medical device. Since the agency’s grace period ended on 1 October 2023, reviewers have been quick to flag submissions that land without a complete SBOM—stretching review timelines for teams that haven’t locked this down.

Quick answer: an SBOM is just a detailed, machine-readable inventory of every piece of software inside your device—from in-house code to open-source libraries—along with version numbers, licenses, and any known security vulnerabilities. For Software as a Medical Device (SaMD) and other internet-enabled hardware, the FDA now expects that list in every 510(k), De Novo, or PMA so it can track and manage cyber risks across the product’s life.

This guide walks you through exactly what the agency wants to see in an SBOM—and the easily overlooked steps that still trip up many companies.

Why SBOM Failures Are the Hidden Killer of Connected-Device Companies

The Software Security Crisis FDA Won't Advertise

Cyberattacks on healthcare keep climbing.

A Sophos survey found a 94 % jump in ransomware incidents at healthcare organizations between 2020 and 2021—proof that software transparency is now a patient-safety issue, not just an IT headache.

The price tag is eye-watering.

IBM’s Cost of a Data Breach 2024 pegs the average U.S. healthcare breach at US $ 9.77 million—and that’s before you factor in recalls or regulatory penalties on the device side.

Regulatory heat is rising.

Since 1 October 2023, FDA reviewers have routinely issued Additional-Information (AI) letters when a connected-device submission lands without a complete, machine-readable SBOM—often stretching clearance timelines by several months. The agency has warned that starting 1 October 2025 it may refuse to accept cyber-device files that omit required SBOM data.

What "Software Bill of Materials" Really Means

SBOM provides complete transparency into software composition by documenting every component, library, and dependency used in medical device software. Think of it as an ingredient list that enables security analysis and vulnerability management.

The hidden complexity most companies miss: Modern medical device software often contains 200-500 third-party components, each with their own dependencies. A single vulnerability can cascade through multiple device functions.

SBOM serves as your software defense system enabling vulnerability identification, supply chain risk management, incident response coordination, and regulatory compliance documentation.

The 5 SBOM Mistakes That Derail Regulatory Submissions — and How to Avoid Them

1. Incomplete Dependency Documentation

The problem. Third-party code isn’t just what you import directly. In the 2025 OSSRA audit, 64 % of the open-source components in commercial codebases were transitive dependencies—pulled in automatically by other libraries.

Why it matters. FDA’s final cybersecurity guidance says an SBOM must show “commercial, open-source, and off-the-shelf software components,” and be “machine-readable … consistent with NTIA minimum elements,” which include full dependency trees.

Fix it. Let automated SBOM tools do the first pass, then manually verify embedded binaries, custom integrations, and build-environment packages before you submit.

2. Inadequate Vulnerability Assessment

The problem. Listing components without quoting their known CVEs triggers an FDA deficiency letter. The guidance requires you to attach “the safety and security risk assessment for each known vulnerability.”

Common slip-up. Relying on an outdated NVD mirror or skipping continuous monitoring.

Fix it. Pull CVE data at the moment of submission and set up weekly feeds afterward. You may use CVSS or another rubric—CVSS is recognized, not mandatory—but you must explain your scoring method.

3. Using The Wrong SBOM Format

The problem. Human-readable spreadsheets slow reviewers and break automated scans.

FDA’s expectation. Provide a machine-readable SBOM; the agency cites the NTIA baseline and notes that industry-accepted formats (e.g., SPDX, CycloneDX, SWID) meet the mark.

Fix it. Generate an SPDX or CycloneDX file straight from your CI/CD pipeline, then include the JSON/XML payload in your eSTAR or traditional submission package.

4. Treating the SBOM as a One-and-done Document

The problem. A static SBOM violates FDA’s total-product-lifecycle security expectations. When a new CVE drops, you need the current component list to assess impact.

FDA trigger. Section 524B(b) requires a plan to “monitor, identify and address” vulnerabilities post-market; the guidance reinforces continuous tracking.

Fix it. Tie SBOM generation to every released build and wire the output into your change-control process.

5. Forgetting The Regulatory Story

The problem. A machine-readable SBOM with no plain-language narrative leaves reviewers guessing about maintenance, monitoring and incident-response plans—delaying clearance.

Fix it. Add a short memo that:

Describes how the SBOM is generated and kept current.
Explains your vulnerability triage (e.g., CVSS ≥ 7 → 30-day patch).
Maps high-risk components to the device’s safety/efficacy claims.

How to Prepare a Robust SBOM for Software as Medical Device (SaMD)

SaMD-Specific SBOM Requirements

Modern SaMD products ship with hundreds of third-party packages and their hidden, “transitive” cousins. Starting in 2025 the FDA expects every connected-device file to include a machine-readable SBOM that lists all of those components and maps any known CVEs to patient-safety risk. Below is a practical eight-week playbook you can adapt to your own sprint cadence:

Step-by-Step SaMD SBOM Preparation

Phase 1: Complete Software Inventory (Week 1-2)

Scan source, binaries & containers for software components (top-level and transitive).
Document component versions, sources, and licensing information

Phase 2: Vulnerability Analysis (Week 3-4)

Pull fresh CVE data for every component.
Score each vuln (CVSS is the easiest recognised method).
Flag anything that could alter safety or performance.

Phase 3: SBOM Generation (Week 5-6)

Export in SPDX or CycloneDX JSON/XML.
Add a two-page human-readable summary explaining how you build, update, and monitor the SBOM.

Phase 4: Integration and Validation (Week 7-8)

Wire SBOM creation into every build pipeline.
Link it to change-control and patch-management workflows.
Dry-run a “new CVE found” drill to prove the process works.

Where the SBOM plugs into the wider SaMD cyber plan

Threat modelling: SBOM data feeds attack-surface charts and helps spot supply-chain vectors.

Security architecture: Component list shows where encryption, auth, and logging controls sit.

Post-market response: When a vulnerability hits, you already know which module—and which patients—are at risk.

SBOM Implementation Strategy That Actually Works

Start with Risk-Based Prioritization

Focus on components that directly affect device safety and effectiveness. Not all software components create equal risk - prioritize SBOM implementation for critical system functions first.
Class III and SaMD devices require comprehensive coverage while Class I devices can focus on externally-accessible components and known vulnerabilities.
Network-connected devices need enhanced documentation for communication protocols, encryption libraries, and remote access components.

Build Automated Systems That Scale

Manual SBOM creation fails at enterprise scale. Companies with multiple software products need automated generation integrated with development workflows.
Tool selection criteria include integration with existing development environments, support for FDA-accepted formats, and ongoing maintenance capabilities.
Continuous integration workflows that update SBOMs when software components change prevent documentation drift and compliance gaps.

Establish Ongoing Vulnerability Management

Static SBOMs become compliance liabilities quickly. New vulnerabilities affecting existing components require immediate assessment and response procedures.
Automated monitoring systems track security advisories, CVE databases, and vendor notifications affecting SBOM components with alert mechanisms for critical issues.
Response procedures must define timelines for vulnerability assessment, risk analysis, and remediation planning based on potential patient safety impact.

FDA Enforcement Reality: What Actually Happens

Inspection Targeting Strategy

Risk-based inspections.

The agency selects device plants using a risk-ranking model that weights product class, inspection history, and emerging safety signals. Cyber-related findings can bump a site higher on the list.

SBOM on the audit checklist—when your product is a “cyber device.”

Since the Cybersecurity in Medical Devices final guidance (Sept 27 2023) folded SBOM into Design Controls and CAPA expectations, investigators may ask to see:

your machine-readable SBOM (SPDX / CycloneDX / SWID)
records that show it’s kept current
evidence that CVE findings feed your CAPA system

The Additional-Information (AI) Letter Trap

What sets it off?

Missing or weak SBOMs—the top three deficiencies reviewers cite are incomplete dependency trees, no vulnerability analysis, and unclear maintenance plans.

Timeline impact.

FDA hasn’t published an average; real-world cases show AI exchanges can add months while teams scramble to rebuild their SBOM. After 1 Oct 2025 the agency can simply Refuse to Accept (RTA) submissions that omit required cyber data.

How to dodge it.

Include:

A full, machine-readable SBOM in an FDA-accepted format.
A two-page narrative explaining how you keep it current and how CVEs are triaged.
Cross-links to your threat-model and CAPA files so reviewers see the life-cycle loop.

Post-Market Escalation: From SBOM to Recall

Rapid impact assessment.

Guidance calls for a prompt SBOM-based check whenever a new CVE hits a component you ship. The faster you can pinpoint affected units, the less disruptive the field action.

Yes, FDA will pull the recall trigger for software vulns.

Recent cases—such as the Illumina sequencing-platform recall—show the agency using its authority when exploitable code could harm patients, and the SBOM is central to scoping the fix.

Warning-letter trend.

Letters now cite gaps in software verification and documentation; explicit SBOM language is still rare but increasing as §524B enforcement matures. Expect transparency failures to be treated as systemic QS violations.

SBOM Requirements By Cyber-Risk And Software Stack

Risk tiers —not device class —drive the depth of your SBOM

Cyber-risk tier	Typical devices	SBOM expectation
Low-risk (offline / no patient harm if hacked)	Stand-alone diagnostic apps, Class I wellness wearables	Full list of software components; high-level vulnerability scan
Moderate-risk	Class II connected monitors, many SaMD decision-support tools	Complete dependency tree + CVE mapping + plan for updates
High-risk	Life-support or therapy devices, any Class III cyber-device	End-to-end SBOM (build env., toolchains, drivers) with continuous CVE feeds, incident-response hooks

FDA’s 2025 guidance states plainly: “Documentation must correspond to the device’s cybersecurity risk level, not to its regulatory class.”

Match SBOM detail to your software integration layer

Layer	Extra items to capture
Embedded firmware	Processor-specific SDKs, RTOS libraries, secure-boot blobs
Connected device code	Communication stacks (BLE, Wi-Fi, TCP/IP), TLS/SSL libraries, remote-update agents
Cloud-linked systems	Server-side micro-services, data-processing pipelines, third-party APIs, IaC modules

The broader the attack surface, the more granular your SBOM needs to be.

Budget & Timeline Reality

Tooling. Commercial platforms range widely—e.g., Sonatype SBOM Manager lists at US $64 k / year for 500 SBOMs.
People. Most mid-size med-tech firms allocate 1–2 FTEs (security + DevOps) for ongoing SBOM and CVE triage.
ROI. A complete SBOM can shave months off review by avoiding Additional-Information letters, and helps dodge multi-million-dollar breach costs documented in IBM’s 2024 report.

Your SBOM Compliance Reality Check

Immediate Assessment Questions

Can you pull a complete, machine-readable SBOM on demand? FDA expects you to supply it promptly—think a day or two, not weeks— if investigators or reviewers ask.

Do you have automated feeds that flag new CVEs for every component you ship? Continuous monitoring is baked into §524B and the 2023 cybersecurity guidance.
Would your SBOM pass an FDA desk review without triggering an Additional-Information letter? Incomplete dependency trees, missing vulnerability analyses, and vague maintenance plans are the top reasons files bounce back.
Are your maintenance procedures robust enough for post-market surveillance and incident response? The law requires an end-to-end plan for monitoring, triaging, and patching vulnerabilities over the device’s life-cycle.

The 60-Day SBOM Readiness Sprint

Week 1-2: Complete software inventory including automated scanning and manual verification of critical components.

Week 3-4: Assess vulnerabilities affecting identified components and establish risk scoring based on patient safety impact.

Week 5-6: Generate comprehensive SBOM using FDA-accepted formats with human-readable regulatory narrative.

Week 7-8: Integrate SBOM generation into development workflows and establish ongoing vulnerability monitoring.

This timeline reveals whether your SBOM systems can withstand FDA scrutiny or require comprehensive remediation before regulatory submission.

SBOM: The Software Foundation That Determines Your Regulatory Future

SBOM compliance isn't just cybersecurity documentation—it's the software transparency foundation that determines whether your medical device reaches patients safely and your business survives FDA scrutiny.

Success requires automated implementation now, not reactive compliance after FDA requests additional information. Your software transparency capabilities determine whether innovation becomes regulatory approval or submission failure.

Ready to build SBOM systems that ensure FDA approval success?

Complizen's AI-powered platform helps medical device companies implement comprehensive software transparency controls that accelerate regulatory compliance and cybersecurity excellence.

Frequently Asked Questions

Q: What SBOM format does FDA require for medical devices?

FDA accepts multiple SBOM formats including SPDX, CycloneDX, and SWID tags. SPDX is the most widely adopted format with the broadest tool support for medical device applications.

Machine-readable formats are mandatory for automated vulnerability scanning, but human-readable summaries must accompany technical SBOMs for regulatory review.

Q: How detailed must SBOMs be for Software as Medical Device?

SaMD requires the most comprehensive SBOM documentation including all runtime components, development environment dependencies, build tools, and third-party integrations.

Vulnerability assessment must connect software security issues to potential impact on device safety, clinical performance, and patient outcomes.

Q: What tools can generate FDA-compliant SBOMs?

Commercial SBOM tools include Synopsys Black Duck ($15,000-50,000 annually), Snyk ($5,000-25,000 annually), and FOSSA ($10,000-40,000 annually).

Open-source alternatives include SPDX tools and CycloneDX generators, but require additional investment in implementation and maintenance expertise.

Q: How do SBOMs affect FDA submission timelines?

Proper SBOM preparation accelerates submissions by demonstrating comprehensive cybersecurity planning and software component management from the initial review.

Inadequate SBOM documentation triggers automatic additional information requests extending approval timelines by 3-6 months while companies scramble to gather missing information.

Q: What happens if we ignore SBOM requirements?

FDA will not approve software-containing devices without adequate SBOM documentation as of October 2023 enforcement implementation.

Post-market consequences include warning letters for cybersecurity compliance failures, mandatory recalls for security vulnerabilities, and increased inspection frequency.