Medical device SBOMs.

A packaged food product carries an ingredients list and allergen warnings on the label so that a shopper with a nut allergy can answer one question quickly: is anything inside this product going to cause harm? The label has to be precise. Peanuts and tree nuts are different problems for different allergies, and an ingredients list that just says "nuts" is not good enough.

An SBOM applies the same logic to software. A Software Bill of Materials is a structured, machine-readable inventory of every third-party component in a product, with exact versions, that lets a manufacturer, regulator, or customer match what is inside against known cybersecurity vulnerabilities. Version specificity matters for the same reason allergen specifics matter: a flaw fixed in OpenSSL 3.0.1 is still present in 3.0.0, and a list that just says "OpenSSL" cannot answer the question.

What an SBOM is

An SBOM is a structured, machine-readable document that lists the third-party software components inside a product. "Component" is SBOM vocabulary for a Software Item (IEC 62304) often is SOUP (Software of Unknown Provenance) or a COTS item: a library, framework, runtime, or operating-system piece brought in from elsewhere rather than written in-house. A Software Item in the software architecture may map to one component, several, or none, depending on how it was assembled.

Two further characteristics matter.

It includes exact versions. Vulnerabilities are version-specific, which is why a component named without a version is not actually useful for vulnerability monitoring.

It captures transitive dependencies. The libraries a project chooses to use bring in libraries of their own, which bring in further libraries. In modern software, transitive dependencies typically outnumber direct ones by ten to one or more. An SBOM that lists only the components a developer chose by hand is incomplete by definition.

Why SBOMs matter for medical devices

Software vulnerabilities can compromise the confidentiality, integrity, or availability of a device. In medical device terms, each is a path to patient harm. Confidentiality breaches expose patient data. Integrity failures alter diagnostic results or therapy parameters. Availability failures take a device offline when it is needed.

A manufacturer cannot protect a device against vulnerabilities in components it does not know are present. The SBOM is the inventory that closes that gap; it turns a constant stream of public vulnerability disclosures into a finite, answerable question.

For medical devices manufactures SBOMs not a completely new activity layered on top of the QMS. It extends process and standards the team already follows.

IEC 62304. The SBOM is the structured, machine-readable extension of the SOUP and COTS lists already required in the software architecture. The components are the same; the additional fields (versions, identifiers, support level, end-of-support date) are what make vulnerability monitoring possible.

ISO 14971. A vulnerability in a SOUP component is a foreseeable software-related hazard. The SBOM is the inventory that lets a manufacturer keep its hazard analysis current as new vulnerabilities are disclosed throughout the product lifecycle.

ISO 13485. The SBOM is a controlled document. It belongs inside the QMS, with version control, change control, and traceability to releases like every other technical-file artefact.

In short: an SBOM is a continuation of existing software item, SOUP, and risk management work, not a new cybersecurity workflow that needs to be built from scratch.

The regulatory landscape, region by region

United States (FDA)

In the United States, SBOMs are explicitly required for "cyber devices" under Section 524B of the Federal Food, Drug, and Cosmetic Act, added by the 2022 Consolidated Appropriations Act and effective from 29 March 2023. The SBOM must be machine-readable, NTIA-aligned (the NTIA, or National Telecommunications and Information Administration, defined the baseline data fields every SBOM should contain), submitted through eSTAR, and consistent with the manufacturer's vulnerability analysis. Submissions that lack an adequate SBOM can be rejected upon submission with a “Refuse to Accept”; this is not theoretical, reviewers do check. In June 2025 a cybersecurity guidance refresh added two further fields for every component: support level and end-of-support date.

European Union (EU MDR and IEC 81001-5-1)

In the European Union, the picture is principles-based rather than prescriptive. EU MDR (Regulation 2017/745) requires manufacturers to follow “State of the art“ for cybersecurity. The standard IEC 81001-5-1:2021 fills the gap. Notified Bodies treat the standard as state of the art, and it requires manufacturers to monitor third-party software for vulnerabilities throughout the product lifecycle. Meeting that obligation in practice requires an SBOM, even though the regulation or standard itself never says so. Formal harmonisation of IEC 81001-5-1:2021 under MDR is expected by May 2028, but Notified Bodies are already assessing against the standard now.

United Kingdom

The United Kingdom is the most uneven of the jurisdictions. UK MDR 2002 contains no explicit cybersecurity requirements and no premarket SBOM requirement; the regulation predates the smartphone. The Medical Devices (Post-market Surveillance Requirements) (Amendment) Regulations 2024, in force from 16 June 2025, brought cybersecurity flaws into vigilance reporting via MHRA guidance. NHS procurement adds a separate effective requirement: the Digital Technology Assessment Criteria (DTAC) and Cyber Essentials, including a 14-day fix expectation for vulnerabilities scoring CVSS 7 or higher (CVSS, the Common Vulnerability Scoring System, is the standard severity scale for software flaws). The practical effect is that UK manufacturers need an SBOM even though no UK regulation names one.

The EU Cyber Resilience Act (CRA)

The EU Cyber Resilience Act is worth a brief mention because it generates more confusion than its scope justifies. Medical devices regulated under MDR or IVDR are excluded (Article 2, paragraphs 2a and 2b). The exclusion is narrower than many assume: companion apps that are not themselves medical devices, wellness products, and accessories often fall within CRA scope. Pure cloud services sit outside the CRA entirely; they fall under the NIS 2 Directive instead. System boundaries are worth checking carefully, particularly for manufacturers with adjacent non-device products. The EU Cyber Resilience Act and medical devices →

International (IMDRF)

The IMDRF N73 guidance recommends SBOMs as international best practice and is a useful reference for manufacturers navigating multiple jurisdictions. IMDRF Principles and Practices for SBOM (PDF) →

The practical synthesis

A manufacturer selling internationally needs an SBOM regardless of which regulator names it. The FDA's makes an opinionated requirements for SBOMs and there content. This is useful as where other authorities don’t offer guidance, as building to FDA expectations should satisfy the rest.

SBOM formats: CycloneDX and SPDX

Two machine-readable formats meet regulatory expectations: CycloneDX and SPDX. Both are widely supported by tooling, both are accepted by the FDA, and either satisfies EU and UK expectations. Their origins differ. CycloneDX has stronger roots in security and vulnerability workflows; SPDX began in licence compliance and now handles security use cases as well. The choice between them is operational rather than regulatory; what matters is picking one and staying consistent across releases and across teams. Mixing formats creates avoidable friction when SBOMs need to be merged across components or compared between versions.

What makes a medical device SBOM different

For medical devices, the FDA sets the practical bar for what an SBOM must contain. Its requirements build on the NTIA Minimum Elements (a 2021 baseline issued by the US National Telecommunications and Information Administration) with two medical-device-specific additions on top.

The NTIA fields are: supplier name, component name, version, unique identifier such as a Package URL (PURL) or Common Platform Enumeration (CPE), dependency relationships, the author of the SBOM data, and a timestamp.

The FDA's June 2025 guidance adds support level (whether the component is actively maintained, no longer maintained, or abandoned by the supplier) and end-of-support date (when the supplier will stop providing security updates) for every component. Component hashes are optional but recommended; both CycloneDX and SPDX support them, and they help with vulnerability matching and integrity checks.

The reasoning is patient-safety driven. A manufacturer needs to know not only what is inside a device, but whether the supplier will still be issuing security patches when the device is still in clinical use five years on.

What you do with an SBOM

An SBOM is not a deliverable that sits in a drawer until the next submission. There are three things a manufacturer does with one.

Generate it. Once per release, ideally automated as part of the CI/CD pipeline. SBOMs need to match the software that actually shipped, which means regenerating them every time a build goes out. The next section covers the tooling landscape.

Monitor it. Vulnerabilities are reported constantly. New CVEs (Common Vulnerabilities and Exposures, the public identifiers used to track individual flaws) need to be matched against the SBOM components. When there is a match triage must take place, prioritised using exploitability and severity data, and documented. The decisions, not just the patches, are what regulators expect to see.

Act on findings. Issue a patch when required, and mitigate with controls or guidance where it is not. This includes documenting why a vulnerability does not impact security or safety. The reasoning is something you may have to defend.

Generating an SBOM

SBOMs are generated by tools, and not usually assembled by hand. Manual assembly fails on three counts:

• Scale. A typical medical device application contains hundreds or thousands of components once transitive dependencies are counted. Manual tracking misses things, and the missed ones are usually the transitive components reviewers ask about.
• Cadence. SBOMs need to be regenerated for every release, not produced once at submission and filed away. Manual maintenance breaks down under release pressure.
• Precision. The errors reviewers flag most often (missing transitive dependencies, mismatched versions, components in the SBOM but not in the vulnerability scan) are exactly the errors manual processes produce.

The good news is that the tooling landscape is mature. There are plenty of capable open source options (Syft, Trivy, cdxgen, and the CycloneDX CLI), alongside commercial alternatives for teams that prefer paid support. Generation itself is essentially free; the open source tools are widely used in production, including by medical device manufacturers. The job is choosing the right tool for each ecosystem in the device's software stack. JavaScript, Python, .NET, Java, and Go are well covered out of the box; mobile platforms have their own conventions; container images need their own scanner.

C/C++ and embedded firmware are the partial exception. Automated tooling cannot discover dependencies the way it can for managed-package ecosystems, because the language has no centralised package manager. Even there, the right approach is to maintain a structured component list and convert it using tooling such as the CycloneDX CLI, rather than assembling the SBOM in a document by hand.