The Crosswalk

    § Topic · SBOM

    Software Bill of Materials, by jurisdiction.

    Where a machine-readable SBOM is mandatory, expected or still emerging — and which format satisfies the most regulators with the least rework.

    Last updated ·

    TL;DR

    Generate one CycloneDX (or SPDX) SBOM per release. It satisfies FDA today, PMDA today, Health Canada today, and the EU CRA from December 2027 — no per-market rework. Pair it with a VEX file describing known vulnerabilities and per-component support level.

    Per-jurisdiction status

    Flag of United States

    United States

    FDA / CDRH

    Required

    Machine-readable; SPDX or CycloneDX. §524B(b)(3) since March 2023.

    Flag of European Union

    European Union

    EC / MDCG

    Required (CRA)

    Expected today by Notified Bodies under MDCG 2019-16; statutory under CRA from 11 Dec 2027.

    Flag of Canada

    Canada

    Health Canada

    Expected

    Health Canada 2024 pre-market guidance expects SBOM for Class III/IV.

    Flag of Japan

    Japan

    PMDA / MHLW

    Required

    PMDA 2024 cybersecurity notification mandates SBOM for connected devices.

    Flag of South Korea

    South Korea

    MFDS

    Expected

    MFDS guidance references IMDRF N73; SBOM strongly encouraged.

    Flag of United Kingdom

    United Kingdom

    MHRA

    Expected

    MHRA aligns with MDCG 2019-16; SBOM expected, becomes explicit in UK SaMD framework.

    Flag of Australia

    Australia

    TGA

    Expected

    TGA aligns to IMDRF N73; SBOM expected for connected devices.

    Flag of Singapore

    Singapore

    HSA

    Expected

    HSA's Regulatory Guidelines for Software Medical Devices reference IMDRF N73.

    Flag of China

    China

    NMPA

    Emerging

    NMPA references in cybersecurity guidance; format not yet standardised. PIPL/DSL overlays.

    Flag of Brazil

    Brazil

    ANVISA

    Emerging

    ANVISA RDC 657/2022 cyber annex; SBOM expectation tracking IMDRF N73.

    CycloneDX vs SPDX

    Both are accepted everywhere SBOM is required. CycloneDX (OWASP) has richer vulnerability integration via VEX and broader medical-device tooling. SPDX (Linux Foundation, ISO/IEC 5962:2021) has stronger licensing metadata and longer regulatory history. If you have no preference, default to CycloneDX 1.5 JSON.

    SBOM is not enough

    An SBOM lists components. Regulators want to know which components are exploitable in your device. Ship a VEX file (CycloneDX VEX or CSAF 2.0) alongside the SBOM, declaring exploitability status for each known CVE. FDA reviewers explicitly look for this in §524B submissions.

    Frequently asked

    What format should my SBOM be in?

    CycloneDX or SPDX, both in machine-readable form (JSON or XML). The FDA explicitly names both; the EU CRA, PMDA, Health Canada and MFDS accept either. CycloneDX has slightly broader medical-device tooling support; SPDX is the older ISO/IEC 5962:2021 reference.

    Do I need a separate SBOM per market?

    No. Generate one SBOM per release in CycloneDX or SPDX, then distribute the same file to every regulator. The deltas are in the surrounding documentation (vulnerability summary, support level, update timeline), not in the SBOM itself.

    How often must I regenerate the SBOM?

    At every release of the device software, plus whenever a third-party component (library, container image, firmware blob) changes. Most teams automate this in CI so the SBOM ships alongside the build artifact.

    Does the SBOM need to include known vulnerabilities?

    FDA §524B requires a known-vulnerability summary AND the support level for each component. This is typically expressed as a separate VEX document (Vulnerability Exploitability eXchange) referencing the SBOM by hash.