Software Bill of Materials (SBOM) Process and End-to-End Workflow for FDA 510(k) Medical Devices in 2026

The SBOM process for FDA 510(k) submissions fails more submissions than any other cybersecurity documentation gap. Under Section 524B, FDA’s reviewers do not accept submissions when the documentation is not complete for the Software Bill of Materials.

The problem is, 70% of the clinical security-related Refuse to Accept (RTA) decisions are because medical device producers’ SBOMs are incomplete or formatted incorrectly. Your SBOM should cover all software components, software dependencies, and software vulnerabilities throughout your product lifecycle, and not just when it’s time to submit it.

This blog details the entire SBOM process, from software inventory to postmarket monitoring. You will understand how to create an FDA compliant SBOM workflow to meet Section 524B requirements, fit into your CI/CD workflow, and enable continuous vulnerability management practice.

What is the SBOM Process?

The SBOM process is the series of activities needed to develop, update, validate and track a Software Bill of Materials over a medical device’s entire product lifecycle.

An SBOM is a hierarchical list. Its output includes all software components which are part of your medical device such as commercial off-the-shelf (COTS) software, open source software libraries, proprietary software, and third-party software. The components contain supplier data, version information, unique identifiers (PURL, CPE, SWID), dependency information, and disclosure paths for vulnerabilities.

The FDA is asking for machine-readable SBOMs, in the format of CycloneDX or SPDX. All of the following are required components of your SBOM: Supplier name, Component name, Version, Dependency relationship, Author, Timestamp, Unique identifier.

SBOM Process Stages

There are eight key steps that make up the entire SBOM process:

1. Software Inventory Discovery – All software components, including transitive dependencies, firmware, embedded Linux, RTOS, containers, microservices, etc. are automatically discovered.
2. Component Classification – Teams classify components into proprietary, open-source, commercial or third-party. There are different documentation and monitoring methods and approaches needed for each of these categories.
3. SBOM Generation – Tools automatically create machine-readable SBOMs in CycloneDX or SPDX format, including all the minimum elements for NTIA and FDA-required metadata.
4. SBOM Validation – Manual validation and automated validation ensure that it is complete, accurate and meets the FDA formatting requirements.
5. Vulnerability Mapping – SBOMs connect to CVE databases, CISA Known Exploited Vulnerabilities Catalog and supplier vulnerability disclosure channels.
6. VEX Integration – Vulnerability Exploitability eXchange (VEX) documents provide the status of vulnerability exploitability.
7. SBOM Signing and Storage – Cryptographic signatures guarantee integrity of SBOM. Versioned SBOMs are stored throughout the product lifecycle.
8. Postmarket Monitoring – Continuous Vulnerability Monitoring, Patch Management and SBOM Updates ensure compliance over the device’s market life.

Why FDA Requires SBOM Process for 510(k) Submissions

SBOMs are required by Section 524B of the FD&C Act for all cyber devices that are seeking FDA premarket clearance. This requirement was passed by Congress in December 2022 and final guidance by FDA in June 2025 detailed what they expect this requirement to look like.

The FDA will rely on SBOMs to evaluate software supply chain security risks. They assess the level of understanding by manufacturers on their software requirements, their ability to identify vulnerabilities in a timely manner and the process they have in place to deal with new threats during the life cycle of a product.

FDA’s SBOM Expectations

FDA expects that manufacturers will:

• Keep full software inventory for all software including the transitive dependencies.
• Use machine-readable formats (CycloneDX or SPDX) that enable automated vulnerability scanning
• Include the support and end of life dates for each component.
• Connect SBOMs to vulnerability disclosure processes & monitor plans for postmarket use
• Make the generation of SBOMs part of automated build processes and not separate once-off documentation.

Manual SBOMs that are simply generated for the purposes of submission to FDA are not acceptable. Your SBOM needs to be a continuous and automated process throughout the product life cycle.

Avoid FDA 510(k) Submission Delays

Avoid costly FDA 510(k) delays by identifying SBOM compliance gaps before submission.

Book an SBOM Gap Assessment →

SBOM Process Workflow: 8 Critical Stages

Stage 1: Software Inventory Discovery

Inputs: Container images, binary artifacts, source code repositories, firmware builds, third-party component documentation

Outputs: Raw component inventory, dependency graphs, software artifact metadata

Dependencies: All build systems, artifact repositories, third party vendor documentation

Ownership: Development teams, DevOps engineers, product security teams

The first step in SBOM processes is full software discovery. All software components are identified using automated tools for source code, compiled binaries, container images and firmware.

Teams must capture:

• Explicitly imported dependencies (direct)
• Transitive dependencies (dependencies of your dependencies)
• Embedded components (firmware, RTOS, embedded Linux distributions)
• Use base images and layers in containers.
• Cloud service dependency and microservices.
• The commercial off-the-shelf software components are subject to copyright.

Transitive dependencies and embedded components are not captured in manual inventories. Comprehensive coverage is possible with automated scanning tools such as Syft, Grype or commercial SCA platforms.

Stage 2: Component Classification

Inputs: Raw components based on discovery stage raw inventory.

Outputs: Categorized parts according to type, risk and impact on regulations

Dependencies: Component metadata, licensing information, supplier documentation.

Ownership: Product security teams, regulatory affairs, legal/compliance

Teams categorize each part in terms of:

• Component type: Proprietary, open-source, commercial, third-party
• Risk level: Critical, high, medium, low (based on functionality and exploitability)
• Regulatory impact: Cyber device components requiring FDA documentation

This classification defines documentation requirements, monitoring frequency and vulnerability response procedures.

Stage 3: SBOM Generation

Inputs: Classified build images and build system artifacts

Outputs: Machine-readable SBOM in CycloneDX or SPDX format

Dependencies: SBOM generation tools, integration into a build pipeline, and SBOM format validators will be dependencies.

Ownership: Available to everyone who uses the application

SBOM generation tools generate machine-readable SBOMs in CycloneDX or SPDX format. 

Teams need to make sure that SBOMs contain all the elements required by the NTIA:

• Supplier name
• Component name
• Component version
• A unique identifier such as PURL, CPE or SWID.
• Dependency relationship
• SBOM author
• Timestamp

Additionally, FDA expects that other metadata:

• A hash of the components (for integrity checking)
• License information
• End-of-support date
• Support level – active, maintenance or abandoned
• Vulnerability disclosure path

Stage 4: SBOM Validation

Inputs: Generated SBOM files

Outputs: Validated SBOMs submitted and distributed

Dependencies: SBOM validators, manual review processes, and FDA formatting requirements.

Ownership: The roles include QA teams, regulatory affairs, compliance managers.

Validation is the process that ensures SBOMs meet FDA requirements:

• Structure and required fields are validated by schema (CycloneDX or SPDX schemas)
• All components are manually verified including transitive dependencies and embedded software (completeness check).
• The version numbers, supplier details and unique identifiers match the actual components (Accuracy Verification)
• Each item must be in the machine-readable format (JSON or XML) with the proper encoding. 

Automated tools cannot identify these issues, which are revealed when manual validation is performed.

Stage 5: Vulnerability Mapping

Inputs: Identified vulnerabilities, prioritized vulnerabilities, remediation strategies, and potential risk score

Outputs: Vulnerability-mapped SBOMs with risk assessments

Dependencies: NVD API, CISA KEV feed and vendor security advisories, as well as vulnerability scanning tools.

Ownership: Product security teams, vulnerability management teams

Teams associate each component with known vulnerabilities through:

• CVE databases: The CVE databases listed below are used to provide standardized vulnerability identifiers.
• CISA KEV Catalog: The CISA KEV Catalog is a catalog of vulnerable software that has been known to be exploited.
• Supplier advisories: These security bulletins from vendors contain details relevant to the vulnerability of individual components.
• CVSS scoring: Common Vulnerability Scoring System measures the severity of the vulnerability

This mapping allows for fast response to vulnerabilities in the event of new CVEs.

Stage 6: VEX Integration

Inputs: The inputs are vulnerability-mapped SBOMs, and the outcome of the exploitability assessments.

Outputs:  VEX documents reporting exploitability status.

Dependencies: VEX Generation Tools, Exploitability Analysis frameworks.

Ownership: Product Security teams, Incident Response teams

Vulnerability Exploitability eXchange (VEX) documents indicate if vulnerabilities identified exist for your device.

VEX statements declare:

• Not affected: Vulnerability exists in component but doesn’t impact your device
• Affected: You are vulnerable to the vulnerability and need to mitigate it.
• Fixed: Vulnerability solved by patch or mitigation 
• Under investigation: Exploitability analysis underway

FDA’s expectation for Vulnerability Exposure Management (VEX) integration with SBOMs is to show active Vulnerability Management.

Stage 7: SBOM Signing and Storage

Inputs: Validated, vulnerability-mapped SBOMs (VEX documents)

Outputs: Cryptographically signed SBOMs in secure storage

Dependencies: More details about the artifacts on a specific release of this are available here.

Ownership: Security teams, DevOps engineers, and IT operations

Cryptographic signatures ensure SBOM integrity and prevent tampering.

Tools teams use to include:

• The Sigstore/Cosign:  An open source signing and verification infrastructure.
• SLSA: Levels for Software Assurance – framework for proving the history of the software supply chain
• Versioned storage: JFrog Artifactory, GitHub Packages or Azure Artifacts for versioned storage.

Signed SBOMs should be stored along with software versions and be versioned.

Stage 8: Postmarket Monitoring

Input: Released SBOMs, vulnerability feeds, CISA alerts, supplier notifications.

Outputs: Updated SBOMs, vulnerability alerts, patch recommendations

Dependencies: Relying on tools to monitor continuously, vulnerability management platforms and patch deployment processes.

Ownership:  A postmarket surveillance team, product security and incident response are responsible.

Postmarket monitoring ensures SBOM relevance throughout product life cycle:

• Continuous vulnerability scanning: Automated tools monitor CVE database and CISA KEV for new vulnerabilities for shipped components
• Supplier notifications: Teams monitor vendor security alerts and end-of-life announcements.
• Patch management: Deploy security patches; update SBOMs accordingly
• Incident response: Quick response to actively exploited vulnerabilities

FDA’s postmarket monitoring plan requirements are found in Section 524B compliance.

Workflow Integration: Connecting All Stages

The SBOM workflow is not linear, but cyclic. Development workflow creates the groundwork for the rest of the development process. The discovery of components is used for dependency mapping and software composition analysis. SBOMs are created throughout validation, storage, and submission during the Build stage. Validation is undertaken to guarantee the accuracy prior to storage and distribution. Versioned SBOMs are stored for further postmarket monitoring. 

Distribution makes SBOMs available to regulators and customers. Postmarket monitoring will keep filling in SBOMs and restart development cycles should there be changes in components. This cycle is repeated during the device’s entire SBOM lifecycle, which is usually 10-15 years for medical devices.

SBOM Formats: CycloneDX vs SPDX Comparison

Recommendation: If security is a priority, medical device manufacturers tend to opt for CycloneDX in workflows that natively support VEX. For teams that have strict license compliance needs, or existing license tooling, SPDX is a good option. 

SBOM Tools: Open Source vs Commercial Solutions

Open Source Approach: Teams integrate Syft (generation), Grype (vulnerability scanning) and OWASP Dependency-Track (management) to create cost-effective workflows that comply with FDA regulations. 

Commercial Approach: Integrated SCA, vulnerability management, and compliance reporting are typically done through a platform, such as Snyk, Mend, or Sonatype, by an enterprise team. 

SBOM Validation, Signing, and Cryptographic Integrity

A. SBOM Validation Checklist

• Schema validation: CycloneDX/SPDX schema validators ensure proper structure
• NTIA minimum elements: Check all of the required fields 
• Component completeness: Manual check ensures all components and transitive components as well as embedded software are present
• Version accuracy: Component versions are consistent with the build artifacts
• Unique identifiers identify the components correctly: PURL, CPE or SWID tags
• Dependency relationships: Parent-child relationship correct according to dependency graph 

B. Cryptographic Signing using Sigstore

Sigstore offers open source, free signing infrastructure:

• Create SBOM (CycloneDX / SPDX).
• Sign with Cosign: cosign sign-blob sbom.cdx.json
• Save signature with SBOM in a repository of artifacts
• Check before distribution: cosign verify-blob sbom.cdx.json 

C. SLSA Provenance

Additionally, SLSA (Supply Chain Levels for Software Assurance) offers an attestation framework: 

• SLSA Level 1: Build process documented
• SLSA Level 2: Versioned source, build scripts
• SLSA Level 3: Hardened build, provenance generation
• SLSA Level 4: Two-person review, reproducible builds

SLSA Level 3 is recommended for medical device manufacturers when submitting to FDA, as it gives evidence regarding hardened build processes and provenance attestation.

Postmarket SBOM Maintenance and Monitoring

Developed by cybersecurity experts and published by vulnerability scanning firms, these databases continuously update to identify new vulnerabilities. They have to evaluate how easily the product can be exploited, as well as deploy them in time to ensure complete Section 524B compliance during the product life cycle. 

I. Postmarket Monitoring Requirements

Manufacturers must have vulnerability management plans and coordinated vulnerability disclosure processes under Section 524B(b)(2).

II. Continuous Monitoring Workflow

• Daily: CVE scan against SBOM components via NVD API
• Weekly: CISA KEV vulnerability catalog review, and actively exploited vulnerabilities.
• Monthly: Supplier Security Advisory Review of all commercial components
• Quarterly: SBOM update and validation on latest builds
• Annually: An annual full audit and update of all deployed devices is run and reported each year. 

III. Patch Management Integration

Postmarket SBOM maintenance integrates with patch management:

• Vulnerability detection: Ongoing monitoring to detect new vulnerabilities
• Risk assessment: Teams assess exploitability and impact using CVSS, EPSS
• Security patches: Security patches for high priority vulnerabilities
• SBOM update: Patches in components reflected in updated SBOMs
• FDA notification: Significant cybersecurity changes may require 30-day FDA 

Real-World SBOM Process Examples

1. Log4Shell (CVE-2021-44228)

The Log4Shell vulnerability was an example of the importance of SBOM:

• Impact: Affected millions of Java applications which rely on Apache Log4j
• Average response time: 14.0 hours were the average time to identify affected systems with partial or incomplete SBOMs
• Before SBOM: Teams were manually sifting through codebases, configuration files, and dependencies for weeks.
• The FDA aspect: Medical devices had to be patched and their SBOMs updated immediately.

2. XZ Utils Backdoor (CVE-2024-3094)

The XZ Utils backdoor wreaked havoc on Linux distributions around the world:

• Discovery: Backdoor in compression library used by SSH, systemd
• SBOM value: Teams with SBOMs were able to easily detect if XZ Utils versions 5.6.0 to 5.6.1 were installed.
• Answer: With the help of SBOMs, risk assessment and patching prioritization was done in a fast time.

3. SolarWinds Supply Chain Attack

In the SolarWinds incident, software supply chain vulnerabilities were exposed:

• Attack vector: A weakness in the build process that allowed for the injection of malicious code.
• SBOM lesson: SBOMs will not stop supply chain attacks from happening, instead, they will allow for quick response.
• Best practice: Integrate SLSA provenance, code signing, and build process hardening with SBOMs 

Common SBOM Process Mistakes

A lot of medical device teams miss out crucial sub-dependencies, RTOS kernels, or bootloaders in their first scans, failing compliance in the process. Others use manually created lists that are static and can easily become out of date with respect to actual software releases. 

1. Incomplete Component Inventory

Teams miss:

• Transitive Dependencies (dependencies of dependencies)
• Microprocessors with embedded components (Firmware, RTOS, bootloaders)
• For shared resources such as containers, base images and layers are used.
• Third party vendor components not documented
• Commercial off-the-shelf software

Solution: Automated scanning of source code, binaries, containers and firmware. 

2. Manual SBOM Creation

Manually building SBOMs for just submission:

• Misses critical dependencies
• Contains version errors
• Becomes outdated immediately
• Signals to the FDA reviewers that there are inadequate processes.

Solution: Embed automated SBOM generation in CI/CD pipelines.

 3. Missing VEX Documentation

Submit SBOMs without VEX:

• Demonstrates inadequate vulnerability management
• Leave reviewers with doubt about exploitability.Ambiguity in reviewers regarding exploitability.
• Lacks an opportunity to show risk-based prioritization

Solution: Create VEX documents in conjunction with SBOMs for all vulnerabilities identified.

4. No Postmarket Monitoring Plan

Not having postmarket processes documented:

• Fails to comply with Section 524B(b)(2) requirements
• Leaves devices open to new risks
• Introduces non-conformities in FDA audits

Solution: Record continuous monitoring, patch and incident response processes.

5. Wrong SBOM Format

Using non-standard formats:

• Excel spreadsheets
• PDF documents
• Proprietary formats that do not export CycloneDX / SPDX

Solution: Have machine-readable CycloneDX or SPDX.

SBOM Best Practices for FDA Compliance

To keep your inventory up to date with all active software builds, automate the generation process with CI/CD pipelines. Ensure formats are validated to standard CycloneDX schemas, and monitor vulnerabilities continuously after the product is released to maximize Section 524B compliance. 

a) Include Early in Development

Ensure SBOM processes are in place from the start of the project:

• Build SBOMs at first build
• Ensure that versioned SBOMs are maintained throughout the development process.
• Do not create SBOMs late – before submission.

b) Automate Everything

Automate SBOM generation, validation and vulnerability scanning:

• Build any number of times per day with CI/CD integration.
• Automated schema validation
• Continuous vulnerability monitoring
• Automated alerts on critical CVEs

c) Document Support Status

Track component SBOM lifecycle:

• Active support: Vendor is actively supporting the component
• Maintenance mode: Security patches and no new features.
• Waste at the end of life: No support, plan replacement
• The date at which support is no longer provided.

d) Maintain Complete Dependency Graphs

Capture all dependencies:

• Direct dependencies (Explicitly imported)
• Transitive dependencies (dependencies of dependencies)
• Optional dependencies (conditionally used)
• To build-time dependencies (tools, compilers)

e) Integrate with Secure Product Development Framework (SPDF)

Integrate SBOM processes with SPDF:

• Requirements: SBOM requirements in product specifications
• Design: Architectures design (SBOM generation)
• Implementation:  Enhancing accessibility to automated SBOM in build processes.
• Verification: When it comes to validating SBOM, this is known as verification.
• Release: The following SBOM is included in the release.
• Response: Specialized in Vulnerability Management, SBOM is the response.
• Maintenance: After postmarketing, SBOM updates are provided to maintain them. 

What Makes Qualysec an Easy Way to Meet SBOM Requirements?

Creating a compliant and automated Software Bill of Materials workflow requires software engineering, product security and regulatory cooperation. Poor team coordination, invalidated product manifests, and fragmented post-market monitoring operations all can cause regulatory delays, Refuse to Accept decisions, and post-market compliance actions.

Qualysec Technologies is a CREST-accredited cybersecurity company that provides medical device manufacturers with human-led, AI-powered penetration testing and regulatory compliance support services. We support engineering and regulatory teams to create repeatable SBOM workflow by offering:

• DevSecOps Pipeline Integration: Setting up automated CycloneDX/SPDX generation, validation and PKI signing workflows for complex source code, RTOS and firmware environments.
• Medical Device Penetration Testing: CREST-accredited penetration testing for device hardware, wireless interfaces, firmware and cloud APIs, to meet FDA premarket testing requirements.
• FDA 510(k) Cybersecurity Submission Support: Conducting gap analyses, creating machine-readable VEX files, and comparing SBOM inventories with ISO 14971/AAMI TIR57 risk management packages for eSTAR submission.

Conclusion

The SBOM process is the basis of FDA Cybersecurity compliance for medical devices. Those who automate SBOM generation, keep full component inventories and integrate continuous vulnerability monitoring are well on their way to a successful 510(k) submission.

The FDA reviewers are looking for SBOMs that actually represent a true software supply chain management process, and not just something that is being generated to comply with the FDA requirement. A team that implements SBOM process across the entire product lifecycle, from design, through development and postmarket monitoring, exhibits the cybersecurity maturity that FDA is looking for.

Preparing for an FDA 510(k) Submission?

Generate FDA-compliant SBOMs, VEX documentation, and cybersecurity assessments with expert support.

Speak with Our FDA Compliance Team →

FAQs

What format does FDA accept for SBOMs?

Machine-readable SBOMs are accepted by FDA in CycloneDX or SPDX format. Both are specifically recommended in FDA guidance. Teams are expected to select a format and stick to that format for all submissions.

Does FDA require SBOM for all medical devices?

For “cyber devices” (defined in Section 524B: devices with software capable of being used on a network), FDA is requiring SBOMs. This includes most connected medical devices that are intended for submission for 510(k), PMA or De Novo submission, and other premarket submissions.

How often should I update my SBOM?

Keep up to date SBOMs for all software releases and when new vulnerabilities are reported for components. Postmarket monitoring involves ongoing vulnerability scanning, and SBOM updates will need to be updated whenever patches or security fixes are issued.

What are NTIA minimum elements for SBOM?

Elements in the NTIA minimum elements include: supplier name, component name, version, unique identifier (PURL/CPE/SWID), dependency relationship, SBOM author, and timestamp. All these are required by FDA.

What is VEX and do I need it for FDA submissions?

The VEX (Vulnerability Exploitability eXchange) documents indicate if vulnerabilities found in your SBOM impact your device. VEX integration is not mandatory, but FDA expects that it is used to show active vulnerability management.

Can I use open-source SBOM tools for FDA submissions?

Yes. Open-source tools such as OWASP Dependency-Track, Syft, Grype and CycloneDX CLI can produce FDA compliant SBOM. These tools are employed by many manufacturers without a problem.

How do I validate my SBOM before submission?

Use schema validators (CycloneDX and/or SPDX), review all NTIA minimum elements, manually review for completeness, and validate the version accuracy against build artifacts.

What happens if my SBOM is incomplete?

FDA can refuse to accept incomplete SBOMs. When the SBOM is incomplete, it indicates a lack of software supply chain management, and can lead to months of delays in getting approvals.

How do I handle third-party vendor components without SBOM?

Ask vendors to provide SBOMs. If not available, document components manually with supplier information, versions and support. Record attempts to obtain vendor SBOMs and planning to replace critical ones.