How to Build an FDA-Compliant Software Bill of Materials (SBOM)

FDA Software Bill of Materials (SBOM) identifies the software components used in a medical device, including proprietary, commercial, open-source, and third-party dependencies. Under Section 524B of the FD&C Act, manufacturers of qualifying cyber devices must provide an SBOM as part of their FDA premarket submissions. However, creating one involves more than listing software names and versions. Manufacturers must identify component dependencies, assess software support status, and maintain accurate records to support vulnerability management throughout the device lifecycle.

What Is a Software Bill of Materials (SBOM) in Medical Devices?

A Software Bill of Materials (SBOM) is an organized list of software components and the relationships they have with other software components included in a product. It defines the computer software that can be used for building and running a device and exhibits the relationship between various components.

Medical devices typically have many layers of software. Examples of this include an operating system, device-control software, communication libraries, encryption packages, and third-party components. They can be created in-house or from commercial vendors or open-source repositories.

An SBOM aids manufacturers in identifying these components and seeing if a newly published vulnerability impacts their devices.

SBOMs can help medical device manufacturers:

• Software transparency: Describes proprietary, commercial, open-source, and third-party software.
• Vulnerability Management: Identifies software that has been impacted by new vulnerabilities.
• Supply chain oversight: Provides visibility into software dependencies and their sources.
• Regulatory documents: Meets relevant FDA cybersecurity submission requirements.
• Postmarket maintenance: Assesses whether software updates and patches are needed by manufacturers.

The SBOM is not a security guarantee of a medical device. It contains information about the components to analyse and respond to software security risks.

What are FDA's requirements for an SBOM?

Section 524B(b)(3) of the Federal Food, Drug, and Cosmetic Act, mandates a software bill of materials for manufacturers of qualifying cyber devices.

A device is considered to be a cyber device if it:

1. Includes software validated, installed, or authorized by the sponsor as a device or in a device.
2. Has the ability to connect to the internet.
3. Contains technological characteristics that could make it vulnerable to cybersecurity threats.

These requirements apply to any premarket submission (510(k), Premarket Approval (PMA), De Novo, Product Development Protocol (PDP) and Humanitarian Device Exemption (HDE) submissions, as applicable, and supplements (if applicable).

Manufacturers are also required to create and maintain a plan for monitoring, identifying, and remediating postmarket vulnerabilities under Section 524B and processes to ensure device cybersecurity and to deliver relevant updates and patches.

The FDA has issued a Final Guidance on Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions on February 3, 2026, which offers guidance on what to include in the SBOM and accompanying documents. This replaces the June 2025 version.

The guidance suggests machine-readable SBOMs following the minimum elements outlined in an October 2021 document from the NTIA. It additionally suggests adding two extra aspects for every software component:

• The level of support for the component, for example, actively maintained, no longer maintained, and abandoned.
• The component's end-of-support date.

This information can be added to the SBOM or presented in an addendum. It is recommended that the SBOM is used in an industry accepted format.

What Information Should an FDA SBOM Contain?

An FDA submission should include a machine-readable SBOM containing the baseline information recommended by the FDA, along with software support and end-of-support details.

The NTIA's 2021 minimum elements provide the baseline for identifying components and their relationships. These include:

For medical device submissions, manufacturers should additionally document:

• Software support status and maintenance arrangements.
• End-of-support date for each component.

The 2026 CISA SBOM guidance introduces further fields and practices, including component hashes, licensing information, SBOM tool details, and generation context. These provide additional supply chain information, although they should not be confused with separate FDA statutory requirements.

How to Build an FDA-Compliant SBOM for a Medical Device

The creation of an SBOM requires a combination of software development, cybersecurity, quality assurance, regulatory, and supplier management. Here are some practical steps:

Step 1. Identify all software components

First, take a look at the full medical device software stack. Use of internally developed software, commercial software, open-source packages, operating systems, libraries, firmware, and third party dependencies.

Don't restrict to software that is made by the manufacturer. Upstream dependencies of proprietary/purchased software should also be taken into account.

For instance, a connected patient monitoring system can include:

• Embedded operating system.
• Device-control application.
• Libraries for communication and networking.
• Authentication and encryption packages.
• Third-party data processing elements.
• Cloud-connected application dependencies.

The inventory should include the software installed on the device and the software it relies on.

Step 2. Collect component information

After the components have been identified, gather information to describe each component.

Capture supplier, component name, version, unique identifiers, and dependencies. If available, provide package URLs (PURLs), Common Platform Enumeration (CPE) identifiers, or other identifiers used to identify software.

It using third party parts, ask suppliers for details and check with the software used in the device.

This a component is missing or the information is unknown, it should be noted instead of assumed.

Step 3. Map software dependencies

A flat listing of software components does not necessarily reveal how a vulnerability could impact a device.

Manufacturers need to capture transitive and relevant dependencies, that is, what components rely on what other components.

If an app on the device relies on a vulnerable open-source library which is also in use by a third party, for instance, the SBOM should help confirm that link.

It's crucial when trying to analyze weaknesses in indirect software dependencies that are not specifically chosen by the device manufacturer.

Step 4. Generate the SBOM in a machine-readable format

Generate a structured inventory using an existing SBOM generation tool or process.

The output shall be machine-readable so that it can be used to process by vulnerability management systems and compare it with software vulnerability databases.

The created SBOM should be compared with the actual software release. Automated tools cannot detect statically-linked libraries, bundles, modified libraries or components, or non-manifested dependencies.

There may be a need for manual verification and supplier information.

Step 5. Document software support and end-of-support dates

According to guidance from the FDA published in February 2026, the status of each software component (either supported or end of support) and its support end date should be documented.

Manufacturers should decide if components are:

• Which receives security updates and is actively maintained.
• Receiving limited maintenance.
• No longer supported.
• Without a known support provider or abandoned.

An unsupported component might be running, however if a vulnerability is identified, the manufacturer might not be able to get security fixes for it.

Manufacturers should consider replacing, updating, or otherwise mitigating risks where support is to end during the device's intended service life.

Step 6. Assess known vulnerabilities

Useful aspects of an SBOM for cyber security risk management come into play when comparing component information with vulnerability information.

Manufacturers need to keep an eye on the following sources:

• National Vulnerability Database (NVD).
• Common Vulnerabilities and Exposures (CVE).
• CISA Known Exploited Vulnerabilities (KEV) Catalog.
• Software supplier security advisories.
• Disclosure of relevant open source projects.

Just because a component is listed in a vulnerability report does not imply that the medical device itself is vulnerable.

The manufacturer is responsible for carrying out an evaluation of the affected software version, configuration, exposure, mitigations available, and possible effect on device safety and effectiveness.

Step 7. Validate and review the SBOM

If you submit an SBOM, ensure that it is a valid representation of the software release you are evaluating.

Check for:

• Missing or duplicate parts.
• Incorrect version information.
• Incomplete dependency relationships.
• Unidentified third-party software.
• Outdated supplier details.
• Information about support and end-of-support.
• Discrepancies between the SBOM and the real device configuration.

The last inventory should be checked by the cybersecurity and regulatory team to verify its match with the version of the device submitted.

Step 8. Maintain and update the SBO

Preparing a SBOM should not be the end of the process!

Manufacturers should determine if the SBOM should be updated when software components are replaced, updated, or removed. The new vulnerabilities discovered should also lead to the verification of affected software versions and dependency.

Keep version controlled SBOM records so that the manufacturer can determine which components were used for each version of the device.

Which SBOM Formats Do Medical Device Submissions Accept?

The FDA recommends machine-readable SBOMs and encourages industry-accepted formats. Two widely used options are SPDX and CycloneDX.

• SPDX (Software Package Data Exchange)

Maintained by the Linux Foundation

The SPDX is an international, open standard that has been ratified as ISO/IEC 5962:2021. It enables software component identification, dependency information and licensing. It is currently being maintained by major specification SPDX 3.0.

Official resource: SPDX specifications.

• CycloneDX

Developed by OWASP

CycloneDX is a machine readable BOM standard for software supply chain and cybersecurity. It is able to host component inventories and other security data such as vulnerability and VEX information. Supports: JSON, XML, Protocol Buffers.

Official resource: CycloneDX specification.

• Which format should manufacturers choose?

SBOM generation and exchange can be achieved for both formats. This should be based on the software development environment, available tools, compatibility with suppliers, and the information needed for vulnerability management.

There is no one format that is required by the FDA. It is important for manufacturers to select a format that includes the needed information, and can be read and understood by the users.

How Is an SBOM Used for Postmarket Vulnerability Management?

An SBOM enables postmarket cybersecurity by allowing manufacturers to determine if a vulnerability has been revealed that is likely to impact their devices.

Discuss a medical device that employs an open-source software library. A vulnerability is disclosed in a particular version of that library. If the software inventory is not available, the manufacturer may want to research a few software packages and supplier records to determine if the device is affected.

The manufacturer can update the SBOM and:

1. Determine if the affected component is part of the device.
2. Check installed software version and dependency.
3. Identify vulnerable functionality and know its accessibility.
4. Evaluate possible impacts to device safety and effectiveness.
5. Determine suitable mitigations or software updates.
6. Ensure the remediation and update of appropriate cybersecurity records.

The FDA's Section 524B requirements also include plans for coordinated vulnerability disclosure, vulnerability monitoring, and postmarket updates and patches.

An SBOM supports these activities, but it does not replace vulnerability assessment, penetration testing, or cybersecurity risk management.

What Are the Common SBOM Mistakes Medical Device Manufacturers Should Avoid?

The value of an SBOM can be quite modest if it does not contain all or accurate information.

Common issues include:

• Listing only direct dependencies: Missing upstream dependencies can leave software vulnerabilities unidentified.
• Using outdated versions: An SBOM that does not match the actual device release can lead to incorrect vulnerability assessments.
• Ignoring unsupported software: Missing support and end-of-support information makes long-term maintenance planning difficult.
• Relying entirely on automated tools: Automated generation may not identify every component, especially modified or statically linked software.
• Providing only a PDF: A non-machine-readable inventory limits automated processing and vulnerability matching.
• Treating the SBOM as proof of security: An SBOM identifies software components but does not establish that they are free from vulnerabilities.
• Failing to update records: Changes to software and dependencies should be reflected in the relevant inventory and release documentation.

These can be problems with the quality of the evidence provided prior to the device entering the market as well as the manufacturer's ability to address vulnerabilities once the device is in use.

What's New in 2026 with SBOM Requirements and Guidance?

On July 29, 2026, CISA, NSA, FBI and international partners published the 2026 Minimum Elements for a Software Bill of Materials.

The update is based on the NTIA's 2021 minimum elements and incorporates innovations in software supply chain practices.

Key additions include:

• Values of the components and hash functions relating to hash functions.
• Information about software components licenses.
• SBOM author signatures.
• SBOM version information.
• SBOM generation context.
• Name and version of a SBOM tool.
• The name and version of the SBOM data format.

The revised guidance also introduces a section on software dependencies, machine-readable formats, and includes dedicated considerations on software for AI and SaaS.

These additions can help medical device manufacturers better identify and assess vulnerabilities, especially if the device depends on third-party software, cloud services or AI-powered features.

Regulatory distinction: Guidance to the 2026 CISA is not a change to Section 524B, and does not automatically change any new field to an FDA requirement. In FDA's guidance from February 2026, the NTIA 2021 minimum elements remain its baseline recommendation for inclusion in SBOMs, along with component support and end-of-support information.

How Medysec Supports FDA SBOM and Cybersecurity Documentation

Medysec's medical device cybersecurity efforts include activities related to the preparation of an SBOM and the cybersecurity assessment process:

1. Software inventory: Identifying software components and third-party dependencies.
2. SBOM assessment: Analyzing component details and versions and their interdependencies.
3. Vulnerability assessment: Identifying vulnerabilities of known software components.
4. Review software support status: Analyzing software’s support information.
5. Documentation: Assisting in the preparation and review of relevant cybersecurity documentation.
6. Postmarket support: Assist in evaluating newly revealed vulnerabilities and keeping up to date with important cybersecurity information.

These activities help the manufacturer's documentation and risk management process. The medical device manufacturer is responsible for submission to regulators.

FDA Software Bill of Materials Checklist

Manufacturers should review the following prior to submitting an SBOM for a qualifying cyber device:

1. Determine any proprietary, commercially available, open-source and off-the-shelf software components that are involved.
2. Record component names, suppliers, versions, and identification numbers.
3. Create software dependency maps of direct and upstream dependencies.
4. Create the SBOM in a machine-readable format that is accepted by the industry.
5. Note software support and end of support dates.
6. Check components against relevant vulnerability databases.
7. Compare the SBOM to the device software release.
8. Check for missing, unknown and inconsistent component data.
9. Ensure SBOM records are kept in a version-controlled system.
10. Set up procedures to update the SBOM when software changes.

Is Your Medical Device Secure?

Check your medical device security risks and find the right steps to protect patient data and meet cybersecurity requirements.

Speak with Our Experts →

Conclusion

An FDA software bill of materials should correctly identify the software components that are included in a medical device, version, software suppliers, and software dependencies. For qualifying cyber devices, Section 524B makes providing an SBOM a statutory requirement, while the FDA's February 2026 guidance provides recommendations for its contents and supporting documentation.

To the manufacturers, preparing an SBOM should be a component of software development lifecycle (SDLC) and cybersecurity risk management practices. Having accurate component records, vulnerability information, and software support information assists in keeping submission evidence and addressing security concerns once a device is on the market.

FAQ

1. Is an SBOM mandatory for FDA medical device approval?

SBOMs are required for qualified “cyber devices” under Section 524B(b)(3). This covers open source software, off-the-shelf and commercial software. The requirement will apply to relevant FDA premarket submission for cyber devices.

2. Does the FDA require a specific SBOM format?

No. FDA has recommended machine-readable SBOMs and has encouraged industry accepted formats. It's common to use SPDX or CycloneDX.

3. Does an SBOM need to include open-source software?

Yes. Commercial, open-source and off-the-shelf software components are explicitly covered by Section 524B. The FDA guidance also provides a good description of a strong SBOM including upstream dependencies and manufacturers developed software

4. How often should an SBOM be updated?

The SBOM should be updated whenever software components are updated. It is important that manufacturers evaluate changes when software is updated, replaced or when new vulnerabilities are discovered. The maintenance process applicable should mimic the software lifecycle of the device and the overall cybersecurity risk management processes.

5. Is an SBOM enough to demonstrate medical device cybersecurity compliance?

No. An SBOM (Software Bill of Materials) is a piece of evidence of cyber security. Manufacturers will also have to respond to pertinent questions related to vulnerability management, cyber security processes, updates and patches, and documentation for risk management.

6. What is the difference between an SBOM and VEX?

An SBOM identifies the software components and their dependencies that are contained in a product. A Vulnerability Exploitability eXchange (VEX) provides a straightforward answer: “is this product vulnerable?” and provides information on the vulnerability status for the product, including whether it is vulnerable, not vulnerable, or under investigation.