Software Bill of Materials (SBOM): FDA 524B Guide

Reader task: Medical device regulatory engineers, Software as a Medical Device (SaMD) developers, and hospital clinical informatics security officers searching for software bill of materials need to satisfy FD&C Act Section 524B premarket submission mandates, include all seven NTIA minimum elements plus FDA lifecycle extensions, and select between SPDX and CycloneDX formats.

Short answer

A Software Bill of Materials (SBOM) is a structured, machine-readable inventory listing every proprietary, commercial, and open-source software component, version, and transitive dependency embedded in a software application or connected medical device. Under Section 524B of the Federal Food, Drug, and Cosmetic (FD&C) Act (21 U.S.C. § 360n-2) and the FDA’s September 2023 Premarket Cybersecurity Guidance, sponsors of ‘cyber devices’ must submit an SBOM conforming to the NTIA Minimum Elements (typically serialized in SPDX or CycloneDX) alongside IEC 62304 Software of Unknown Provenance (SOUP) documentation and component end-of-support disclosures.

What is a Software Bill of Materials (SBOM) and how is it used in clinical research and healthcare?

Modern medical devices, laboratory analytical instruments, and clinical research platforms rarely consist exclusively of first-party code. A single infusion pump, bedside patient monitor, or genomics pipeline typically incorporates dozens to hundreds of third-party open-source libraries, operating system kernels, cryptographic modules, and commercial software development kits (SDKs). Historically, when a critical zero-day vulnerability (such as Log4Shell or OpenSSL flaws) emerged in the National Vulnerability Database (NVD), hospital biomedical engineering teams and clinical trial sites had no visibility into which devices contained the vulnerable library.

An SBOM acts as a digital ‘ingredient label’ for software supply chains across two core healthcare workflows:

Premarket Regulatory Qualification: Medical device and SaMD sponsors generate an SBOM directly from their continuous integration/continuous delivery (CI/CD) build pipelines to document all third-party and open-source components—referred to as Software of Unknown Provenance (SOUP) in IEC 62304—as part of their Design History File (DHF) and FDA premarket cybersecurity submission.
Postmarket Vulnerability Management in Hospitals and Labs: Healthcare Delivery Organizations (HDOs) and clinical research networks ingest vendor-supplied SBOMs to map newly published Common Vulnerabilities and Exposures (CVEs) to specific networked medical devices and laboratory instruments without waiting weeks for manual vendor questionnaires.

What standards or regulatory requirements govern Software Bills of Materials?

1. NTIA Minimum Elements for an SBOM (Executive Order 14028)

Following Executive Order 14028 (Improving the Nation’s Cybersecurity), the National Telecommunications and Information Administration (NTIA) published The Minimum Elements for a Software Bill of Materials (SBOM) in July 2021. The NTIA baseline organizes requirements into three pillars: Practices and Processes, Automation Support, and Seven Baseline Data Fields that must be recorded for every component:

Supplier Name: The entity that creates, defines, and identifies the component.
Component Name: Designation assigned to a unit of software defined by the original supplier.
Version of the Component: Identifier used by the supplier to specify a change in software from a previously identified version.
Other Unique Identifiers: Standardized lookup strings used to correlate components with vulnerability databases, such as Common Platform Enumeration (CPE), Package URL (PURL), or Software Identification (SWID) tags.
Dependency Relationship: Characterization of how upstream and transitive components are included in the primary software artifact (at minimum stating that component X is included in software Y).
Author of SBOM Data: The entity that creates the SBOM metadata for the component (which may be the device manufacturer, an upstream supplier, or an automated analysis tool).
Timestamp: Record of the date and time the SBOM data was assembled.

2. FD&C Act Section 524B and FDA September 2023 Premarket Cybersecurity Guidance

Enacted via Section 3305 of the Consolidated Appropriations Act, 2023 (Public Law 117-328), Section 524B of the FD&C Act (21 U.S.C. § 360n-2) legally requires sponsors submitting premarket applications (510(k), De Novo, PMA, PDP, or HDE) for a cyber device to provide an SBOM covering all commercial, open-source, and off-the-shelf software components. A device is a statutory ‘cyber device’ if it (1) includes software validated, installed, or authorized by the sponsor, (2) has the ability to connect to the internet, and (3) contains any technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats.

In its September 2023 final guidance (Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions), the FDA requires sponsors to supply a machine-readable SBOM Containing the seven NTIA baseline fields plus two additional FDA-mandated lifecycle disclosures for each software component:

Software Level of Support: Whether the component is actively maintained and monitored for security patches by its upstream developer or is no longer actively supported.
End-of-Support (EOS) Date: The scheduled date on which upstream maintenance and security support for the component or operating system will terminate, enabling hospital procurement and risk teams to anticipate obsolescence risks under medical device cybersecurity programs and IEC 81001-5-1 health software lifecycle rules.

Machine-readable SBOM formats: SPDX vs. CycloneDX vs. SWID

Both NTIA and the FDA emphasize that an SBOM must be delivered in an interoperable, machine-readable format rather than an unstructured PDF or spreadsheet so automated tools can ingest it. The three NTIA-recognized formats differ in origin and primary engineering focus:

Format Standard	Maintaining Body & Standard ID	Supported Serializations	Primary Engineering & Healthcare Strengths
SPDX (Software Package Data Exchange)	Linux Foundation (ISO/IEC 5962:2021)	JSON, YAML, RDF/XML, Tag:Value, XLSX	International ISO standard with deep support for open-source software license compliance, copyright provenance, package relationships, and security advisories across operating systems and embedded Linux medical devices.
CycloneDX	OWASP Foundation (ECMA-424)	JSON, XML, Protocol Buffers	Purpose-built for application security and cyber supply chain risk analysis; natively models software, hardware/firmware (HBOM), cryptographic assets (CBOM), SaaS service dependencies, and embedded VEX exploitability statements.
SWID Tags (Software Identification)	ISO / IEC & NIST (ISO/IEC 19770-2:2015)	XML	Designed for endpoint software asset management and installed package discovery (deployed on disk alongside commercial executables and referenced in NISTIR 8060).

How does Software Bill of Materials integrate with EHR and health informatics workflows?

In hospital clinical engineering, research laboratories, and EHR integration environments, raw SBOM files generate significant alert fatigue unless paired with exploitability context:

Automated CI/CD Generation and Ingestion: Device manufacturers and clinical software developers run Software Composition Analysis (SCA) tools (such as Syft, Trivy, CycloneDX CLI, or commercial SCA scanners) during compilation to inspect package manifests and binary artifacts, emitting a signed SPDX or CycloneDX JSON file with every software release.
Correlation with NVD via CPE and PURL: Hospital security operations centers (SOCs) load vendor SBOMs into medical device security and asset management platforms, which continuously match each component’s CPE or PURL identifier against newly published CVEs in the NVD.
Filtering False Positives with VEX (Vulnerability Exploitability Exchange): A third-party library listed in a device’s SBOM may contain a known CVE, yet the vulnerable function may never be compiled, reachable, or exposed on the device’s network interface. Using machine-readable VEX documents (standardized by CISA, CycloneDX, and CSAF), the manufacturer communicates one of four standardized statuses for a specific CVE-to-product pair—not_affected (with a machine-readable justification such as vulnerable_code_not_in_execute_path), affected, fixed, or under_investigation—so hospital informatics teams focus remediation only on exploitable risks.

Common misunderstandings

‘An SBOM requires disclosing proprietary source code’: False. An SBOM lists component names, versions, suppliers, and dependency graphs (similar to an ingredient list on food packaging); it never contains or exposes proprietary source code or trade-secret algorithms.
‘Listing only direct (top-level) dependencies satisfies FDA Section 524B’: False. Both the NTIA minimum elements and the FDA’s September 2023 guidance require capturing transitive (nested) dependencies, or explicitly declaring ‘known unknowns’ where a closed-source commercial subcomponent does not yet expose its internal dependency tree.
‘Every CVE matching an SBOM component requires an immediate device recall or patch’: False. As recognized by FDA guidance and CISA VEX workflows, many CVEs present in third-party libraries are not exploitable within the specific architecture or operating environment of the medical device; manufacturers document non-exploitability via VEX advisories and premarket/postmarket risk assessments.

Frequently asked questions

What is software bill of materials and how is it used in clinical research and healthcare?

A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of all commercial, open-source, and off-the-shelf software components, libraries, and dependency relationships contained within a software product or connected medical device. In healthcare and clinical research, device manufacturers submit SBOMs in FDA premarket applications, while hospital biomedical engineering and health informatics teams ingest SBOMs to track Software of Unknown Provenance (SOUP) and assess CVE vulnerability exposure without reverse-engineering device firmware.

What standards or regulatory requirements govern software bill of materials?

In the United States, SBOM baseline structure is defined by the NTIA Minimum Elements for an SBOM (issued July 2021 under Executive Order 14028), which mandates seven core data fields and machine-readable automation formats such as SPDX (ISO/IEC 5962:2021), CycloneDX (ECMA-424), and SWID (ISO/IEC 19770-2:2015). For medical devices, FD&C Act Section 524B (21 U.S.C. 360n-2) and the FDA’s September 2023 Premarket Cybersecurity Guidance make an SBOM—plus component support levels and end-of-support dates—a statutory requirement for cyber device premarket submissions.

How does software bill of materials integrate with EHR and health informatics workflows?

Health informatics and clinical engineering teams ingest SPDX or CycloneDX SBOM files into asset management and Software Composition Analysis (SCA) platforms linked to the National Vulnerability Database (NVD). Paired with Vulnerability Exploitability Exchange (VEX) machine-readable advisories, teams correlate newly disclosed CVEs against connected medical devices, laboratory instruments, and FHIR-integrated EHR applications to prioritize patching or network segmentation.

Software Bill of Materials (SBOM): FDA Section 524B, NTIA Minimum Elements, SPDX, and CycloneDX