Medical Device SBOMs: Handling Missing Component Data From Suppliers

When a software supplier will not or cannot disclose complete component details for your cyber device, the SBOM obligation does not move to the supplier. Section 524B(b)(3) of the Federal Food, Drug, and Cosmetic Act (FD&C Act), in effect since March 29, 2023, requires the sponsor of a premarket submission for a cyber device to provide a software bill of materials (SBOM) that includes commercial, open-source, and off-the-shelf software components. FDA's current final guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (issued February 3, 2026, superseding the June 27, 2025 version, which had replaced the September 27, 2023 version), describes what a robust SBOM should contain and gives one stated route for gaps: a manufacturer unable to provide SBOM information should provide a justification for why it cannot be included in the premarket submission. That justification is not an exemption. It travels with known-vulnerability disclosures, risk controls for the affected component, and a plan to update or replace it, while purchasing controls under the Quality Management System Regulation (QMSR) are where the durable fix belongs.

What FDA Actually Requires, and From Whom

Start with who carries the obligation, because much of the vendor material on this question blurs it. Compliance-software pages often describe FDA's SBOM rules as supplier requirements or tie them to device class. The statute does neither: it attaches to the sponsor of a premarket submission for a device that meets the cyber-device definition. For the broader Section 524B package, see our medical device cybersecurity guide; for SBOM basics and formats, our SBOM guide for medical devices.

The Statutory Mandate: Section 524B and the Cyber Device Test

Section 3305 of the Consolidated Appropriations Act, 2023 (Public Law 117-328, enacted December 29, 2022) added Section 524B to the FD&C Act, codified at 21 U.S.C. 360n-2. The section took effect 90 days after enactment, on March 29, 2023. It applies to a person who submits a 510(k), PMA, Product Development Protocol (PDP), De Novo request, or Humanitarian Device Exemption (HDE) for a device that meets the statutory definition of a cyber device.

Under Section 524B(c), a device is a cyber device if it meets all three of these prongs:

1. Software: it includes software validated, installed, or authorized by the sponsor as a device or in a device;

2. Connectivity: it has the ability to connect to the internet. FDA's guidance gives an illustrative, non-exhaustive list: network, server, or cloud connections; radio-frequency links such as Wi-Fi, cellular, and Bluetooth; magnetic inductive communications; and hardware connectors capable of connecting to the internet, such as USB, Ethernet, or serial ports; and

3. Vulnerability: it contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats.

For a cyber device, Section 524B(b)(3) says the sponsor shall “provide to the Secretary a software bill of materials, including commercial, open-source, and off-the-shelf software components.” The statutory relief valve is Section 524B(d): FDA may identify devices, or categories or types of devices, that are exempt, and must publish that list in the Federal Register. That mechanism is defined by device type, not by supplier circumstance, so an uncooperative vendor is not a route to exemption.

Sponsor Duty Versus the Supplier Responsibility Myth

The statutory command is directed at the sponsor of the premarket application or submission. Suppliers of operating systems, commercial libraries, chipset firmware, or cloud SDKs are not the sponsor and have no SBOM submission obligation under Section 524B. What you need from them is a matter of your purchasing controls and contracts, not their regulatory filings.

That shapes how gaps are written up. A bare statement that “our OS vendor would not give us an SBOM” moves no obligation. What the guidance describes instead is a justification for the specific information that cannot be included, inside a submission that still provides an SBOM for everything the sponsor can document. Timing matters for anyone reading older internal memos. FDA's refuse-to-accept (RTA) policy for cyber devices, announced in the Federal Register on March 30, 2023 (88 FR 19148), said FDA generally did not intend to issue RTA decisions based solely on Section 524B information before October 1, 2023, and would instead work with sponsors through interactive and deficiency review. From that date, a cyber-device submission missing the Section 524B information can be refused at acceptance review.

The Governing Guidance: February 3, 2026 Final Revision

The current FDA document is Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (docket FDA-2021-D-1158), issued February 3, 2026. It supersedes the June 27, 2025 version, which had replaced the September 27, 2023 version. Like all FDA guidance, it contains nonbinding recommendations except where it restates statutory requirements, so procedures and dossiers should cite the 2026 text and keep its “should” distinct from the statute's “shall.”

Section V.A.4 of the guidance, which Section VII.C.3 applies to cyber devices, describes the SBOM content FDA recommends:

• Manufacturer-developed components: the software the device manufacturer develops itself, which the guidance calls proprietary software.

• Third-party components: purchased or licensed software and open-source software.

• Upstream dependencies: the software that proprietary, purchased/licensed, and open-source components themselves require. Because this layer sits inside the supplier's product, it is the part of the SBOM you cannot complete without the supplier's help.

• NTIA minimum elements, machine-readable: SBOMs consistent with the minimum elements (also called baseline attributes) identified in the October 2021 NTIA multistakeholder document on framing software component transparency, in addition to the documentation FDA's off-the-shelf software guidance already recommends.

• Support level and end-of-support date: for each component, the level of support provided through monitoring and maintenance by the component's manufacturer (for example actively maintained, no longer maintained, or abandoned) and its end-of-support date, either in the SBOM or in a separate addendum.

Where Component Information Goes Missing in Medical Devices

Device software stacks rarely arrive as a tidy, single-tier list. Real-time operating systems, board support packages, commercial communication stacks, and deep open-source trees all sit inside the same build. Information gaps tend to appear in four places.

Off-the-Shelf Software and the Loss of Lifecycle Control

FDA's baseline for third-party software is its final guidance Off-The-Shelf Software Use in Medical Devices (issued August 11, 2023, docket FDA-2019-D-3598). It describes off-the-shelf (OTS) software as a generally available software component for which the manufacturer cannot claim complete software life cycle control, such as an operating system or display library. The SOUP concept in IEC 62304 covers similar ground; see our SOUP guide.

When a device embeds OTS software, the sponsor does not control the vendor's codebase or its internal development records. Components licensed years before Section 524B existed may have been bought on standard commercial terms that never contemplated SBOM delivery, leaving the sponsor with binaries and release notes rather than a component inventory.

The Upstream and Transitive Dependency Blind Spot

Gaps often appear one level down. A sponsor may license an imaging SDK or a DICOM parser and receive a product name and version, while the SDK itself bundles third-party libraries for compression, cryptography, or XML parsing.

Because the guidance's robust-SBOM description includes “the upstream software dependencies that are required/depended upon by proprietary, purchased/licensed, and open-source software,” an SBOM that lists only the vendor's top-level component leaves part of the recommended scope uncovered. If the vendor will not disclose its own dependency list, say so explicitly rather than let the omission look like a complete record; the known-unknowns practice discussed below is the standard way to do that.

Commercial Refusals, Proprietary Blobs, and Legal Barriers

Suppliers that mainly serve other industries, such as consumer telecommunications, automotive, or industrial silicon, may treat detailed component manifests as confidential. Requests for a full SBOM, vulnerability notification commitments, or support timelines can meet refusals grounded in standard license terms or intellectual-property concerns.

Other components arrive only as precompiled binaries, such as radio firmware or graphics microcode, under license terms that may restrict reverse engineering. FDA's guidance acknowledges the situation directly: manufacturers “may not have control of source code due to licensing restrictions, terms of supplier agreements, or other challenges.” Source code is not required in premarket submissions, but the guidance still expects the submission to include plans for how such components could be updated or replaced if support ends or other software issues arise.

Legacy Operating Systems and Abandoned Open-Source Modules

The fourth failure mode is software nobody supports any more. Devices with long commercial lives can run embedded Linux distributions, Android Open Source Project branches, or RTOS builds whose vendors have ended support or left the market.

Open-source libraries in older codebases can likewise lose their maintainers. There is then no supplier to ask for an end-of-support date or patch commitments, yet the component remains part of the validated device software. The guidance's support-level field anticipates this case: “abandoned” is one of its own example values.

The Justification Route When SBOM Information Cannot Be Provided

FDA's February 3, 2026 guidance addresses missing SBOM information in one sentence, in Section V.A.4.b (Documentation Supporting Software Bill of Materials), which Section VII.C.3 applies to cyber devices:

“If a manufacturer is unable to provide the SBOM information to FDA, the manufacturer should provide a justification for why the information cannot be included in the premarket submission.”

That sentence is the bridge between commercial reality and the statutory SBOM requirement, but the guidance says nothing more about what the justification should contain. Treat it as an engineering and risk document, not a waiver letter: the reviewer still has to assess the device's cybersecurity risk with a known gap in the inventory.

A Practical Structure for the Justification

FDA does not prescribe a format. The five-part structure below is this article's recommendation for organizing a justification so it answers the questions a reviewer is likely to ask; it is not FDA text. Keep it with the SBOM and cybersecurity documentation in the submission and cross-reference it from the cybersecurity risk assessment.

1. Component identification and context: name the component, its supplier, the version or revision you can confirm, its function in the architecture, and where it executes (application layer, kernel, or a separate processor).

2. Record of attempts: summarize what was requested from the supplier, when, and what came back, including the license or agreement terms that limit disclosure. Keep the underlying correspondence in your design records.

3. Exact scope of the gap: state what is known and what is not. For example: the top-level binary and its version are confirmed; transitive dependencies, their versions, and the vendor's end-of-support date are not.

4. Vulnerability assessment for the gap: show how you searched for known vulnerabilities affecting what you can identify, how you checked the KEV catalog, which test methods you applied to the component (for example binary software composition analysis or fuzzing at its interfaces), and the limits of each method. The guidance asks manufacturers to describe how vulnerabilities were discovered so FDA can judge whether the assessment methods were sufficiently robust.

5. Risk controls and lifecycle plan: describe the architecture and controls that limit the effect of an undisclosed weakness in the component, such as segmentation, least privilege, and integrity protection for code and updates, and the plan to update or replace the component if support ends.

Known Vulnerability Disclosures and KEV Screening

The justification does not replace the vulnerability content the guidance recommends for every premarket submission. Manufacturers should identify all known vulnerabilities associated with the device and its software components, including those in CISA's Known Exploited Vulnerabilities (KEV) catalog, and describe how they were discovered. For components with known vulnerabilities, the guidance recommends a safety and security risk assessment of each vulnerability and details of the risk controls that address it, with any compensating controls described in appropriate detail.

When a closed module is suspected to contain an open-source library with a KEV-listed vulnerability, address it directly: whether the vulnerable code path is reachable in the device's configuration, what evidence supports that conclusion, and which controls limit exploitation. A gap in supplier data makes this analysis harder; it does not make it optional. For the triage workflow once components are identified, see our SBOM-to-VEX triage guide.

The Absence of Templates and Review Acceptance Realities

FDA publishes no justification template, no checklist specific to missing SBOM information, and no statistics on how such justifications fare in review. Any claim about acceptance rates is speculation.

What the guidance does say is that cybersecurity documentation should scale with the device's cybersecurity risk, rather than with other criteria such as the documentation level in FDA's premarket software guidance. A gap in an isolated logging library on a device with a single USB connection and a gap in the communications stack of a networked infusion system are different problems, and the depth of testing, architecture evidence, and lifecycle planning behind each justification should reflect that.

The Configuration-to-Claim-to-Evidence Map

The two tables below carry the decision. The first separates where each SBOM-related expectation comes from, because vendor material routinely turns recommendations into requirements. The second maps five common supplier situations to what the sponsor can honestly claim and the evidence behind that claim.

Evidence Tiers: Statute, Guidance, Voluntary Baselines, and Commercial Terms

Five Supplier Situations Mapped to Claims and Evidence

Getting the Data Through Purchasing Controls and Quality Agreements

Justifications handle gaps you could not close in time. The durable fix belongs in the quality management system, ideally before design freeze, while you still have leverage to choose or replace a supplier.

The QMSR and ISO 13485:2016 Subclause 7.4 Purchasing Mandate

On February 2, 2026, FDA's Quality Management System Regulation (QMSR) took effect, amending 21 CFR Part 820 to incorporate ISO 13485:2016 by reference. FDA inspections now follow compliance program 7382.850, which replaced 7382.845 and 7383.001.

FDA's cybersecurity guidance applies the purchasing clause directly to software: under subclause 7.4 of ISO 13485, a manufacturer must put in place processes and controls to ensure that its suppliers conform to its requirements, with that information documented in the Design and Development Files (subclause 7.3.10) and the Medical Device File (subclause 4.2.3). The guidance adds that security risk assessments covering cybersecurity risks in, or introduced by, third-party software and the software supply chain may help demonstrate that manufacturers have ensured this conformance.

If a supplier repeatedly declines to provide the transparency your purchasing requirements specify, that is a supplier-evaluation question under subclause 7.4, not only a submission-writing problem. Our third-party vendor cybersecurity risk guide and supply chain risk management guide cover the wider supplier program.

Supplier Terms That Close the SBOM Gap

Purchasing requirements are where SBOM expectations become enforceable against a supplier. The terms below are common choices, not regulatory text; timelines and thresholds should come from your own risk assessment and negotiation. For clause construction, audit rights, and change notification, see our guide to QMSR supplier quality agreements for cloud, AI, cybersecurity, and test vendors.

• SBOM with each release: a machine-readable SBOM in an industry-accepted format with every build or release you receive, including upstream dependencies, or an explicit statement of which dependencies are unknown or withheld.

• Support status and end-of-support notice: the component's support level and end-of-support date, with advance written notice before monitoring, maintenance, or security updates stop. Set the notice period from your device's own support horizon.

• Vulnerability notification: notice when the supplier learns of a vulnerability affecting the component, within a period your risk assessment supports, so your postmarket plan can act on it.

• Restricted delivery where confidentiality is the obstacle: access to the SBOM under confidentiality terms or controlled distribution, rather than no SBOM at all.

Source-Code Escrow and Long-Term Support Horizon Planning

The guidance addresses a common mismatch: a device often stays in service longer than the support life of the software inside it. It recommends that manufacturers keep custodial control of device source code throughout the lifecycle as part of configuration management, naming methods such as source code escrow or source code backups. Where suppliers will not grant source access, it suggests manufacturers may consider adding to their purchasing controls the acquisition of source code should the purchased software reach end of support or end of life before the device's intended end of support.

As the guidance describes it, escrow means depositing a copy of the relevant source code, with related technical components and documentation, with an independent third party. Release conditions, such as supplier insolvency or the end of maintenance, are negotiated terms. Escrow helps only if your team can actually build and maintain the released code, so confirm that capability before you rely on it.

flowchart TD
    A["Third-party software selected in design"] --> B{"Supplier provides SBOM and support terms?"}
    B -- Yes --> C["Record supplier controls under ISO 13485 subclause 7.4"]
    C --> D["Reconcile SBOM with build and screen against NVD and CISA KEV"]
    D --> E["Submit SBOM, support data and vulnerability assessment"]
    B -- "No or partial" --> F{"Can the component be replaced?"}
    F -- Yes --> G["Qualify an alternative or build in house"]
    G --> C
    F -- No --> H["Document requests and the supplier position"]
    H --> I["Mark unknown dependencies explicitly in the SBOM"]
    I --> J["Test the component and state each method's limits"]
    J --> K["Design risk controls around the component"]
    K --> L["Write the justification per guidance Section V.A.4.b"]
    L --> M["Submit with an update-or-replace plan"]

Substitute Evidence: Build-Time Generation, Binary Analysis, and Their Limits

When a supplier will not provide SBOM data, teams reach for tools that generate a substitute inventory. The tools are useful; the question is what each can and cannot support in a submission.

NTIA's 2021 minimum elements report sets the order of preference: from an efficiency and utility perspective, SBOM data should be provided by the supplier, but where that is not possible, for example legacy software with only object code available, binary analysis tools can help identify components and dependencies, validate SBOM contents, or expose gaps. The same report notes that SBOMs generated from source, at build time, and from already-built software can differ, and it advises obtaining SBOM data from the build where possible because the build reflects what the compiler actually produced.

Build-Pipeline SCA: Strengths and Blind Spots

Software composition analysis (SCA) in a continuous integration pipeline reads source repositories, package manager manifests and lockfiles, and build configuration. It is effective at enumerating declared open-source dependencies and matching them to known vulnerabilities.

Its blind spot is anything that enters the build as a precompiled artifact. If a vendor ships a closed shared library, static archive, or firmware image that is linked or flashed as delivered, a manifest-based tool typically records only that artifact, not the libraries compiled inside it.

Binary Analysis: Forensic Utility Versus Failure Modes

Binary analysis tools inspect compiled code: symbol tables, embedded strings, cryptographic constants, and code patterns compared against fingerprints of known open-source libraries.

FDA's guidance lists “Software composition analysis of binary executable files” among the security testing it recommends, so binary SCA results belong in your testing evidence. The guidance does not, however, describe binary analysis as a substitute for SBOM information a supplier withholds. Present it as verification of what you could and could not identify, and state its limits:

• Stripped binaries: release builds often have symbols and metadata removed, which lowers match confidence.

• Modified forks: if a vendor has customized an open-source library, matchers may miss it or report the wrong version.

• Compiler optimization: inlining, link-time optimization, and similar transformations change instruction sequences, producing both false positives and false negatives.

• Obfuscation and packing: packed, encrypted, or obfuscated modules can defeat static analysis.

• No hash for what the tool cannot see: NTIA notes that when component data comes from a tool without direct access to the component, such as a binary analysis tool, the author may be unable to generate a component hash.

MITRE Findings on Data Normalization and the Single Source of Truth

Two MITRE white papers announced by FDA document the reconciliation problem: Data Normalization Challenges and Mitigations in Software Bill of Materials (SBOM) Processing, written for medical device manufacturers and announced by FDA on October 24, 2024, and Considerations for Managing Challenges in Software Bill of Materials (SBOM) Data Normalization, announced on April 22, 2026.

The 2024 paper addresses manufacturers who now generate SBOMs at scale from various data sources, and focuses on normalization challenges and mitigations, meaning consistent nomenclature and formats so that data from those sources agrees. The 2026 follow-on covers SBOM tooling and its evolving capabilities, how normalization contributes to inconsistencies, considerations when acquiring tools, and managing an organizational “source of truth” for consistent naming. For a supplier gap the practical lesson is simple: build data, scanner output, and vendor SBOMs will name the same component differently, so reconcile them into one internal record before you claim what the device contains.

Baseline Drift: NTIA 2021 Versus CISA's Revised Minimum Elements

Check which baseline your suppliers' tools target. FDA's guidance recommends SBOMs consistent with the NTIA minimum elements. NTIA's July 12, 2021 report, The Minimum Elements For a Software Bill of Materials (SBOM), lists seven baseline data fields: supplier name, component name, version, other unique identifiers, dependency relationship, author of SBOM data, and timestamp. It also sets practices that bear directly on supplier gaps. Under its known unknowns practice, when the full dependency graph is not enumerated, the SBOM author must explicitly distinguish a component with no further dependencies from one whose dependencies are unknown, and the default reading of the data is that it is incomplete.

Federal baselines have kept moving since 2021. CISA's August 2025 public-comment draft, 2025 Minimum Elements for a Software Bill of Materials (SBOM), written to guide SBOM practice in U.S. federal agencies, proposed new fields (component hash, license, tool name, and generation context) and asked SBOM authors to distinguish dependency information that is unknown from information that is purposefully redacted. That distinction is useful wording for supplier contracts and for your own justification. Whatever version of the CISA baseline a supplier's tooling follows, it is not an FDA submission requirement: FDA's February 2026 guidance still points to the NTIA 2021 minimum elements, plus the support-level and end-of-support fields.

Postmarket Obligations, Labeling, and Continuous Transparency

Clearance or approval with a justification does not close the supplier problem. The SBOM, and the gaps in it, carry into labeling, postmarket monitoring, and every later software change.

Continuous User Availability in Machine-Readable Formats

In its labeling recommendations (Section VI.A), the guidance says manufacturers should provide or make available SBOM information to users on a continuous basis, in a machine-readable format, with up-to-date links if an online portal is used. Section V.A.4 also recommends maintaining the SBOM as part of configuration management and updating it to reflect software changes in marketed devices.

Users such as hospital clinical engineering and security teams rely on that information to manage assets and to judge the effect of newly disclosed vulnerabilities. Declared unknowns help them too: a clear statement that a module's dependencies are not supplier-confirmed is more usable than an inventory that looks complete but is not. The guidance also recommends that labeling include information on end of support and end of life for the device and its components, when known or anticipated.

Configuration Management and Pre-Planned Migration Paths

For cyber devices, Section 524B(b)(1) requires a plan to monitor, identify, and address postmarket vulnerabilities and exploits in a reasonable time, and Section 524B(b)(2) requires processes and procedures that provide a reasonable assurance of cybersecurity and make postmarket updates and patches available. When a component is unsupported or abandoned, no vendor patch will arrive, so those obligations fall on the manufacturer's own engineering.

That is why the guidance asks for plans, in the premarket submission, for how third-party components could be updated or replaced if support ends. Make the plan specific: the triggers (for example a KEV-listed vulnerability or an announced end-of-support date), the replacement candidates, the verification work, and how you will decide whether the change needs a new premarket submission, which Section VII.D of the guidance addresses for cyber devices. For the customer-facing side of a component reaching end of support, see our guide to device software end-of-support transitions; for deployment mechanics, see regulated patch management.

The EU Boundary: What MDR Does and Does Not Require

Manufacturers filing in both the US and the EU should not copy Section 524B framing into EU technical documentation. The two systems treat SBOMs differently.

The Absence of a Standalone Statutory SBOM Mandate in MDR

The EU Medical Devices Regulation (MDR, 2017/745) and In Vitro Diagnostic Medical Devices Regulation (IVDR, 2017/746) contain no standalone SBOM submission requirement comparable to Section 524B(b)(3). Cybersecurity enters through the Annex I general safety and performance requirements, for example MDR section 17.2 (software developed according to the state of the art, taking into account development life cycle, risk management including information security, and verification and validation) and section 17.4 (minimum requirements on hardware, IT network characteristics, and IT security measures, including protection against unauthorized access).

MDCG 2019-16 Status Versus US Prescriptive Depth

The main EU cybersecurity guidance is MDCG 2019-16 rev.1, Guidance on Cybersecurity for medical devices (December 2019, revised July 2020). Its cover states that it is endorsed by the Medical Device Coordination Group, is not a European Commission document, and is not legally binding.

MDCG 2019-16 does mention SBOMs: it lists a Software Bill of Materials among security information that may be shared with users through documentation such as administrator or security manuals. It does not set per-component data fields, a machine-readable format expectation, or a justification route for missing component information. A peer-reviewed comparison of MDCG 2019-16 and FDA's premarket cybersecurity guidance, published in 2025 (PMC), found FDA's handling of third-party software components and SBOM requirements more detailed and better articulated than the EU guidance; that analysis predates FDA's February 2026 revision. Build EU documentation around the general safety and performance requirements and your notified body's expectations, not around a Section 524B-style acceptance checklist.

Vendor Claims Worth Correcting in Your Internal Documentation

RA/QA teams can check internal SOPs, supplier onboarding documents, and cybersecurity management plans against the corrections below.

The workable sequence is straightforward. Put SBOM and support-status requirements into purchasing controls before design freeze. List every component with what is known and mark what is not. Use the guidance's justification route only for information you genuinely cannot obtain, backed by vulnerability assessment, testing with stated limits, risk controls, and an update-or-replace plan. Then keep the SBOM current after clearance. None of this guarantees a review outcome, but it keeps every claim in the submission tied to evidence you can show.