What is an SBOM? Think food labels, but for software.

You're doing the weekly shop. Your daughter has a nut allergy, so you check every label. Ingredients list, bold allergen warnings, the lot. You're not reading it because you find food chemistry fascinating. You're reading it because one wrong ingredient could send her to hospital.

An SBOM works the same way. It's an ingredients list for software. And the allergens you're scanning for? Known cybersecurity vulnerabilities.

What an SBOM actually does

SBOM stands for Software Bill of Materials. It's a structured list of all the third-party software components in your product, with their exact version numbers.

Why exact versions? Because vulnerabilities are version-specific. A security flaw in OpenSSL 3.0.0 might be fixed in 3.0.1. If your SBOM just says "OpenSSL" without the version, you cannot tell whether you're affected. It's like an ingredients list that says "contains nuts" but doesn't tell you whether they're peanuts or tree nuts, critical information if you're only allergic to one.

The purpose is straightforward: know what's in your product so you can monitor for problems. When a new vulnerability is reported (and they're reported constantly), you check your SBOM. Affected? Evaluate and act. Not affected? Move on.

Why this matters for medical devices

Software vulnerabilities can impact the confidentiality, integrity, or availability of your device. In medical device terms, that's a path to patient harm.

Confidentiality: patient data exposed. Integrity: diagnostic results altered. Availability: device stops working when it's needed. None of these are acceptable. All of them are possible if you're running software with known security flaws.

The SBOM is your early warning system. You cannot protect against vulnerabilities in components you don't know you're using.

Do you need an SBOM for an FDA 510(k)?

Yes.

The FDA's 2023 cybersecurity guidance (Section 524B of the FD&C Act, added by the 2022 Omnibus) requires an SBOM for cyber devices. It's a mandatory submission element alongside your cybersecurity risk assessment and vulnerability analysis.

The FDA isn't asking for an SBOM because they want busywork. They want to verify that you know what's in your product and that you can identify vulnerabilities effectively. A complete, well-structured SBOM demonstrates that your vulnerability management has a solid foundation. A missing or incomplete one suggests it doesn't.

Reviewers will check whether your SBOM covers all components (including transitive dependencies (the libraries your libraries use)), uses a standard format (CycloneDX or SPDX), and correlates to your vulnerability analysis. If your SBOM shows 50 components but your vulnerability scan found issues in libraries that aren't listed, expect questions.

Do you need an SBOM for EU MDR?

No. There's no explicit SBOM requirement in the EU MDR.

However, IEC 81001-5-1:2021 (the cybersecurity standard that European Notified Bodies now expect you to follow) does require you to assess third-party software for existing vulnerabilities and continue monitoring for newly reported ones throughout your product's lifecycle.

How do you identify vulnerabilities in third-party software without knowing what third-party software you're using and which versions? You don't. An SBOM is the practical answer, even if the regulation doesn't name it directly or require you to provide it in your technical file.

Most manufacturers targeting both FDA and EU markets maintain an SBOM regardless. It's the foundation for vulnerability monitoring, and you'll need that capability for either jurisdiction.

Back to the shopping analogy

Imagine the allergen warnings disappeared from food packaging. You'd have to research every ingredient yourself, track which products had been reformulated, and hope nothing slipped through. For a busy parent, that's untenable.

That's what software vulnerability management looks like without an SBOM. You're guessing, searching manually, and hoping you catch problems before they cause harm.

The SBOM puts the ingredients list back on the label. Bold warnings included.

The bottom line

An SBOM is your software ingredients list. It tells you exactly what third-party components are in your product and which versions you're running, so you can check for known vulnerabilities.

The FDA requires one. The EU MDR doesn't explicitly, but IEC 81001-5-1 expects you to monitor third-party software for vulnerabilities, and an SBOM is how you do that in practice.

Know what's in your product. Monitor it. That's the point.