How to Create an FDA-Compliant SBOM for 510(k) Submissions: Step-by-Step Implementation Guide

The U.S. The Food and Drug Administration (FDA) enforces strict cybersecurity requirements under Section 524B of the Federal Food, Drug, and Cosmetic (FD&C) Act. All manufacturers filing a 510(k) for a cyber device are required to submit a complete, comprehensive machine-readable Software Bill of Materials (SBOM). 

Section 524B(b)(3) of the FD&C Act makes it statutory, not advisory. In addition to the baseline fields in the NTIA, FDA requests that you indicate the level of support for each component, when each component will reach its end-of-support date, and any vulnerabilities you are aware of, including entries in the CISA Known Exploited Vulnerabilities Catalogue. Since February 2, 2026, the Quality Management System Regulation governs how you produce that document; your SBOM now traces to ISO 13485 design controls rather than a standalone premarket checklist. 

This guide provides software architects, embedded engineers, and regulatory affairs professionals with an engineering playbook for generating, validating, and submitting an FDA-compliant SBOM. 

The Gap Between Having an SBOM and Having a Compliant One

Almost all device teams that I meet already have an SBOM. Everyone checks the “regulatory box”, and the scanner generates clean JSON that is archived by the pipeline.

Next, the deficiency letter comes.

The problem is anything but tooling. All of the following generate accurate component inventories: Syft, cdxgen, and Trivy. The issue is that the FDA has four questions for which you have no scanner answers: Who provides you this component? How long will they support it? What are the known weaknesses with it? How does your inventory of this relate to your risk file?

Why FDA Requires SBOMs

Through this requirement, FDA will be able to evaluate software supply chain security threats and provide visibility into the software supply chain for the product life cycle. SBOMs must include commercial off-the-shelf (COTS), open-source, and off-the-shelf (OTS) software components for all cyber devices as required by Section 524B(b)(3). 

SBOMs provide FDA reviewers with a means to identify all software components in the device, to determine vulnerability exposure using CVE mapping, to assess the maturity of the manufacturer’s software supply chain, to ensure the ability to monitor the device after it goes on market, and to ensure the capability to disclose vulnerabilities. Under QMSR, the FDA considers cybersecurity to be device safety: SBOMs don’t have to be snapshots as of a specific point in time before submission, but need to be maintained continuously.

How the SBOM became a Statutory Requirement

The Food and Drug Omnibus Reform Act, 2023 (Section 3305 of the Consolidated Appropriations Act, 2023) is a section added to the FD&C Act that requires Section 524B, Ensuring Cyber Security of Devices. It makes three demands of the sponsors of cyber devices:

• Provide a proposal for postmarket vulnerabilities and exploits monitoring, identification and mitigation, including coordinated disclosure of vulnerabilities.
• Design, develop and maintain processes to ensure a reasonable level of cybersecurity of the device and associated systems; and make post-market updates and patches available.
• Supply SBOM for commercial, open-source and off-the-shelf software components.

The filing requirements are those that are attached to the submissions filed on or after March 29, 2023. Until October 1st, 2023, FDA used its discretion, but then it paused. The second layer most regulatory teams overlook is a failure to comply with 524B(b)(2) in section 301(q) of the Act – this is a “prohibited act”.

What constitutes a “cyber device”?

There are three tests under Section 524B(c). It has software that has been validated, installed or authorized by the sponsor, can be connected to the Internet and has characteristics that may present a risk to cyber threats.

FDA interprets the second test broadly — devices that make intentional or unintentional connections, by any means. Those include Wi-Fi, cellular, Bluetooth, Ethernet, USB and serial ports. Before the other pieces of writing, write a one-page classification memo. Identify the tests that your device passes, provide the supporting evidence and get your regulatory lead to sign it.

What FDA Actually Expects For Core Technical Criteria for SBOM Compliance

The FDA’s expectations for software inventory are based on the Cybersecurity and Infrastructure Security Agency (CISA) and National Telecommunications and Information Administration (NTIA) Minimum Elements for a Software Bill of Materials.

An FDA-compliant SBOM must meet 3 key architectural requirements:

1. Data Fields

Each component entry is required to have seven fields:

• Supplier Name: The name of the supplier, usually the primary developer, the community or the commercial vendor, of the component (e.g., The OpenSSL Project).
• Component Name: The actual name of the module or library (e.g., openssl).
• Version String: The version or build number, such as version 3.0.12.
• Other Unique Identifiers: Machine-resolvable strings, such as Package URL (PURL) and Common Platform Enumeration (CPE).
• Dependency Relationship: Any explicit structural relationship between modules (e.g., DeviceApp is-parent-of libcurl).
• A person or program that created the SBOM data.
• Timestamp: Exactly when and at what time the file was created (in ISO 8601 format).

2. Automation and Machine Readability

Documents that can be read by humans do not meet FDA validation. The SBOM must be generated from standard and machine-readable data formats:

• OWASP CycloneDX (v1.4, v1.5, or v1.6): Formatted as .json or .xml.
• SPDX (v2.2 or v2.3), Linux Foundation: .json, .spdx.json, .xml.
• Software Identification (SWID) Tags: Structured XML tags, embedded in binary distributions.

3. Depth and Operational Practice

The FDA is in need of an in-depth dependency resolution. Your SBOM should include direct dependencies (the software that you actually link to) and also transitive dependencies (those that your direct dependencies link to). Also, this file should be updated and archived on a regular basis if there are changes to the software build.

Step-by-Step Implementation Guide: Building an FDA-Compliant SBOM 

Phase 1 — Map Every Software Layer

Reviewers compare your SBOM against your architecture views.

Most inventories are broken down into two categories. Transitive dependencies affected the vast majority of Log4Shell attacks, but were not manifested when the attacks were launched, catching them when they’re generated from lockfiles or built artifacts. Statically linked code no trace of a package manager detected using binary composition analysis, plus a single audit of third_party/, vendor/, and submodule directories.

Phase 2 — Choose a Format, Pin the Version

FDA references both SPDX and CycloneDX and mandates neither.

Use CycloneDX where vulnerabilities are what matter, and/or when ISO compliance or license provenance are important. Then make sure to add the auditable schema version into the procedure, such as “CycloneDX 1.6 JSON”.

Phase 3 — Generate From the Build

Generate within the pipeline, using the same inputs that will generate the shipping artefact. This one decision eradicates most accuracy defects. Use Syft, cdxgen for multi-language trees, INHERIT += “create-spdx” for Yocto, native plugins for Java/.NET/npm/pyton and binary composition analysis of firmware. In the same phase belongs Software Composition Analysis, which is the identification of third-party software components that are compared to vulnerability databases, providing automation.

Phase 4 — Enrich What Scanners Cannot Know

Scanners send out a name, version, and sometimes a purl. You provide a unique identity of the supplier, support status, end-of-support date, SPDX license identifier, and a hash, using the SHA-256 algorithm, that binds the entry to an artefact.

Include the field that most teams don’t fill: specify each component and its role in the security-critical functions: authentication, cryptography, secure boot, update mechanism, network communication, patient data handling.

JSON

“properties”: [

  { “name”: “fda:supportStatus”,  “value”: “actively-maintained” },

  { “name”: “fda:endOfSupport”,   “value”: “2026-09-07” },

  { “name”: “fda:deviceFunction”, “value”: “cryptography;tls-communication” }

]

Phase 5- Reconcile against SOUP

The IEC 62304 (Software 62304) specifies a list of SOUP 3rd party software which is not developed by you in your own controlled process. SBOM is required in Section 524B. Each is owned by a different team, updated on different cycles and never compared.

Create the SOUP list of the SBOM filtered by third-party origin. Write a release gate script for the diff. An SBOM component not in a SOUP means the build gap; a SOUP item not in the SBOM means the documentation gap. 

Phase 6 — Validate, Sign, Store

Perform four gates that fail the build, on each of which perform schema validation, empty supplier strings pass schema validation, and there is a reconciliation with the shipped image as well as semantic checks to ensure that purls resolve and there are no version wildcards left.

Then sign. Use Sigstore’s cosign (detached HSM signature) or CycloneDX’s enveloped signature to bind the SBOM to the artefact digest. Go for SLSA level 2 or 3 for the pipeline: SLSA states how to create the artefact; the SBOM describes what was used to create it. Both are not just about a dependency because SolarWinds was a build system.

Place in a versioned artefact repository, maintain for the life of the device and link to the design history file for each version.

Phase 7 — Package for eSTAR

All 510(k) submissions have used eSTAR since October 1, 2023, under MDUFA V. The template is focused on structure, not substance a technically sufficient SBOM will pass the template and fail at the review step. 

Name files unambiguously: SBOM_DeviceName_SW-v4.2.1_CycloneDX-1.6_2026-07-26.json.

Automating the Pipeline

Maintaining SBOMs manually takes 20-60 hours of engineer time per release, and they tend to get out of sync with the binary during a sprint. Automation can make it take minutes and be reproducible.

text

Commit → Build → Generate SBOM → Enrich → Validate (fail on error)

       → SCA scan (CVE, CWE, CVSS, EPSS) → Apply VEX

       → Policy gate (KEV present? unmitigated CVSS ≥ 7?)

       → Sign → Publish to artifact repo + Dependency-Track → Release

This is natively supported by GitHub Actions, GitLab CI, Azure DevOps, Jenkins, and JFrog. OWASP Dependency-Track is a tool for continuous monitoring of a portfolio.

• Deliberately set the boundary: automate the generation and validation; maintain enrichment and VEX authoring under human review. Exploitability justifications created by the tools do not stand up to audit. Software tool validation also includes software tools that generate regulatory records. Keep a record of intended use; perform a protocol on reference use of known composition.
• Finding prioritizing: CVSS is damaged if exploited; measures severity. EPSS is published by FIRST and has estimates of exploitation probability within 30 days. CWE categorises the root cause of the weakness, which will give rise to secure coding fixes. Vulnerabilities that are currently being exploited are listed in the CISA’s KEV Catalogue. For impact, use CVSS; for urgency, use EPSS; as an override, use KEV.

Mistakes That Generate Deficiency Letters

These are some common technical issues that cause FDA holds and rejections: 

• Version imprecision. There is no CVE database for 3.x or the latest.
• Blank supplier fields. Scanners output empty strings, and schema validation doesn’t complain.
• Firmware omission. A scanner detected 60 components, while the device has 400.
• Direct dependencies only. When the maximum graph depth is 1, the tool is not performing transitively.
• There is an SOUP and SBOM contradiction. There is a SOUP and SBOM contradiction. No recon, no reconciliation.
• CVEs without VEX. The reviewer took the burden of your analysis.
• Missed support end-of-support dates. The most frequently blanked-out item in the FDA-specific section.
• Self-contradictory documentation. This test report is for v4.1.8 with the corresponding version of SBOM, which is v4.2.1.
• PDF in place of machine-readable JSON.

The greatest loss and the least facilitation come from internal contradictions. Have one person compile the software version reference for each software version of the software description, architecture views, threat model, SBOM, vulnerability assessment, test reports, and labelling prior to filing. I can’t run that sweep without finding 3 inconsistencies.

Best Practices Checklist for 510(k) SBOM Preparedness

Review your SBOM before submitting your eSTAR package to the FDA with this checklist:

Produce an OWASP CycloneDX (v1.4+) or SPDX (v2.2+) manifest.

• Printed file in the form of raw, machine-readable .json or .xml.
• The presence of all 7 CISA/NTIA Minimum Data Elements has been verified.
• Added explicit PURL: CPE string for each 3rd party package.
• Firmware, drivers, bootloaders, RTOS, and OS are all captured.
• Changed every string identified as “UNKNOWN” or “TBD” to build/version tags. 
• The scanned final SBOM was checked with NVD and CISA KEV databases.
• Produced matching VEX statements for all found CVEs
• A document was produced that confirmed alignment of VEX files with ISO 14971 Risk Assessment. 
• Continuous re-generation inside CI/CD automated. 
• Signed the master manifest digitally with Sigstore, Cosign, or PKI 

Real-World Implementation Examples 

Case Study: U.S. Healthcare Company

A healthcare company in the United States had an RTA decision issued for submission of a 510(k) for incomplete SBOM documentation. The initial SBOM was a 7-page Excel spreadsheet with no transitive dependencies, embedded firmware and no vulnerability mapping. The company automated scanning and identified 340 components in the SBOM instead of 47 as per the original, converted the SBOM to machine-readable CycloneDX format with all NTIA minimum elements, added CVE data and CISA KEV references, generated a 3-page human-readable explanation of SBOM generation and postmarket monitoring, and properly uploaded the SBOM to the eSTAR cybersecurity sections. Submitted the 510(k) for FDA clearance within one month of resubmission without further cybersecurity questions.

Case Study: European Medical Device Manufacturer

A European medical device business had submitted an Excel SBOM for a 510(k) submission. A European medical device company had submitted an Excel SBOM for a 510(k) submission. FDA made an RTA decision on the non-machine-readable format. The team used Syft to convert Excel to CycloneDX, validated the schema and NTIA elements, added vulnerability mapping and VEX documents, integrated SBOM generation with the CI/CD pipeline and created detailed process documentation. Resubmission was cleared by FDA in 4 weeks, and the 3-month delay from original submission negatively affected market launch plans.

Regulatory Outlook: Updates and beyond for 2026

Regulatory requirements for transparency of the medical device supply chain are continuing to evolve as more AI, machine learning, and cloud-edge functionality is added to the architecture of medical devices.

• AI/ML Software Bills of Materials (AIBOM): FDA is investigating how to incorporate the ability to see the model training frameworks (e.g., TensorFlow, PyTorch runtimes), lineage of the training datasets, and model weight artefacts in the CycloneDX manifest for devices using AI/ML algorithms.
• Post-Quantum Cryptographic (PQC) Inventory: With the future of post-quantum security in mind, regulators are urging manufacturers to list cryptographic primitives, cypher suites, and key-exchange algorithms right inside their SBOMs.
• Dynamic SBOM endpoints for cloud-connected SaMD: Static point-in-time files are moving to real-time cloud supply chain updates via API-based SBOM endpoints.
• The minimum elements of CISA will be determined. Closed comment on 2025 draft on October 3, 2025. It adds component hash, license, tool name and generation context information to minimal elements; introduces a new category for Known Unknowns: ‘unknown’; ‘redacted’; ‘not applicable’; renames ‘Supplier’ to ‘Software Producer’; replaces ‘Depth’ with ‘Coverage’. Create these fields at this time.
• AI elements are coming into play. On May 12, 2026, CISA and its G7 partners released the Software Bill of Materials for AI – Minimum Elements, which complement the general elements. In addition to the traditional dependencies, teams developing AI/ML-powered devices should monitor the provenance of models, their associated data sets, and their training.
• The need for a unified approach is growing worldwide. SBOMs are required for market access by the EU Cyber Resilience Act, which is supported by the TR-03183-2 from Germany’s BSI. The FDA, the CRA, and hospital procurement are increasingly being served by a single well-built program.

Qualysec’s Way of Generating FDA-Compliant SBOM Documentations

Creating an FDA-compliant Software Bill of Materials and embedding it into your Secure Product Development Framework (SPDF) demands a lot of cybersecurity expertise and understanding of FDA regulations. One uncategorized component, missing CPE or unmitigated CVE can result in regulatory delays and market access.

Qualysec Technologies is a CREST-accredited cybersecurity firm specializing in human-led, AI-powered penetration testing and regulatory compliance support for medical device manufacturers. They help medical device engineering and regulatory teams navigate Section 524B expectations through:

• Automated SBOM Implementation & Validation: Creating CycloneDX/SPDX pipelines throughout the source code, RTOS and embedded firmware stack.
• Medical Device Penetration Testing: CREST-accredited penetration testing of both hardware, firmware and software to meet FDA submission requirements.
• Cybersecurity Gap Analyses for FDA 510(k): Threat modelling, VEX files and risk management documentation review to prepare for eSTAR.

Frequently Asked Questions (FAQs)

Does FDA require SBOMs in CycloneDX or in SPDX?

The FDA has received feedback on machine-readable SBOM formats (such as SPDX, CycloneDX, and SWID tags) that include the full set of CISA Minimum Elements and directly reference device vulnerability management documentation. The flat formats (PDF/Excel) are not compliant.

What is the difference between SOUP and SBOM when submitted to the FDA?

Software of Unknown Pedigree (SOUP) is software that is produced by third parties or off-the-shelf software that does not have verifiable quality records. The machine-readable document that lists all its components, including SOUP, custom proprietary code, operating systems, and firmware, is an SBOM.

Will the FDA reject a 510(k) if an SBOM lists known vulnerabilities (CVEs)?

CVEs do not necessarily mean rejection. Rejection happens if a manufacturer does not document those CVEs, evaluate their risk in the ISO 14971/AAMI TIR57 risk management file, or if VEX documentation proves that the CVEs cannot be exploited in the device architecture.

What are the NTIA minimum elements for a medical device SBOM?

The following elements are required for this: Supplier Name, Component Name, Version String, Other Unique Identifiers (such as PURL or CPE), Dependency Relationship, Author of SBOM Data, and Timestamp.

How deep must an SBOM go when mapping software dependencies?

The FDA has mandated dependency mapping all the way down through the transitive (nested) and direct dependencies. The manifest should include the main user application libraries, lower levels of software requirements, operating system kernels, device drivers, microcontroller firmware, etc.

Can we use open-source tools to generate our FDA SBOM?

Yes. There are open-source tools which can produce valid SBOMs, such as Syft, Trivy, and cyclonedx-cli. But engineering teams need to ensure that these tools produce accurate schema versions, populated PURL/CPE identifiers, and full firmware/OS dependency sets.

How often must an organization update an SBOM after 510(k) clearance?

Section 524B requires that there be an accurate SBOM throughout the product lifecycle. The manifest will need to be regenerated and re-validated every time you make a software update, security patch, OS upgrade, or component change. Keep these updated files in your Quality Management System (QMS).

Is a Vulnerability Exploitability eXchange (VEX) document mandatory for 510(k) clearance?

An SBOM document contains all software components, while a VEX document explains whether a specific vulnerability is exploitable or not. The FDA strongly recommends that VEX be documented to explain why there is no patient safety concern due to the known VEX components (CVEs).

What happens if a third-party COTS vendor refuses to provide source code or an SBOM?

You need binary static analysis and firmware dissection tools to reverse engineer and inventory the compiled binaries. All third-party software in your medical device is subject to your legal obligations as to security and compliance.

Where exactly do I attach the SBOM inside the FDA eSTAR portal?

Include your machine-readable SBOM in the attachment section of the eSTAR template in the Cybersecurity – Software Inventory section.