How to Prepare an SBOM for an FDA 510(k) Submission?

A Software Bill of Materials (SBOM) is an important part of cybersecurity documentation for medical devices submitted through the FDA's 510(k) pathway. An SBOM for 510(k) submissions identifies the software components within a device, including commercial, open-source, and third-party dependencies. For devices that meet the definition of a cyber device, Section 524B of the Federal Food, Drug, and Cosmetic Act makes providing an SBOM a statutory requirement. This guide explains what the FDA expects, which information to include, how to generate and validate an SBOM, and how to prepare it for a 510(k) submission.

Is an SBOM Required for an FDA 510(k) Submission?

Considering Section 524B(b)(3) of the Federal Food, Drug, and Cosmetic Act, an SBOM is required for applicable FDA premarket review of certain cyber devices.

A cyber device is defined by three requirements in Section 524B:

1. The device has software that is validated, installed, and/or authorized by the sponsor as a device and/or in a device.
2. The device can be used for Internet connection.
3. The device has technological features which may be susceptible to cybersecurity risks.

When a medical device satisfies all three, the manufacturer is required to consider the provisions of Section 524B as they submit an applicable 510(k).

These encompass Traditional, Special, and Abbreviated 510(k) submissions. These requirements are also applicable to relevant PMA, De Novo, PDP, and HDE submissions.

The statutory requirements come into force on 29 March 2023. They do not pertain to submissions earlier than that date. But a change to an already approved cyber device that necessitates a new submission may result in the new submission falling under Section 524B.

What happens if the device isn't considered to be a cyber device?

Section 524B of the statute may not be applicable. In its final guidance on cybersecurity risks for applicable devices, released by the FDA on February 3, 2026, however, the FDA advises that SBOM documentation is recommended for applicable devices with cybersecurity risks more broadly.

Manufacturers need to evaluate the device's regulatory status and the cybersecurity content in the documentation submitted for the device.

What Does the FDA Expect in an SBOM for a 510(k)?

In guidance dated 26 February 2026, FDA recommended that manufacturers submit an SBOM in a machine-readable format that should follow the minimum elements outlined in the NTIA document, Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM), published in October 2021.

The submission should also include software support information, end-of-support dates, and relevant known-vulnerability assessments.

Seven NTIA minimum SBOM fields

Each component should contain the following baseline information:

These fields help reviewers and manufacturers identify software components and understand how they are incorporated into the device.

Additional information required for FDA submission documentation

The FDA's current guidance recommends two additional details for every software component:

• Software support level: Whether the software is currently being supported or not, and if not, whether it has been discontinued, abandoned, or does not receive enough support.
• End-of-support date: The date the manufacturer of the component is likely to cease monitoring and maintenance support.

This information can be part of the SBOM or summarized in an addendum.

If the manufacturer is not able to deliver certain SBOM data elements, the FDA recommends describing why it is not available in the premarket submission.

How to Prepare an SBOM for a 510(k) Submission

To create an SBOM, software architecture, software development environment, third-party component information, and software build history are required. Here's a practical approach to preparation.

Step 1. Identify the device's software components

Firstly, understand the architecture of the device and the software that is included in the product.

This could be:

• Embedded operating systems and firmware.
• Manufacturer-developed applications.
• Commercial and licensed software.
• Libraries and packages available for free.
• Third-party frameworks and communication libraries.
• Direct and transitive dependencies.

A connected diagnostic device could include proprietary firmware, operating system, application interface, and third-party libraries for data communication, for instance.

The aim is to identify the software elements of the device submitted, not just the primary application.

Step 2. Collect software information from development and suppliers

Gather component names, suppliers, versions, identifiers, and dependency information from source repositories, package managers, build manifests, dependency lockfiles, and software suppliers.

If you utilize third-party software, ask the supplier for an SBOM or appropriate component documentation.

This is especially crucial if a third party develops the software and has no control over its development or maintenance, as is the case with off-the-shelf software.

Document any information that you cannot find on a component and determine if you need additional supplier data or analysis.

Step 3. Map direct dependencies and transitive dependencies

An SBOM should describe the relationships between software components.

A direct dependency is a part of software used by the device directly. A transitive dependency is something that is used by another dependency.

For example, device firmware may use a communication library that relies on a separate cryptographic package. Both components matter when assessing software vulnerabilities.

The relationship mapping will reduce the risk of hidden relationships being overlooked in the inventory.

Step 4. Generate a machine-readable SBOM

Generate an SBOM using a software composition analysis tool or an SBOM generation tool.

Common industry formats include:

• SPDX: Supports software component information, relationships, and licence.
• CycloneDX: Supports software component inventories, dependencies, and security information.

The FDA does not mandate one exclusive format. The important consideration is whether the selected format represents the required information and can be processed by the manufacturer's tools.

Step 5. Record software support and end-of-support information

Check the maintenance of each identified component.

Review support policies, release notices, maintenance notices, and end-of-life notices.

An end-of-support component will no longer receive security patches. The manufacturer should determine whether there is an unacceptable risk and whether it is necessary for the manufacturer to make an update, replacement, or provide adequate compensating control.

Step 6. Identify and assess known vulnerabilities

Compare the software inventory against recognised vulnerability sources, including:

• National Vulnerability Database (NVD).
• CISA Known Exploited Vulnerabilities (KEV) Catalog.
• Supplier security advisories.
• Relevant open-source project security notices.

Record the applicable vulnerability identifiers, affected component versions, discovery sources, and assessment methods.

The FDA recommends identifying known vulnerabilities associated with the device and its components. For each known vulnerability, manufacturers should provide a safety and security risk assessment that considers device and system impacts, along with relevant risk controls.

A vulnerability's CVSS score can support prioritisation, but it does not independently establish the risk to a medical device. The manufacturer must consider the actual component configuration, exposure, exploitability, and potential consequences for device safety and effectiveness.

Step 7. Validate the SBOM against the device release

Compare the generated SBOM before you submit it to the software that is in the actual version of the device being reviewed.

Verify component versions, dependency information, supplier information, identifiers, and missing entries. Use build records, package inventories and available supplier data to compare with the SBOM.

The Verify file is indeed the FDA submission and not an early development build.

How Should an SBOM Be Included in a 510(k) eSTAR Submission?

The FDA requires most 510(k) submissions to be provided through its electronic submission template, eSTAR, unless an applicable exemption applies.

The cybersecurity portion of the eSTAR includes questions and supporting attachment requirements that are pertinent to the device's cybersecurity profile.

In preparing the submission:

1. Determine whether the device meets the definition of a cyber device.
2. Complete the applicable cybersecurity questions in eSTAR.
3. Provide the SBOM in a machine-readable format.
4. Include software support and end-of-support information.
5. Attach relevant known-vulnerability and safety and security risk assessment documentation.
6. Ensure that the supporting answers and attachments are consistent with the device's actual software configuration.

The SBOM teams should not replace the threat model, risk assessment, security testing, or vulnerability management plan, but should distribute it in parallel with each of these documents.

Failure to respond to questions on the eSTAR documents with accuracy, or provide attachments that do not correspond to the questions on the eSTAR documents may result in a technical screening hold, the FDA states. Thus, before submitting, manufacturers should review the completeness and relevance of each attachment.

What Are the Common SBOM Mistakes in 510(k) Submissions?

An SBOM can include common fields and not give a good representation of the device's software.

Common problems include:

1. Transitive software components: Only packages used directly will be listed, which can leave out software components that are used indirectly.
2. Outdated package information: Vulnerability assessments might not detect vulnerable software if they are based on outdated information.
3. Not documented support information: If we do not identify unsupported or abandoned components, it is more difficult to assess the risks of the lifecycle of these components.
4. Ambiguous component identification: Varied naming standards from various scanning tools and vendors can make it challenging to correlate the components with vulnerability databases.
5. No vulnerability assessment: If you have known vulnerabilities, they are not listed, and their presence is not explained.
6. Outdated SBOM files: When the SBOM inventory does not sync with the version of software being reviewed, it can cause inconsistencies between what developers submit and the configuration of the actual product.

By comparing SBOM information to build records, supplier information, software inventories, and security testing results prior to submission, we can reduce these issues.

What Changed in FDA and SBOM Guidance in 2026?

There are two big things to note when it comes to SBOMs for medical device submissions. Two things stand out when it comes to medical device submission SBOMs.

I. February 3, 2026: FDA issued updated medical device cybersecurity guidance

The June 2025 version was replaced with the FDA's current final guidance. It will continue to support the machine-readable SBOM documentation with extra details of software support levels, end-of-support dates, and known software vulnerabilities, based on the NTIA minimum elements for SBOM release in October 2021.

For manufacturers filing 510(k) submissions, they should not rely on previous cybersecurity checklists, but instead refer to the version for the February 2026 submission.

II. July 29, 2026: CISA published updated SBOM minimum elements

The 2026 Minimum Elements for a Software Bill of Materials (SBOM) have been released by CISA, NSA, FBI, and international partners.

The new format adds new data elements and concepts, such as component hashes, licence data, SBOM tool information, and generation context. It also covers AI software, open-source software, and software-as-a-service.

For medical device companies, these enhancements can be used to enhance component identification and software supply-chain visibility.

It is, however, important to note that the new CISA framework is different from the current FDA submission recommendation. The FDA guidance for February 2026 still refers to the minimum elements from October 2021 (NTIA). CISA is not a new statutory FDA SBOM requirement, but a useful supplementary reference.

How Medysec Supports SBOM Preparation for Medical Devices

Medysec's medical device cybersecurity services cover the following SBOM-related activities:

1. SBOM authoring: Identification of software components, suppliers, versions, and dependencies.
2. Support assessment: Documentation of component maintenance status and end-of-support dates.
3. Vulnerability assessment: Identification of known vulnerabilities and evaluation of their potential impact on device safety and security.
4. Submission documentation: Connecting SBOM findings with cybersecurity risk assessments and other premarket evidence.
5. Postmarket maintenance: Supporting SBOM and VEX updates as software components and vulnerability information change.

SBOM for 510(k) Submission: Final Checklist

Before adding an SBOM to a 510(k) cybersecurity bundle, make sure:

• Applicability of Section 524B has been considered.
• The software identifies text parts.
• Someone records direct and transitive dependencies.
• The minimum NTIA data fields are included.
• The SBOM can be presented in machine-readable format.
• Documented software support levels / end-of-support dates.
• Security analysts have evaluated the known vulnerabilities.
• Appropriate safety and security risk assessments and controls exist.
• Component identifiers and versions have been checked.
• The SBOM is the same as the device release submitted.
• In eSTAR, relevant cyber security teams include responses and attachments.

Conclusion

Creating an SBOM for a 510(k) submission is more than just listing software packages. Manufacturers must identify the appropriate components, trace the relationships between components, create a support guide, review existing vulnerabilities, and ensure compatibility of stock with the device being reviewed.

If the cyber device is eligible, then the SBOM is a mandatory submission requirement under Section 524B. The guidance document from the FDA from February 2026 contains the latest recommendations for the information and supporting Vulnerability assessment that should accompany it.

A verified, machine-readable SBOM also gives manufacturers a useful starting point for postmarket vulnerability monitoring and software maintenance.

Need Help Preparing an SBOM for FDA 510(k)?

Get expert support with SBOM preparation, vulnerability assessment, and FDA cybersecurity documentation.

Speak with Our Experts →

Frequently Asked Questions

1. Is an SBOM mandatory for a 510(k) submission?

It requires that 510(k) submissions of qualifying cyber devices comply with Section 524B. The FDA also recommends SBOM documentation for devices generally where there is a cybersecurity risk.

2. Does the FDA require SPDX or CycloneDX?

No. The FDA recommends industry-standard machine-readable SBOMs. There are a number of options out there, including SPDX and CycloneDX, but neither is the only FDA-required format.

3. What are the seven minimum NTIA SBOM fields?

They are supplier name, component name, component version, other unique identifiers, dependency relationship, author of SBOM data, and timestamp.

4. Does the SBOM need vulnerability information?

The SBOM is a way of identifying software components. The FDA also separately advises describing all known vulnerabilities associated with the device and its software elements and to include the appropriate safety and security risk assessments and controls in the premarket submission.

5. Does FDA approval depend on the SBOM alone?

No. Part of the cybersecurity evidence for a qualifying device is an SBOM. The 510(k) review also takes into account information on safety and performance, as well as substantial equivalence. Having a full SBOM does NOT guarantee clearance.

6. Does an SBOM need to be updated after 510(k) clearance?

Manufacturers must keep up-to-date SBOM data as software changes on the devices and new vulnerabilities are identified. Additionally, there are continuing cybersecurity processes necessary under Section 524B for qualifying cyber devices.