The Software Bill of Materials (SBOM): What Every SaMD Manufacturer Needs to Know

Regulatory Guide | FDA Cybersecurity | SaMD Compliance | QMSR | SBOM 2026

If you are developing a connected Software as a Medical Device (SaMD), one regulatory requirement may already be determining whether your FDA submission succeeds or fails: the Software Bill of Materials, or ‘SBOM’.

In the past 18 months, SBOM compliance has moved from a niche technical concern to one of the most scrutinised elements of FDA premarket submissions. For SaMD manufacturers using AI and machine learning components, the stakes are even higher: complex dependency chains mean greater exposure to cybersecurity vulnerabilities.

Is an SBOM Required for FDA Submission?

Yes! For any device that qualifies as a “cyber device” under Section 524B of the FD&C Act, submitting an SBOM is a mandatory requirement, not a recommendation. The FDA will not accept a premarket submission whether a 510(k), De Novo, or PMA without it. A missing or incomplete SBOM is one of the most common causes of technical screening holds, which can delay review by months before a single substantive question is even asked.

The requirement applies to the vast majority of connected SaMD products. If your device can connect to the internet and contains software validated or installed by the manufacturer, you are almost certainly in scope. Here is what you need to know.

What Is an SBOM?

A Software Bill of Materials is a comprehensive, structured inventory of every software component that makes up your device or application. A SaMD developer must declare every component their device relies upon, including proprietary code, commercial off-the-shelf (COTS) software, open-source libraries, and all underlying dependencies.

For each component, a compliant SBOM must capture, at minimum:

• Supplier name: who produced the original software
• Component name: the name of the software element
• Version: the precise version in use
• Unique identifier: a hash or PURL that unambiguously identifies the component
• Dependencies: what the component in question relies upon
• Author of the SBOM data: who created the SBOM entry
• Timestamp: when the SBOM was generated

These attributes form what the US National Telecommunications and Information Administration (‘NTIA’) calls the “minimum elements” for a viable SBOM and they represent the FDA’s explicit baseline expectation.

In practice, the two dominant machine-readable SBOM formats accepted by the FDA are SPDX (maintained by the Linux Foundation) and CycloneDX (maintained by OWASP). Both are open standards; your toolchain will determine which is more practical for your development environment.

What SBOM Format Does the FDA Accept: SPDX or CycloneDX?

The FDA accepts both SPDX and CycloneDX as valid machine-readable SBOM formats. SPDX (Software Package Data Exchange), maintained by the Linux Foundation, is widely used in enterprise and open-source ecosystems. CycloneDX, maintained by OWASP, is increasingly favoured in security-focused environments due to its native support for vulnerability data and its tighter integration with common SCA tooling.

The choice between the two is primarily a toolchain decision. What matters most to the FDA is not the format itself, but whether all NTIA minimum elements are present and whether the SBOM is machine-readable, up to date, and traceable to your device configuration at the time of submission.

Why Has SBOM Become So Important Right Now?

Two factors have converged: the explosion of software complexity in medical devices, and a sharp regulatory shift by the FDA.

Modern SaMD products are built on vast stacks of third-party components. It is estimated that 75% or more of the software in a typical medical device comes from external sources: open-source packages, pre-trained model libraries, cloud frameworks, and vendor SDKs. Each of those components can carry known vulnerabilities, and without knowing exactly which components your device contains and which versions are running, you simply cannot identify, manage, or respond to those vulnerabilities.

On the regulatory front, the FDA has progressively tightened its position, culminating in a clear, up-to-date stance: the SBOM is no longer optional for connected devices.

SBOM and the QMSR: A Critical Intersection

The SBOM requirement does not exist in isolation. It sits directly within the quality system obligations introduced by the FDA Quality Management System Regulation (QMSR, 21 CFR Part 820), which came into force in February 2026. The QMSR aligns the FDA’s quality system requirements with ISO 13485, and its provisions directly govern how SBOM must be managed throughout the product lifecycle.

Four QMSR provisions are directly relevant to SaMD manufacturers building SBOM programmes:

• Design Controls: the QMSR requires full documentation and control of all device components. Without an SBOM, you cannot demonstrate to the FDA that you have a complete, verified picture of what your software contains.
• Supplier Controls: every third-party component in your SBOM is, in QMSR terms, a supplier input. You must evaluate and qualify each supplier, monitor version changes, and document how you manage updates or end-of-life notices.
• Change Control: any modification to a component listed in your SBOM (a dependency update, a library replacement, a version patch) constitutes a design change under the QMSR and must pass through your formal change control procedure before release.
• Post-Market Surveillance: when a new CVE (Common Vulnerabilities and Exposures) is published for a component in your SBOM, the QMSR’s post-market obligations are immediately triggered. You must assess the vulnerability, determine patient safety impact, and take documented corrective action where required.

Read our full article about QMSR.

Who Does This Apply To?

The SBOM requirement applies to any device that meets the FDA’s definition of a “cyber device” (Section 524B of the FD&C Act). A device qualifies as a cyber device if it:

• Contains software (including firmware) validated, installed, or authorised by the manufacturer
• Has the ability to connect to the internet
• Contains technological characteristics that could be vulnerable to cybersecurity threats

For the SaMD sector, this captures the majority of products. If you are building or already marketing any of the following, you are almost certainly in scope:

• AI imaging and diagnostic tools (radiology CAD, pathology analysis, retinal screening)
• Clinical triage algorithms (patient prioritisation, deterioration prediction)
• AI scribes and documentation tools (ambient clinical intelligence, coding assistants)
• Remote patient monitoring platforms
• Digital therapeutics and mental health apps
• Connected surgical planning software

The FDA submission pathways affected include 510(k), De Novo, PMA, PDP, and HDE submissions. Our MedTech FDA regulatory team supports manufacturers across all of these pathways.

Integration Into the Broader Submission Package

The SBOM does not stand alone. It is expected to accompany and cross-reference a wider set of cybersecurity documentation, all of which must be submitted through the FDA’s eSTAR process:

• Security architecture documentation and data flow diagrams
• Threat models
• Security risk management reports (aligned with ISO 14971)
• Vulnerability assessments derived from SBOM analysis
• The cybersecurity management plan for post-market surveillance

The FDA now requires around 12 standardised cybersecurity documents as part of each submission. Missing or incomplete documents can result in a technical screening hold before the submission is even reviewed substantively which is a costly delay that is entirely avoidable with the right preparation.

What Happens If Your SBOM Is Incomplete or Missing?

The consequences are immediate and cascading. At the premarket stage, a missing or materially incomplete SBOM will trigger a technical screening hold (TSH) under the FDA’s eSTAR process, meaning your submission is returned before substantive review even begins. The clock stops, your timeline slips, and you must resubmit from scratch once the deficiency is remedied.

Common SBOM deficiencies that lead to holds include: missing NTIA minimum elements (particularly unique identifiers or version numbers), an SBOM that does not reflect the actual device configuration at submission, or an SBOM present but disconnected from the vulnerability assessment and risk management documentation.

Post-market, the risks are different but equally serious. If a vulnerability is disclosed for a component in your device and your SBOM is out of date or absent, you may be unable to demonstrate that you assessed the impact, resulting in a potential QMSR compliance failure with reporting obligations to the FDA.

How to Approach SBOM: A Practical 6-Step Framework

A correctly produced SBOM should be an embedded part of your software development and quality management processes, not a document assembled at the last moment before submission. Here is a practical framework:

Step 1: Conduct a Full Software Inventory

Use automated Software Composition Analysis (SCA) tooling such as Syft, FOSSA, or Black Duck to scan your codebase, container images, and build artefacts. The goal is a complete, accurate picture of every component in your software supply chain, including transitive (indirect) dependencies.

Step 2: Generate the SBOM in a Machine-Readable Format

Export your inventory as a structured SBOM in either SPDX or CycloneDX format. The FDA accepts both. Ensure every NTIA minimum element is populated for each component: gaps in supplier name, version, or unique identifier are common rejection triggers.

Step 3: Map Vulnerabilities to Patient Safety Impact

Cross-reference your component list against the National Vulnerability Database (NVD) and vendor security advisories. For each identified vulnerability, assess exploitability and potential patient safety impact as part of your ISO 14971 risk management process. Unmitigated known vulnerabilities are a significant red flag for FDA reviewers.

Step 4: Integrate SBOM Into Change Control

Your SBOM must be kept current. Under the QMSR, any software update, dependency change, or component replacement constitutes a design change and must pass through formal change control before release. Each such change should also trigger an SBOM revision and a corresponding vulnerability re-assessment. Embed this into your change control procedure under your ISO 13485 QMS.

Step 5: Establish Post-Market SBOM Maintenance

The FDA’s cybersecurity expectations extend beyond market authorisation. Your post-market surveillance plan must describe how you will monitor newly disclosed vulnerabilities in your SBOM components, assess impact, and respond. This includes coordinated vulnerability disclosure where appropriate.

Step 6: Prepare Your Supporting Documentation

Compile the full cybersecurity documentation package: threat model, security risk management report, architecture diagrams, vulnerability assessment, and your plan of action. Each document must be internally consistent and cross-referenced to the SBOM. Inconsistencies across documents are a common cause of Additional Information (AI) requests from the FDA.

SBOM Requirements Beyond the US: The EU Cyber Resilience Act

For manufacturers with ambitions beyond the US market, SBOM obligations are not unique to the FDA. The EU Cyber Resilience Act (CRA) will require SBOMs for all products with digital elements sold into the EU market, with full implementation expected by December 2027. Vulnerability and incident reporting obligations under the CRA take effect from September 2026.

If you are building your SBOM capability now for FDA compliance, you will be well-positioned to extend that capability to meet EU CRA requirements avoiding the need to build from scratch when those deadlines arrive. This is also directly relevant to CE Marking strategies for SaMD products already navigating EU MDR requirements.

How Apotech Can Help

Our team has deep practical experience supporting SaMD manufacturers through FDA premarket submissions, including 510(k) and De Novo pathways. We understand the specific challenges SaMD manufacturers face and the common pitfalls in this process and we are on hand to help you avoid them early.

Whether you need support with:

• Preparing your first SBOM from scratch
• Remediating a deficient SBOM ahead of resubmission
• Building post-market surveillance processes that keep your SBOM current throughout your device’s lifecycle
• Aligning your broader cybersecurity documentation package for eSTAR submission
• Embedding SBOM maintenance into your QMSR-compliant quality management system, covering supplier controls, change control, and post-market surveillance

We provide targeted, hands-on support at every stage. Explore our SaMD, AI & Machine Learning services or review our case studies to see how we have supported similar programmes.

This article reflects regulatory guidance and published FDA requirements as of May 2026. Regulatory requirements evolve; manufacturers should always verify against the most current FDA guidance documents. This article does not constitute legal or regulatory advice.