Frequently asked.

They overlap heavily, but they aren't the same thing, and one doesn't replace the other.

SOUP (Software of Unknown Provenance, sometimes Software of Unknown Pedigree) is an IEC 62304 classification. It covers any pre-existing software item used in the device whose development history and compliance with IEC 62304 you can't fully verify. That usually means third-party libraries, runtimes, operating-system components, and commercial off-the-shelf software, but it can also include legacy code your own team wrote before your current IEC 62304 processes were in place. The test is verifiability, not origin: third-party software isn't automatically SOUP. Some suppliers offer IEC 62304-certified versions of their components (Qt is one example), and a component whose development can be verified against the standard may fall outside the SOUP classification. IEC 62304 requires you to identify each SOUP item, place it under configuration management, and evaluate its known anomalies and residual defects for their impact on safety.

An SBOM (Software Bill of Materials) is an inventory format, not a classification. It's the structured, machine-readable list of the third-party and open-source components in your software, with the exact versions, unique identifiers, supplier, support level, and end-of-support dates that make vulnerability monitoring possible.

The two overlap but aren't interchangeable. Most third-party components on your SBOM will also be SOUP under IEC 62304, so the SBOM is the most efficient way to keep your SOUP inventory current. But each does something the other doesn't. A SOUP list already records the supplier and version; the SBOM's distinctive contribution is the unique identifier (a PURL or CPE) for each component. Without that machine-readable identifier, you can't automatically match your components against CVE databases, which is what turns the inventory into something you can monitor for vulnerabilities at scale. The SBOM also reaches further down the dependency tree: the FDA expects both direct and transitive dependencies (the libraries your libraries pull in, covered in the question below), whereas a SOUP list usually captures only the components you deliberately brought in. The SOUP classification, in the other direction, can cover pre-existing software, including legacy in-house code, that wouldn't appear as a component in an SBOM at all.

No. An SBOM lists the third-party and open-source components in your software, with their versions and suppliers. It doesn't contain your source code, your proprietary logic, your algorithms, or your architecture. It's an ingredients list, not the recipe: it names the off-the-shelf parts but says nothing about how you combined them into a working device. The IP that matters is almost never the list of common libraries you used (half the industry uses the same handful), it's what you built on top of them, and that isn't in the SBOM.

It's also worth remembering that sharing an SBOM isn't publishing it. It goes into your confidential FDA submission, not onto the open web, and IMDRF guidance (N73) recommends SBOMs be treated as sensitive information shared through protected channels; hospital customers typically receive one under an NDA. Anything an SBOM does reveal, the off-the-shelf components, is the easiest thing for anyone to recover from shipped software anyway, so producing one doesn't widen the exposure you already have.

Full blog post: Won't an SBOM give away my IP or source code?

Every released build of your device. An SBOM is only useful if it matches the binary that ships, so generation should be wired into your CI pipeline alongside the build itself. For maintained devices already on the market, expect to re-issue the SBOM for each new release. Corresponding VEX update, a document on the status of the vulnerabilities identified in the SBOM, whenever a new vulnerability becomes relevant or analysis identifies it as unexploitable.