SBOM Gap Assessment for FDA 510(k): Common SBOM Mistakes That Delay FDA Approval and How Medical Device Manufacturers Can Avoid Them

The U.S. Food and Drug Administration (FDA) implemented strict cybersecurity requirements for medical device software submissions under section 524B of the Federal Food, Drug, and Cosmetic (FD&C) Act. When a manufacturer submits a 510(k) file, FDA eSTAR automated intake scripts immediately evaluate the Software Bill of Materials (SBOM). If the software inventory contains missing data fields, hidden open-source libraries, or static formats like Excel or PDF, the FDA instantly issues a Refuse-to-Accept (RTA) hold, stopping the regulatory review on day one.

An SBOM gap assessment is also called a pre-submission dry run. It catches these tiny formatting errors and hidden security flaws early, keeping your launch timeline on track and your hard work out of uncertainty. A medical device SBOM gap analysis by the manufacturer before the 510(k) submission helps identify unanticipated omissions, unaddressed vulnerabilities, and compliance issues before FDA reviewers.

This article explains the importance of an SBOM gap assessment, identifies the most common pitfalls that lead to clearance delays, and provides a complete framework for conducting an SBOM gap assessment and getting your software inventory through regulatory review the first time.

Key Takeaways

• CycloneDX or SPDX (JSON/XML) formats must be used for passing through FDA eSTAR automated parsers and avoiding RTA holds.
• Scan transitive open source packages down to binary modules.
• Build scripts should automatically populate Supplier, Version, PURL/CPE, Dependencies, Author, and Timestamp.
• Provide VEX files justifying lack of patching of vulnerabilities with reachability analysis of the code.
• Match SBOM build version and SHA-256 hash to V&V test reports and Threat Models.
• SCA scanning should be automated within CI/CD pipeline to enable continuous post-market vulnerabilities monitoring.

What is an SBOM Gap Assessment for FDA 510(k)?

An SBOM gap assessment is a technical and regulatory review of the software inventory of a medical device to be conducted before a 510(k) application is submitted.

It is used to determine whether the software component inventory is complete to satisfy all possible requirements specified in Section 524B and conforms with National Telecommunications and Information Administration minimum standards. It also represents the production software currently installed in the physical device.

A thorough gap assessment checks different areas instead of simply running a basic automated security scan just before submission:

• Format and Structure Compliance: Ensuring the SBOM is not just written in machine-readable syntax like CycloneDX or SPDX, but also that the syntax is used correctly.
• Metadata Completeness: Making sure that all the mandatory attributes in the NTIA list, such as supplier names, component titles, precise version numbers, unique identifiers, and dependency relationships, are present in every listed component.
• Vulnerability Mapping: Matching each identified library with public vulnerability databases like the National Vulnerability Database to ensure that all known CVEs have risk justifications.
• Design File Alignment: Ensuring that the SBOM components align with software architecture diagrams, threat modeling diagrams, and compiled binaries in the Design History File (DHF).

Avoid FDA 510(k) Submission Delays

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

Book an SBOM Gap Assessment →

Why Is an SBOM Gap Assessment Required?

An SBOM gap assessment is an initial quality gate before submitting medical device software. There are several key technical and administrative failure points that should be solved before filing a 510(k) eSTAR submission:

• Avoids RTA ingestion rejections: Checks that the SBOM uses the required format and structure so it can be properly processed by the eSTAR system. This helps avoid issues caused by malformed syntax, static text, or unsupported file formats.
• Helps address known vulnerabilities: Identifies known CVEs early so they can be assessed and, where appropriate, addressed through technical risk justifications and companion VEX files.
• Prevents conflicting information: Cross-checks the software inventory against Design History File (DHF) records to identify inconsistencies before submission.
• Improves V&V build traceability: Links the exact software build tested during Verification and Validation (V&V) to its semantic version and cryptographic identifier, such as a SHA-256 hash.
• Supports post-production updates: Ensures the SBOM format and process can be integrated into DevSecOps pipelines, making it easier to track software changes, newly disclosed vulnerabilities, and security patches after the device is launched.

Common SBOM Errors That Delay FDA 510(k) Approvals

Common mistakes related to SBOM that could affect the FDA 510(k) submission process would be a lack of component information, files that are not machine-readable, and a lack of open source dependencies.

Knowing these essential compliance mistakes can help engineering and regulatory teams avoid submission errors while uploading documents to the FDA eSTAR portal.

Submitting Static, Human-Readable File Formats

A lot of manufacturers end up with their software inventory in a PDF, Microsoft Word document, or in a manual Excel spreadsheet. FDA eSTAR Electronic Submission Template Guide indicates that the FDA uses automated software to read and check the submitted software files automatically.

If you upload static spreadsheets and text documents that cannot be read by automated intake scripts, it affects the submission, and the FDA immediately files a Refuse-to-Accept (RTA) hold.

Omitting Transitive (Sub-Tier) Dependencies

You are making a mistake if you are only documenting the direct dependencies but not documenting the packages they depended on. This means an SBOM is listing top-level libraries while missing the sub-tier packages. This creates improper documentation of a software supply chain.

As demonstrated in the CISA 2025 Minimum Elements Framework for SBOMs, security vulnerabilities frequently hide deep within nested open-source trees. Omitting sub-tier relationships creates gaps in supply chain visibility, prompting FDA reviewers to issue formal deficiency letters requesting a complete component hierarchy.

Missing Required NTIA and CISA Baseline Attributes

If you use simple command-line tools to create an SBOM, it may contain incomplete software entries such as a software component name without a specific version number or package identifier.

By excluding key fields like Supplier Name, Component Title, Semantic Version, and Package URL (PURL), it is not possible to automate cross-referencing with public threat repositories, such as the National Vulnerability Database.

Presenting Unresolved Common Vulnerabilities and Exposures Without Risk Justifications

If your SBOM contains software components with known vulnerabilities, you have to mention the severity, impact, and the management procedure for the risks. If these details are not mentioned, the process of FDA approval can be delayed.

Discrepancies Between SBOM and System Architecture Files

The SBOM and system architecture documents should accurately describe the same software environment. For example, the SBOM may list only the application-level code modules, while the System Threat Model or Architecture Diagram may show the host operating system, such as Ubuntu Linux or FreeRTOS.

If the operating system or other software components shown in the architecture documents are missing from the SBOM, the FDA may identify this as a structural discrepancy during review.

Omitting Component Support Levels and End-of-Support (EOS) Dates

Third-party packages are often documented by manufacturers, but not always with information on whether the library is actively developed by upstream developers.

The CISA Software Supply Chain Risk Management Guidance demonstrates that if a medical device uses deprecated or End-of-Life (EOL) software, there should be a documented plan. If a manufacturer has no plan for maintaining, updating, or patching it, they can’t prove whether the device can be kept secure after it is released.

Scope Mismatches between Development Tools and Production Builds

When a software build is performed without the use of build-target filtering, the build may contain development-only requirements, such as test frameworks, local web servers, or debug scripts. On the other hand, teams sometimes leave out low-level microcontroller bootloaders, hardware abstraction drivers, or commercial cryptographic libraries.

Extra development components can create false vulnerability findings, while missing production components can hide real security risks.

Invalid or Non-Standardized Open-Source License Expressions

If you do not fill in the license area, or if you enter custom text strings like “Custom Open Source” or “GPL License,” then the automated intake will fail. eSTAR’s standard validation parsers validate license fields based on pre-defined registries. Empty or unformatted strings are not valid, and present legal issues about the long-term rights to distribute software.

Version and Hash Mismatches Relative to Verification & Validation (V&V) Test Builds

If an SBOM is submitted early in the development cycle which differs from the final production binary tested during V&V testing, this can cause traceability problems. If the SBOM says the tested software is Version 2.1 with SHA-256 hash ABC123, but the test report shows Version 2.0 with a different hash, the FDA may question whether the safety tests were actually performed on the final software being submitted to the market.

Controlling the Software Inventory through a Static Submission Deliverable

If a medical device SBOM is submitted with no post-market Vulnerability Monitoring procedure attached, it implies that the manufacturer considers supply chain inventory as a one-off administrative item. Manufacturers need to prove that they can continue to monitor software components for emerging threats during the entire commercial life of the medical device. To prevent delays in SBOM adoption, medical device manufacturers need to take action.

How Medical Device Manufacturers Can Avoid SBOM Delays

Manufacturers who automate supply chain documentation in their build pipelines see a dramatic decrease in technical review queries. This is supported by recent operational data from the FDA Cybersecurity Center of Excellence Report.

1. Export Only in Standardized Machine-Readable Schemas

Create software inventory files only in recognized and machine-readable formats. Files must be in structured .json or .xml (OWASP CycloneDX Specification v1.4+ and ISO/IEC 5962:2021 SPDX Standard v2.2+). This guarantees that there are no administrative failures while submitting for a review under FDA eSTAR.

2. Automate Deep Recursive Scanning in DevSecOps Pipelines

Set up Software Composition Analysis build tools such as Snyk, Syft, or Black Duck to scan deeply during compile time. SCA tools need to be able to resolve the explicit parent-child dependency tree down to the lowest level compiled third-party module.

3. Fill in all of the required NTIA Baseline Fields

Set up automated build scripts to fill in all seven of the baseline fields mandated by federal guidelines for each software entry:

• Supplier Name: The name of the authoring organization or the open source community.
• Component Name: The specific module name should be mentioned.
• Version Identifier: Semantic version tags that are precise, for example 2.17.1.
• Unique ID: Standardized Package URLs (PURLs) or Common Platform Enumerations (CPEs).
• Dependency Relationship: Explicit structural relationships between components and parent build.
• Author of SBOM Data: The tool or build agent that is creating the inventory.
• Timestamp: An ISO 8601 creation date and time stamp.

4. Share Companion Vulnerability Exploitability eXchange (VEX) Files

If your SBOM contains components with known CVEs, but you cannot fix them before submitting to the FDA, don’t just leave them unexplained.

Instead, include a VEX (Vulnerability Exploitability eXchange) file that explains:

• whether the vulnerability actually affects your device (e.g., Not Affected), and
• For example, vulnerable_code_not_in_execute_path means the vulnerable code exists but is never executed, or inline_mitigations_exist means other security controls already prevent exploitation.

5. Run Pre-Submission Cross-Document Synchronization

Before submitting your 510(k), compare all your documents to make sure they describe the same software.

For example, if the System Architecture Diagram mentions:

• Ubuntu Linux
• SQLite database
• bootloader
• communication stack

Those same components should also appear in the medical device SBOM.

6. Adhere to the EOL Component Remediation and Support Plan

Check all third-party software regularly. If you must use End-of-Life (EOL) or unsupported software (for example, an old board support package from a chip vendor), explain:

• how you’ll continue providing security patches, or
• what compensating controls (such as network isolation) will protect the device.

7. Isolate Production Release Targets in Build Automation

Generate the SBOM only from the final production build, not from development builds. Exclude development-only items like test frameworks and debugging tools. But include everything actually shipped:

• firmware
• static libraries
• embedded operating systems
• compiled software

8. Normalise Licensing Using Official SPDX Expressions

Use the official SPDX license identifiers for every open-source component. Instead of writing free-text descriptions. This helps FDA validation tools correctly read the license information.

For example:

• Apache-2.0
• MIT
• GPL-3.0-only

9. Embed Cryptographic Build Hashes (SHA-256) for Full Traceability

Generate a SHA-256 hash for every released software build. Then use that same SHA-256 value and software version in the SBOM, Verification & Validation (V&V) reports, and release records. This proves that the software you tested is exactly the software you submitted.

10. Create a Life Cycle Cybersecurity Management Plan

Don’t stop managing cybersecurity after the device is released. Create a process to:

• Receive vulnerability reports (Coordinated Vulnerability Disclosure – CVD)
• Continuously monitor public vulnerability databases against your production SBOM
• Deliver security updates, including OTA patches, when needed

A Step-by-Step Framework to Perform an SBOM Gap Assessment

Manufacturers need to create a repeatable, point-by-point SBOM gap assessment workflow before completing their 510(k) eSTAR package. This helps avoid costly submission holds.

Step 1: Establish Automated Generation at Build Time 

Stop using manually updated spreadsheets. Integrate Software Composition Analysis (SCA) tools into your DevSecOps CI pipelines. Set up build agents to automatically generate a new SBOM (CycloneDX, JSON/XML) or SPDX (JSON/tag-value) each time the production binaries are built. Make sure the build tool is able to record precise version numbers and Package URLs for all compiled binary and firmware images.

Step 2: Review of Metadata against NTIA requirements

Examine the SBOM schema generated to ensure all NTIA minimum data elements are included and filled out. Verify that supplier names match official vendor designations rather than internal project shorthands. Confirm that dependency relationships clearly delineate between direct primary software components and sub-tier transitive libraries.

Step 3: Run Automated Vulnerability Cross-Referencing

Submit the completed medical device SBOM  to a vulnerability scanner to compare components to the National Vulnerability Database and CISA Known Exploited Vulnerabilities catalog.

Classify all identified CVEs according to their CVSS score and the impact on the essential device performance. Make sure that no active vulnerabilities are left unanalyzed before creating regulatory submission files.

Step 4: Perform VEX (Vulnerability Exploitability eXchange) Analysis

For every identified CVE in your SBOM components, execute a three-part technical evaluation to determine its VEX status:

1. Code Path Reachability Analysis: Determine if the vulnerable function inside the third-party component is executed by your device software. If the vulnerable code path is never called, assign the VEX status “Not Affected” with the justification Vulnerable_code_not_in_execute_path.
2. Inline Mitigation Evaluation: If the code path is reachable, check whether hardware or network controls neutralize the threat (e.g., an encrypted TLS tunnel blocking unauthenticated network calls). Assign the VEX status “Not Affected” with the justification Inline_mitigations_exist.
3. Remediation & Patching: If the code path is reachable and no compensating controls exist, assign the VEX status “Affected”. Issue an immediate software hotfix or patch before submitting the 510(k).

Step 5: Verify Cross-Document Synchronization

Map SBOM entries to Software Architecture Description, Data Flow Diagrams (DFDs), and System Threat Model. Make sure that all operating systems, runtime environments, third-party libraries, and driver packages mentioned in system documentation appear in the machine-readable SBOM.

Confirm that the postmarket vulnerability monitoring procedures clearly include how the team will monitor the components of the SBOM after clearance.

Pre-Submission SBOM Audit Checklist

Follow this checklist when conducting internal regulatory reviews to ensure that your 510(k) software inventory package is complete:

• Machine-Readable Format: Check if the SBOM exists in a .json or .xml file, and whether it is in CycloneDX v1.4 or higher or SPDX v2.2 or higher
• Full Metadata Population: Review if entries are missing Supplier Name, Component Name, Version, Unique Identifier (PURL/CPE), Relationship, Author, and Timestamp
• Transitive Coverage: Is there coverage for all sub-tier and nested dependencies down to the open-source base components
• VEX Justifications Attached: For each known CVE associated with an SBOM library, is there a VEX document or a Security Risk Assessment report present
• Firmware and Middleware Included: Are embedded operating systems, microcontroller drivers, and third-party stacks accounted for alongside main application code
• eSTAR Attachment Placement: Is the machine-readable SBOM file included in the SBOM section of the FDA eSTAR template for cybersecurity

How can Technical Security Audits avoid 510(k) delays?

An independent SBOM gap assessment gives medical device companies a realistic assessment of the readiness of their submissions. Third-party cybersecurity experts fill the gap between the software development teams and regulatory affairs experts by providing targeted support:

• SCA & Build Pipeline Integration: Automating DevSecOps tooling to create precise, machine-readable CycloneDX or SPDX inventories at each build.
• Complete Vulnerability Assessment: Identifying unpatched CVEs and supply chain risks from component lists and databases of public threats.
• VEX Strategy & Threat Modeling: Assisting engineering teams in estimating code path reachability and creating defensible VEX risk justifications for any remaining vulnerabilities.
• eSTAR Compliance Packaging: Organizing software inventories, threat models, and security test reports to meet FDA requirements and administrative RTA checklists.

How Qualysec Helps Medical Device Manufacturers Build FDA-Compliant SBOM Reports

Qualysec provides a combination of automated tooling and expert human validation to connect software development and regulatory affairs. We follow various methodologies to ensure your medical device SBOM report is ready for submission.

7-Step FDA SBOM Assessment & Remediation Process

Qualysec follows a complete 7-phase methodology to guarantee that your software inventory will pass regulatory screening on day one:

1. Raw Software Inventory Extraction & Formatting: We extract and format software inventories from raw data in standardized machine-readable OWASP CycloneDX and SPDX schemas (JSON/XML). This means that there are no parsing errors when ingesting automated FDA eSTARs.
2. Expert Human Review & Verification: Complex software architectures are not always captured by automated tools. Security engineers at Qualysec conduct a thorough manual audit to guarantee that all components are properly named, correctly versioned, dependencies are mapped, and no sub-tier (transitive) components are missed.
3. Multi-Database Vulnerability Correlation: Each identified open-source, commercial off-the-shelf, and third-party library is cross-correlated with authoritative threat intelligence databases, such as the National Vulnerability Database (NVD), MITRE CVE, CISA KEV, GitHub Security Advisories (GHSA), and specialized vendor advisories.
4. Context-Aware Cybersecurity Risk Assessment: Flaws identified are not just measured by the CVSS score. We evaluate the vulnerability exploitability for the device, based on exposure, current hardware or network security measures, code-path reachability, and possible patient safety consequences.
5. Technical Mitigation Strategy & Remediation: Once vulnerabilities are identified, we offer developer-ready remediation strategies, from patching the upstream libraries, upgrading versions, replacing components, to implementing defensible compensating controls.
6. FDA Cybersecurity Documentation Assembly: The next step is to prepare all the technical findings in audit-ready regulatory documents such as machine-readable SBOMs, System Security Architecture documentation, companion VEX files, and extensive Cybersecurity Risk Assessments for eSTAR submission.
7. Post-Market Total Product Life Cycle (TPLC) Support: Compliance is not a one-time process. We continuously monitor, track newly revealed CVEs, update SBOM versions, and keep the cybersecurity posture throughout the device’s operational life.

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 →

How Qualysec Solved an FDA Refuse-to-Accept Hold for a US Medical Device Manufacturer

A medical device company in the USA had to deal with a critical product launch delay. The FDA issued an immediate Refuse-to-Accept (RTA) hold due to missing cybersecurity documentation.

• Missing key information needed according to the Section 524B standards.
• Not mapping sub-tier (transitive) open-source libraries and exact build versions.
• Unaddressed CVEs lacking context-aware risk evaluations or exploitability assessments.
• Lack of Lifecycle Metadata: End-of-Life (EoL), End-of-Support (EoS), and continuous patching protocols.

Technical Intervention: At Qualysec, we performed a dry-run SBOM assessment and revamped the submission package:

• Carried out a comprehensive expert review to locate and fix all schema, syntax, and formatting mistakes.
• Checked all software requirements at primary and sub-tier level down to the lowest compiled modules.
• Updated the remaining vulnerabilities along with EoL and EoS information.
• Identified known vulnerabilities and created a package of risk mitigations.
• Prepared an FDA-ready medical device SBOM package as per the current regulatory expectations.

The Outcome:

• Fixed all gaps, format issues, and security issues in the metadata.
• Successfully resubmitted to FDA using the eSTAR template without holds.
• The submission was cleared directly from technical review to full FDA 510(k) market clearance.

Conclusion

A medical device SBOM gap assessment is a critical quality gate before submission for modern connected medical devices. Without a machine-readable, transparent software inventory, the 510(k) clearance process for Section 524B can be directly impacted.

Medical device manufacturers can benefit from automating the generation of SBOMs, auditing metadata completeness, documenting sub-tier dependencies, and providing clear VEX risk justifications for known vulnerabilities.

These practices help avoid administrative holds, demonstrate software supply chain transparency, and achieve efficient FDA 510(k) clearance.

Ready to run your own pre-submission dry run? Talk to Qualysec’s medical device cybersecurity team before you file your next 510(k).

FAQs

What will happen if we submit a manual Excel spreadsheet SBOM with our 510(k)?

A manual Excel spreadsheet or static document may result in an immediate Refuse-to-Accept administrative hold. Standardized, machine-readable formats like CycloneDX or SPDX, which can be fed into automated review tools, are required for FDA.

Are OTS software included in an SBOM gap assessment?

Yes. An SBOM gap assessment considers all the software components in the device boundary, such as off-the-shelf software, commercial third-party drivers, open-source libraries, operating systems, and firmware stacks.

What is the difference between an SBOM and a VEX document?

An SBOM is a list of all the software components and versions that are included in a device. A VEX document is a companion document that indicates if the CVEs present in those components affect the device or if they are counteracted by system mitigations.

How Deep Should an FDA SBOM Go Into Transitive Dependencies?

The FDA expects software inventories to include sub-tier dependencies down to the point where the component is compiled into the binary. Not including sub-tier libraries will leave gaps in your vulnerability management and can result in requests for further information from regulators.