MedTech Terms
    The authoritative reference
    All terms
    CybersecurityConnected & Cyber-Physical DevicesSoftware LifecycleSBOM

    Software Bill of Materials

    An inventory of software components and dependencies used in a device, supporting vulnerability management and supply-chain transparency.

    Reviewed by Christian Espinosa, Founder, Blue Goat CyberLast reviewed September 19, 2026

    Definition

    A software bill of materials (SBOM) is an inventory of software components and their relationships, including manufacturer-developed software, purchased or licensed components, open-source software and upstream dependencies. It helps identify devices potentially affected by vulnerabilities in those components. Machine-readable, industry-accepted formats support automated analysis; CycloneDX and SPDX are common examples. An SBOM does not by itself prove that a component is secure or that a vulnerability is exploitable in a particular device.
    What the regulation says
    For cyber devices within section 524B of the FD&C Act, section 524B(b)(3) requires an SBOM including commercial, open-source and off-the-shelf software components as part of the applicable premarket submission. FDA's February 3, 2026 final guidance supersedes the June 27, 2025 edition. The legal obligation to provide an SBOM is distinct from nonbinding guidance recommendations about its format and supporting information. Section V.A.4 of the guidance recommends machine-readable SBOMs consistent with the NTIA baseline attributes and encourages industry-accepted formats. FDA also recommends component support level and end-of-support dates, which may be supplied within the SBOM or separately. The guidance recommends maintaining the SBOM or an equivalent capability in configuration management and updating it to reflect changes to marketed software; section VII.C.3 discusses the cyber-device statutory requirement.

    What this means in practice

    MedTech teams can generate an SBOM during software builds, review it when shipped software changes, and use it in vulnerability monitoring. VEX can add product-specific exploitability context but does not replace the inventory or risk assessment. Information sharing with healthcare operators should follow the device's labeling, security communication plan and applicable agreements; an SBOM alone is not a universal hospital procurement guarantee.

    Examples

    • Illustrative example: a manufacturer uses its inventory to identify products containing a newly vulnerable library, then evaluates exploitability and appropriate corrective action.
    • Illustrative example: a hospital reviews shared component information alongside the manufacturer's vulnerability assessment, rather than treating the inventory as proof that a device is secure.

    Use cases

    1 scenario
    1

    Reviewing a changed software build

    Product security engineer

    The team generates a machine-readable inventory, checks dependencies and component support, and evaluates known vulnerabilities in the actual device context.

    OutcomeThe updated inventory supports the premarket package and lifecycle risk management; acceptance still depends on the complete submission.
    Common pitfalls
    • •Omitting third-party components or upstream dependencies.
    • •Treating a machine-readable format recommendation as the wording of the statute.
    • •Assuming an inventory proves that software has no vulnerabilities.
    • •Failing to update component information when marketed software changes.

    Frequently asked questions

    No. Section 524B applies to covered premarket submissions for cyber devices. The statutory definition includes sponsor-validated, installed or authorized software, the ability to connect to the internet, and technological characteristics that could be vulnerable to cybersecurity threats. FDA guidance also recommends SBOM documentation beyond this statutory category where applicable.

    Cross-references

    Uses

    Used by

    See also

    Related terms

    Grouped by theme
    Cited by

    Where this term appears across MedTech Terms.

    Learning paths (2)

    Latest in MedTech

    Sources

    6 sources

    Sources support the definition or relevant regulatory context, not necessarily every claim on this page. Each is graded against our source-tier hierarchy so you can see what rests on binding law versus commentary.

    Official-source claim check:

    Current FDA guidance issued February 3, 2026 distinguishes the statutory SBOM requirement from recommended formats and supporting documentation.

    Partial review: verified corrections are applied, but this is not a full accuracy certification. The last full review date is unchanged.

    Remaining verification limits
    • Targeted check of SBOM scope, format and maintenance wording, not a full cybersecurity-program certification.
    Tier 2Regulator guidance and consensus· 6
    Link health: 4 verified 2 unchecked· last checked 2026-06-20
    FDA·2CISA·1OWASP·1Linux Foundation·1US official source·1
    1. 1
      Section 524B of the FD&C Act
      Tier 2 Verified
      FDAfda.gov
    2. 2
      CISA SBOM Resources & Minimum Elements
      Tier 2 Verified
      CISAcisa.gov
    3. 3
      CycloneDX Specification
      Tier 2 Verified
      OWASPcyclonedx.org
    4. 4
      SPDX Specification (ISO/IEC 5962:2021)
      Tier 2 Verified
      Linux Foundationspdx.dev
    5. 5
      FDA guidance publication page: February 3, 2026 edition and superseded guidance
      Tier 2 Unchecked
      FDAfda.gov
    6. 6
      FDA final cybersecurity guidance, February 3, 2026
      Tier 2 Unchecked
      US official sourcefda.gov

    Inline markers like [1] jump to the matching reference above.