SBOM vs SOUP: what's the difference?.

If your software file already has a SOUP list in it, the first time someone asks for an SBOM the natural reaction is: don't we already have one of those?

It's a fair question. Both are lists of software you didn't write. Both name components, versions, and suppliers. Both exist because regulators want to know what's inside your device beyond the code your own team produced. Plenty of teams have handed over their SOUP list when a customer asked for an SBOM, and "your SOUP list in a new format" is a common way of describing the SBOM.

That shorthand is sensible as far as it goes, and it will carry you most of the way. But the two documents come from different worlds, answer different questions, and each covers ground the other doesn't. Once you see the distinction, keeping both accurate stops being duplicated effort and becomes one process with two outputs.

The short answer: SOUP is an IEC 62304 safety classification applied to pre-existing software in your device, plus the evaluation work that follows from it. An SBOM is a machine-readable inventory of every component in your software, including the dependencies you didn't choose (The transient dependencies). Most SBOM components are also SOUP items, but neither replaces the other: the SBOM gives you visibility and vulnerability monitoring, the SOUP records hold the safety judgement.

SOUP is a classification, not a document

SOUP (Software of Unknown Provenance) comes from IEC 62304, and it's worth being precise about what it means, because the common shorthand of "third-party software" isn't quite right.

IEC 62304 defines SOUP as a software item that either wasn't developed for the purpose of being incorporated into the medical device, or was developed previously without adequate records of the development process. The test is verifiability, not origin. Most third-party libraries, runtimes, and operating-system components are SOUP because you can't audit how they were built. But the definition cuts both ways. Code your own team wrote years ago, before your current IEC 62304 processes existed, is SOUP too. And a third-party component isn't automatically SOUP, some suppliers offer versions of their components developed and documented against IEC 62304 (Qt is one example), and a component whose development records you can verify against the standard may fall outside the classification.

Once a software item is classified as SOUP, IEC 62304 attaches obligations to it. You identify each item by name, manufacturer, and a unique version designator. You specify the functional and performance requirements the item needs to meet, and the hardware and software it needs to run. You place it under configuration management. And, for the safety classes where it matters, you evaluate the item's published anomalies, the bugs its own developers have admitted to, for their potential to contribute to a hazardous situation. That evaluation feeds your ISO 14971 risk file.

Notice what SOUP is really about: it's a safety concept. The standard's concern is that you're building a device on code whose quality you can't verify, so it asks you to compensate with requirements, testing, and risk evaluation. Nothing in IEC 62304 says the resulting list has to be machine-readable, cover your whole dependency tree, or be shareable with anyone outside your technical file.

An SBOM is an inventory built for machines

An SBOM (Software Bill of Materials) is a structured, machine-readable list of the components in your software, usually produced in one of two standard formats, SPDX or CycloneDX. If SOUP is a classification you apply, an SBOM is a document you generate, and in practice you generate it from your build rather than curating it by hand. (If you want the full primer, start with what an SBOM actually contains.)

The baseline content comes from the US government's NTIA minimum elements: supplier, component name, version, unique identifiers, dependency relationships, the author of the SBOM data, and a timestamp. The FDA's premarket cybersecurity guidance, finalised in June 2025, builds on that baseline for the SBOM required with cyber device submissions under Section 524B, and asks for each component's level of support and end-of-support date as well. CISA, the US cybersecurity agency, published an updated set of minimum elements in 2025 that adds fields like component hashes and licence information, so the expected baseline is still moving, in the direction of more detail rather than less.

Two of those fields do work that no SOUP list does.

The unique identifier is what makes monitoring possible. Each component carries a standardised machine-readable code (a PURL or CPE) that pins down exactly which piece of software it is. That identifier is what lets a tool match your components against the public databases of known vulnerabilities (CVEs) automatically. A SOUP list names the supplier and version, but a human still has to do the matching. The identifier turns a static record into something you can monitor continuously, which is the entire point of the postmarket side of the FDA's expectations.

Dependency relationships reach further down the tree. Your SOUP list records the components you deliberately brought in. The FDA expects an SBOM to also cover transitive dependencies, the libraries your libraries pull in without asking you. For a typical modern codebase that's the majority of the components, and it's where vulnerabilities most often hide, precisely because nobody chose those components on purpose.

Where they overlap, and where each stands alone

Lay the two side by side and the overlap is obvious: most of the third-party components on your SBOM are also SOUP items under IEC 62304. Same libraries, same versions, same suppliers. That overlap is why the "SOUP list in a new format" shorthand survives.

But each covers ground the other can't.

The SBOM goes wider. Transitive dependencies, machine-readable identifiers, support and end-of-support dates, and a format you can hand to a hospital security team or a regulator's tooling. A SOUP list has none of that, and adding it by hand doesn't scale past a handful of components.

The SOUP record goes deeper. An SBOM tells you what's there. It says nothing about whether that's acceptable. The SOUP record is where you document what the component is for, what requirements it has to meet, and what you concluded when you evaluated its known anomalies against your hazard analysis. No SBOM format has a field for "we reviewed the maintainer's bug tracker and none of the open defects can contribute to a hazardous situation". That judgement is the safety work, and it only exists in your IEC 62304 documentation.

And SOUP covers software an SBOM may never see. That legacy in-house code from before your current processes? It's SOUP, with all the evaluation obligations that follow, but it won't show up as a third-party component in a generated SBOM at all. If your SOUP process starts from the SBOM alone, that code is invisible to it.

One process, two outputs

The practical conclusion isn't to maintain two parallel lists and hope they agree. It's to let each artefact do its job in a single process.

Generate the SBOM from your build, every release, so the inventory is accurate by construction rather than by diligence. Treat it as the source of truth for which components and versions are in the device. Then link your SOUP records to it: for each SOUP item, the intended use, the requirements, and the anomaly evaluation live in your technical file, referencing the component the SBOM identifies. When monitoring flags a new vulnerability in one of those components, it routes into your ISO 14971 risk file through the same door your SOUP anomaly evaluations already use.

Run it that way and the question "is your SOUP list up to date?" answers itself, because the inventory underneath it is regenerated with every build. The auditor gets a SOUP list that matches reality. The FDA gets a conformant SBOM. Your customers get a document their security tooling can read. One process, and every audience served from it.

The bottom line

SOUP is the IEC 62304 safety classification you apply to pre-existing software and the evaluation work that follows from it. An SBOM is the machine-readable inventory that says exactly what's in your device, all the way down the dependency tree. They overlap on the components but not on the job: the SBOM gives you visibility and monitoring, the SOUP records hold the safety judgement.

You need both, and the good news is they feed each other. The SBOM is the most efficient way to keep your SOUP inventory current, and your SOUP process is what turns the SBOM from a list into evidence.

Frequently asked questions

Is a SOUP list the same as an SBOM?

No. A SOUP list is the IEC 62304 record of pre-existing software items and their safety evaluation, kept in your technical file. An SBOM is a machine-readable inventory in a standard format (SPDX or CycloneDX) covering every component, including transitive dependencies. The same components appear on both, but a SOUP list won't satisfy an FDA request for an SBOM, and a generated SBOM doesn't contain the safety evaluation IEC 62304 requires.

Is all third-party software SOUP?

No. The IEC 62304 test is whether adequate development records exist, not who wrote the code. Most third-party libraries and operating-system components are SOUP because you can't verify how they were built, but a component developed and documented against IEC 62304 may fall outside the classification. In the other direction, your own legacy code can be SOUP if it predates your current development processes.

Does an SBOM replace SOUP documentation?

No, and it isn't meant to. The SBOM tells you what's in the device; the SOUP records document what each item is for, the requirements it must meet, and your evaluation of its known anomalies against your ISO 14971 risk file. The practical approach is to generate the SBOM from each build and link your SOUP records to it, so one process keeps both accurate.

If you already have an SBOM and want to know whether it would satisfy an FDA reviewer, that's something you can check yourself in a few minutes, without a sales call.