Software Bill of Materials (SBOM) for Medical Devices: IEC 62304 and FDA Guide

Table of Contents

• Introduction
• What an SBOM Is — and Why Medical Device Software Needs One
• FDA Requirements: Section 524B and the Premarket Cybersecurity Guidance
  • Which devices qualify as cyber devices
  • The three statutory obligations
• SBOM Content: NTIA Minimum Elements and FDA Additions
• IEC 62304: where the SBOM lives in the software lifecycle
  • SOUP requirements as the SBOM content source
  • From SOUP management to a machine-readable inventory
• CycloneDX vs SPDX: Choosing a Format
• EU Requirements: MDR, MDCG 2019-16, IEC 81001-5-1 and the Cyber Resilience Act
• Building and Maintaining the SBOM: a Step-by-Step Process
• SBOM in Post-Market Vulnerability Management
• Common Audit Findings and How to Fix Them
• Frequently Asked Questions
• Conclusions

Introduction

An SBOM for medical device software is no longer a nice-to-have: for any device that meets the FDA’s definition of a cyber device, a machine-readable software bill of materials is a statutory premarket requirement, and under IEC 62304 the underlying data has always been there in your SOUP records — most manufacturers just never assembled it into a deliverable. The gap between “we manage SOUP” and “we can hand a reviewer a valid CycloneDX file” is exactly where submissions now get stuck. This guide covers what an SBOM must contain, how Section 524B of the FD&C Act and the FDA premarket cybersecurity guidance define the requirement, how the SBOM maps onto the IEC 62304 lifecycle, the EU picture, and how to build a process that keeps the SBOM accurate after release. It builds directly on our SOUP management guide for IEC 62304 and the IEC 62304 complete guide.

What an SBOM Is — and Why Medical Device Software Needs One

An SBOM is a structured, machine-readable inventory of every software component contained in a device: proprietary code developed in-house, open-source libraries, commercial off-the-shelf packages, runtime environments, and the transitive dependencies those components pull in. The concept is borrowed from manufacturing — no manufacturer would release a physical device without a bill of materials listing every part, supplier and revision — and applies the same discipline to software composition.

The reason regulators converged on the SBOM is simple arithmetic. Modern medical device software is overwhelmingly assembled rather than written: typical connected devices carry dozens or hundreds of third-party components, and industry analyses consistently find that the majority of the code shipped in a device was not written by the legal manufacturer. When a vulnerability such as Log4Shell or a critical OpenSSL flaw is disclosed, the only question that matters is “which of our devices contain the affected component and version?” A manufacturer without a current SBOM cannot answer that question in hours; one with a properly maintained SBOM can answer it with a database query. That difference is precisely what Section 524B, the FDA premarket cybersecurity guidance, and the EU’s cybersecurity expectations are designed to enforce.

An SBOM is therefore not a static submission artifact. It is generated during development, verified before release, filed with the regulator, referenced in labeling, and then continuously reconciled against vulnerability databases for the entire marketed life of the device. The complete lifecycle looks like this.

FDA Requirements: Section 524B and the Premarket Cybersecurity Guidance

The statutory basis is Section 524B of the FD&C Act, “Ensuring Cybersecurity of Devices”, introduced by Section 3305 of the Consolidated Appropriations Act, 2023 and effective for premarket submissions from 29 March 2023. Since 1 October 2023 the FDA applies a refuse-to-accept policy: a submission for a cyber device that lacks the required cybersecurity information, including the SBOM, can be rejected before substantive review even begins. The agency’s expectations are detailed in the premarket cybersecurity guidance — originally issued in September 2023, substantially revised on 27 June 2025 to add a dedicated section on Section 524B, and subsequently updated again under the title “Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions” to align with the Quality Management System Regulation. The current version and related resources are maintained on the FDA’s medical device cybersecurity page.

Which devices qualify as cyber devices

Section 524B(c) defines a cyber device through three cumulative conditions: the device includes software validated, installed or authorized by the sponsor; it has the ability to connect to the internet; and it contains technological characteristics that could be vulnerable to cybersecurity threats. The trap is the second condition. The FDA interprets “ability to connect to the internet” broadly — it covers intentional and unintentional connectivity through any means, including Wi-Fi, cellular, Bluetooth and Bluetooth Low Energy, and hardware interfaces capable of carrying an internet connection such as USB, Ethernet and serial ports. A device that is never intended to go online but carries a USB service port used for firmware updates is, in the FDA’s reading, capable of connecting and therefore in scope. In practice, very few software-containing devices fall outside the definition, and software as a medical device products are essentially always in scope. The obligation applies to 510(k), De Novo, PMA, PDP and HDE submissions, and — per the current guidance — also to premarket submissions for modifications to previously authorized cyber devices.

The three statutory obligations

Section 524B(b) imposes three requirements on the sponsor. First, a plan to monitor, identify and address post-market vulnerabilities and exploits in a reasonable time, including coordinated vulnerability disclosure procedures. Second, processes and procedures providing reasonable assurance that the device and related systems are cybersecure, including making post-market updates and patches available on a regular cycle for routine issues and as soon as possible for critical vulnerabilities. Third — the subject of this article — a software bill of materials covering commercial, open-source and off-the-shelf software components. The SBOM is not severable from the other two obligations: the vulnerability monitoring plan is only executable if the SBOM tells you what to monitor, and the patching commitment is only credible if the SBOM identifies which components have a support horizon. Reviewers read the three together, and inconsistencies between them are a recurring deficiency-letter topic.

SBOM Content: NTIA Minimum Elements and FDA Additions

The FDA anchors SBOM content to the framing published by the National Telecommunications and Information Administration in 2021. The NTIA baseline defines seven minimum data fields per component, and these are a true list worth stating precisely:

• Supplier name — the entity that creates or maintains the component
• Component name — as designated by the supplier
• Version of the component
• Other unique identifiers (e.g. CPE, PURL, SWID)
• Dependency relationship — which component includes which
• Author of the SBOM data
• Timestamp of SBOM generation

The FDA guidance then goes beyond NTIA. For each component, the agency expects information on the software level of support — whether the component is actively maintained by its supplier — and the component’s end-of-support date, because a component that will lose security maintenance during the device’s expected service life is a design input for your maintenance planning. In addition, the submission should include a component-level assessment of known vulnerabilities: which published CVEs affect the shipped versions, an evaluation of exploitability and patient-safety impact in the device’s context, and the controls or compensating measures applied where a fix is not (yet) implemented. This assessment is exactly where the SBOM connects to your ISO 14971 risk file and to your security testing program — the vulnerability evaluation methodology belongs with the practices described in our medical device cybersecurity testing guide. Finally, the SBOM itself must be machine-readable; a PDF table is not acceptable as the primary deliverable, although a human-readable summary in labeling — with instructions for accessing the machine-readable file — is expected as well.

IEC 62304: where the SBOM lives in the software lifecycle

IEC 62304:2006+A1:2015 never uses the term “software bill of materials” — the standard predates the vocabulary. But everything an SBOM contains is information that IEC 62304 already requires you to generate and control. A manufacturer with a properly implemented IEC 62304 lifecycle does not need to invent an SBOM process; it needs to formalize the output of processes it already runs. Two clause groups do the heavy lifting.

SOUP requirements as the SBOM content source

Software of unknown provenance is IEC 62304’s term for software not developed under the standard’s lifecycle — which covers essentially every third-party component in your SBOM. Clause 5.3.3 requires the manufacturer to specify functional and performance requirements for each SOUP item necessary for its intended use, and Clause 5.3.4 requires specification of the system hardware and software necessary to support SOUP operation. Clause 7.1.2 requires evaluation of SOUP as a potential cause of hazardous situations, and Clause 7.1.3 requires evaluation of the published anomaly lists for each SOUP item at the revision level actually used in the device. None of these obligations can be discharged without knowing exactly which components, at which versions, from which suppliers, are in the build — which is to say, without SBOM data. The relationship runs both ways: your SOUP list defines what the SBOM must contain, and the SBOM’s automated generation is the most reliable completeness check on your SOUP list. The practical mechanics of anomaly review and SOUP risk evaluation are covered in depth in our dedicated SOUP management article.

From SOUP management to a machine-readable inventory

IEC 62304 never uses the term SBOM, yet a manufacturer with a properly implemented software lifecycle already generates most of the SBOM’s content as a by-product of SOUP management and configuration management. The standard defines SOUP — software of unknown provenance — as a software item already developed and generally available that was not developed for the purpose of being incorporated into the medical device, or software for which adequate development records are not available. Every commercial library, open-source package and OS component in your SBOM is, by definition, SOUP under IEC 62304, and the standard’s SOUP clauses are the natural data source for the SBOM. The reverse is also true: if your SBOM contains components that never appeared in your SOUP evaluation, your IEC 62304 compliance has a hole.

The IEC 62304 clauses that generate SBOM data

Four clusters of clauses do the work. Clause 8.1.2 requires that configuration management identify every SOUP item by title, manufacturer and a unique designator — typically the version. This is, almost verbatim, the NTIA triad of component name, supplier and version, which is why the configuration management system, not a spreadsheet maintained by the regulatory department, must be the SBOM’s source of truth. Clauses 5.3.3 and 5.3.4 require the architecture activity to specify the functional and performance requirements each SOUP item must meet, and the hardware and software the SOUP item needs to function; these justify why the component is present and constrain which versions are acceptable. Clause 7.1.3 requires evaluation of the published anomaly lists of each SOUP item relevant to the release — the direct ancestor of the FDA’s known-vulnerability assessment, extended from functional anomalies to security advisories. And Clause 6.1 requires the maintenance plan to define how the manufacturer monitors feedback on SOUP, which is where post-market SBOM maintenance and vulnerability watching are anchored. The class assignment under IEC 62304 (A, B or C) shapes the rigor of these activities but not the SBOM obligation itself: the FDA expects the SBOM regardless of software safety class, as explained in more depth in our IEC 62304 complete guide.

One distinction to keep clean, because it recurs in audits: IEC 62304 covers verification of software, while validation of the overall software product arrives through IEC 82304-1, ISO 13485 design controls and IEC 62366-1. SBOM accuracy checks — completeness against the build, format conformance — are verification activities and belong in the verification records described in our IEC 62304 software verification and validation article, not in a validation report.

Keeping the SOUP register and the SBOM synchronized

The most common structural failure is maintaining two parallel inventories: a manually curated SOUP register in the technical file and an automatically generated SBOM from the build system, which drift apart within one or two releases. The robust pattern is a single component database, populated automatically by dependency-scanning of the build, from which both deliverables are rendered: the SOUP register view carries the IEC 62304 fields (requirements, evaluation rationale, anomaly review), while the SBOM export carries the NTIA/FDA fields in a machine-readable format. A gate in the release procedure should diff the current build’s component set against the approved register: any new or changed component blocks release until the SOUP evaluation is completed. That single control eliminates both the “undocumented SOUP” finding and the “stale SBOM” finding at once.

CycloneDX vs SPDX: Choosing a Format

Two machine-readable formats dominate, and both are acceptable to the FDA. SPDX (Software Package Data Exchange), stewarded by the Linux Foundation, is an international standard — SPDX 2.2.1 was published as ISO/IEC 5962:2021 — with historical roots in open-source license compliance, which shows in its rich licensing metadata. CycloneDX, originating in the OWASP community and standardized as ECMA-424, was designed from the start for security use cases: it natively models vulnerability data (through the companion VEX/VDR mechanisms), services, and even hardware and firmware components, which makes it a common choice for embedded medical devices.

For a medical device manufacturer, the practical decision criteria are three. First, tooling: your build ecosystem’s dependency scanners (npm, Maven, pip, Yocto, Zephyr and the commercial SCA platforms) typically export both formats, but verify that transitive dependencies and statically linked components are captured, not just declared top-level packages. Second, the consumer: hospital security teams and vulnerability-management platforms increasingly ingest CycloneDX for operational monitoring, while license-compliance workflows favor SPDX — many manufacturers generate both from the same internal database. Third, VEX support: an SBOM without a mechanism to communicate “this CVE exists in a shipped component but is not exploitable in our device” generates noise for every downstream consumer; CycloneDX handles this natively and CSAF/VEX documents can accompany SPDX. Whichever format you choose, fix it in your software development plan, validate exports against the format schema as part of release verification, and never hand-edit the generated file — corrections belong in the source database.

EU Requirements: MDR, MDCG 2019-16, IEC 81001-5-1 and the Cyber Resilience Act

The EU has no explicit SBOM mandate for medical devices today, but the direction of travel is unambiguous and notified bodies are already asking component-inventory questions in technical documentation reviews. The legal anchor is EU MDR Annex I: GSPR 17.2 requires software to be developed and manufactured according to the state of the art, taking into account the principles of the development lifecycle, risk management and IT security, and GSPR 17.4 requires manufacturers to set out minimum IT requirements in the information supplied with the device. MDCG 2019-16 on cybersecurity operationalizes these requirements across the lifecycle and expects control over third-party components — an expectation that is practically impossible to demonstrate without a component inventory, even if the guidance does not use the word SBOM.

The state of the art itself is now defined by IEC 81001-5-1, the health software security lifecycle standard harmonized with the IEC 62304 process framework, which requires manufacturers to establish and maintain an inventory of the software components in their products, including third-party and open-source elements, and to monitor them for emerging vulnerabilities throughout the support period. Since notified bodies increasingly treat IEC 81001-5-1 as the benchmark for GSPR 17.2 conformity, an SBOM-grade inventory has become a de facto EU expectation; our IEC 81001-5-1 cybersecurity guide covers the full standard.

The Cyber Resilience Act, Regulation (EU) 2024/2847, deserves a precise reading because it is widely misquoted. The CRA does require manufacturers of products with digital elements to draw up an SBOM in a commonly used machine-readable format, covering at least the top-level dependencies — but medical devices falling under the MDR and IVDR are excluded from the CRA’s scope, precisely because sector legislation governs them. The correct conclusion is not “the CRA requires an SBOM for my device”; it is that the CRA fixes the SBOM as the European baseline for software transparency, and manufacturers should expect MDR-side guidance and notified body practice to converge on the same expectation. Building the SBOM capability once, to the FDA’s more demanding specification, covers both markets.

Building and Maintaining the SBOM: a Step-by-Step Process

A defensible SBOM process has six steps, each anchored in an existing QMS element rather than bolted on. Step one: define ownership and scope in the software development plan — which products, which format, which tool generates the SBOM, and the rule that the SBOM covers the software as built, including OS-level and firmware components in embedded devices, not merely the application-layer dependency manifest. Step two: automate generation in the build pipeline, so that every candidate release produces an SBOM as a build artifact with a timestamp and the identity of the generating tool; manual compilation is the single largest source of incompleteness. Step three: enrich the raw output with the fields automation cannot know — supplier support level, end-of-support dates, and your dependency-relationship corrections — maintained in the component database shared with the SOUP register.

Step four: run the vulnerability assessment. Screen every component version against the NVD and supplier advisories, evaluate each hit for exploitability in the device’s actual configuration and for patient-safety impact through your ISO 14971 process, and record the disposition — patched, mitigated by compensating control, or not exploitable with rationale. Step five: verify and release. Verification checks are format-schema validity, completeness against the build’s resolved dependency graph, and consistency with the SOUP register; the SBOM then enters document control as a configuration item tied to the release, and the submission package (for FDA cyber devices) includes the machine-readable file plus the labeling summary with access instructions. Step six: maintain. Every software change — including a patch that only bumps a library version — regenerates the SBOM, and the post-market process consumes it continuously, which is the subject of the next section.

SBOM in Post-Market Vulnerability Management

The premarket submission is the least valuable thing an SBOM does. Its operational payoff comes after release, when a new CVE is published and the question is “which of our devices, in which fielded versions, contain the affected component?” With version-resolved SBOMs archived per release, that query takes minutes; without them, it takes an engineering investigation per product. The post-market cybersecurity plan required by Section 524B(b)(1) should therefore reference the SBOM explicitly: the monitoring procedure watches advisories for every component in the current SBOMs, triage uses the SBOM’s dependency data to determine reachability, and the coordinated vulnerability disclosure process uses VEX statements keyed to SBOM component identifiers to tell customers whether they are affected.

On the EU side the same mechanics plug into the MDR post-market system: security signals from component monitoring are post-market surveillance inputs feeding the PMS plan, PSUR and, where a vulnerability creates an unacceptable risk, the vigilance and field safety corrective action processes described in our EU MDR post-market surveillance guide. Two practical rules keep this system honest. First, archive the SBOM of every distributed release for the device’s full support lifetime — the currently shipping SBOM is useless for the installed base running version N-3. Second, close the loop into maintenance planning: when a component’s end-of-support date approaches, the IEC 62304 Clause 6 maintenance process must trigger a migration decision before the component becomes unpatchable, not after the first orphaned CVE.

Common Audit Findings and How to Fix Them

Across FDA deficiency letters and notified body software reviews, the same SBOM problems recur. The most severe is the incomplete inventory: the SBOM lists the twenty libraries the developers consciously chose and omits the two hundred transitive dependencies they pulled in, or omits the OS and firmware layer of an embedded device entirely — a reviewer who spots one known component missing from the SBOM stops trusting the whole file. Its twin is the contradiction finding, where the SOUP register in the IEC 62304 file and the submitted SBOM disagree on components or versions, undermining both documents at once. The remaining findings are gaps in the FDA-specific fields (no support-level or end-of-support data), staleness (an SBOM generated for the submission and never updated through subsequent patches), format failures (a PDF table where a machine-readable file is required), and missing generation metadata (no author, no timestamp, no tool identity), which makes the SBOM’s provenance unverifiable.

Frequently Asked Questions

Is an SBOM mandatory for FDA medical device submissions?

Yes, for cyber devices. Section 524B(b)(3) of the FD&C Act requires the sponsor of a premarket submission for a cyber device to provide a software bill of materials covering commercial, open-source and off-the-shelf components. The requirement applies to submissions from 29 March 2023, and since 1 October 2023 the FDA can refuse to accept a submission that lacks it. Given the FDA’s broad reading of internet connectivity — including USB and other hardware interfaces — most software-containing devices are cyber devices.

Does IEC 62304 require an SBOM?

Not by name. IEC 62304 requires SOUP items to be identified by title, manufacturer and unique version designator (Clause 8.1.2), their requirements to be specified (5.3.3–5.3.4), their published anomalies to be evaluated (7.1.3), and their feedback to be monitored in maintenance (Clause 6.1). Those records contain most of the SBOM’s data, so a compliant IEC 62304 process should be able to render an SBOM directly from its configuration management system.

What format should a medical device SBOM use?

A machine-readable format — in practice SPDX (ISO/IEC 5962) or CycloneDX (ECMA-424). The FDA accepts both. CycloneDX offers native vulnerability and VEX support, which suits security-driven use; SPDX is stronger on license metadata. Choose one in your development plan, generate it automatically from the build, and validate it against the format schema at release.

Does the SBOM need to include open-source and operating system components?

Yes. The statutory language explicitly covers commercial, open-source and off-the-shelf software, and the FDA expects the SBOM to reflect the software as built — including transitive dependencies, runtimes, and the OS or RTOS layer of embedded devices. An SBOM limited to top-level application libraries is the most common completeness deficiency.

Is an SBOM required in the EU under MDR?

Not explicitly today. However, GSPR 17.2 requires state-of-the-art IT security, MDCG 2019-16 expects control of third-party components, and IEC 81001-5-1 — the harmonized benchmark — requires a maintained component inventory with vulnerability monitoring. The Cyber Resilience Act mandates SBOMs for products with digital elements but excludes MDR/IVDR devices from its scope; it nonetheless sets the European transparency baseline that notified body practice is converging toward.

How often must the SBOM be updated?

At every software release, including patches that only change component versions, because the SBOM is a configuration item describing a specific build. Manufacturers should also archive the SBOM of every distributed version for the device’s support lifetime, so that post-market vulnerability triage can answer which fielded versions contain an affected component.

Conclusions

The SBOM sits at the junction of three systems you already run: IEC 62304 SOUP management supplies the component data, the FDA’s Section 524B framework defines the deliverable, and post-market surveillance consumes it for the life of the device. The manufacturers who struggle are those who treat it as a submission document assembled by the regulatory team the week before filing; the ones who sail through reviews generate it automatically from the build, keep it synchronized with the SOUP register through a single component database, enrich it with support-lifecycle and vulnerability data, and regenerate it at every release. Start from your configuration management records, close the gap to the NTIA and FDA field set, pick one machine-readable format, and wire the output into your vulnerability monitoring plan — in that order.

The IEC 62304 Software Lifecycle Documentation Package on MD Regulatory includes the software development plan, SOUP management procedure and register templates, configuration management SOP, and verification and maintenance planning documents — all aligned with IEC 62304 requirements and immediately deployable in an existing ISO 13485 quality management system, giving you the documented process backbone that a defensible SBOM depends on.

Related articles

• SOUP Management under IEC 62304
• IEC 62304 Complete Guide
• IEC 81001-5-1 Cybersecurity for Health Software
• Medical Device Cybersecurity Testing
• Software as a Medical Device (SaMD)
• IEC 62304 Software Verification and Validation