SBOM, SOUP, COTS, and OTS in Medical Device Software: The Complete Guide (2026)
| Interlynk
Modern medical device software is not mostly yours. Analysis of current FDA submissions consistently shows that 75% or more of the average device's software stack is external — open-source libraries, third-party commercial tools, pre-built infrastructure. The code your team actually wrote from scratch is often a minority of what ships.
The moment you cannot answer what is running in a device, you have a compliance problem. You also have a patient safety problem.
Since March 2023, FDA Section 524B has required a Software Bill of Materials for all cyber device premarket submissions. As of February 2, 2026, QMSR brought ISO 13485:2016 into 21 CFR Part 820 as a binding requirement — which means the purchasing controls, supplier evaluation, and design lifecycle processes that govern how you manage third-party software components are now US law, not just international best practice. And the EU Cyber Resilience Act sets the same SBOM expectation for European markets by December 2027.
IEC 62304 has required structured SOUP management for years. Most MDMs haven't enforced it consistently enough to survive a serious audit.
What Is an SBOM in Medical Devices?
A Software Bill of Materials is a machine-readable inventory of every software component in a device — open-source libraries, commercial SDKs, operating system packages, firmware dependencies, cloud APIs your device calls at runtime, and your own proprietary code. All of it.
The ingredients-list analogy works well here: the stakes of a missing entry are patient safety rather than a food allergy.
What must be in an SBOM?
The FDA's June 2025 final guidance references the NTIA Minimum Elements as the baseline. Each component entry should include:
Supplier name
Component name
Version
Unique identifier (CPE or PURL)
Dependency relationships
Author of the SBOM
Timestamp
FDA accepts SPDX and CycloneDX as machine-readable formats. A PDF listing software versions is not sufficient.
What does FDA Section 524B require?
Section 524B of the FD&C Act, effective March 29, 2023, requires manufacturers of "cyber devices" to submit an SBOM covering all commercial, open-source, and off-the-shelf components. FDA started refusing non-compliant submissions on October 1, 2023. The June 2025 final guidance clarified that for cyber devices, SBOMs are mandatory; for other software-containing devices, strongly recommended.
A device qualifies as a cyber device if it:
includes software validated, installed, or authorized by the manufacturer;
can connect to the internet or another device; and
has technological characteristics that could be exploited.
Under QMSR, the QMS processes behind that SBOM —
how you evaluate and qualify the software components in it,
how you monitor suppliers,
how you document design decisions around third-party software
— must now meet ISO 13485:2016 §7.4 purchasing controls as a matter of US regulatory requirement, not just international certification practice.
Real-world example:
A Class II insulin pump with
wireless connectivity uses your proprietary dosing algorithm,
OpenSSL for encryption,
Linux as its operating system, and
a third-party Bluetooth stack.
All four go in the SBOM with version numbers and CVE exposure. When a critical vulnerability hits OpenSSL, you assess impact that day rather than spending two weeks reverse-engineering your own product.
What Is SOUP in Medical Devices? (IEC 62304)
SOUP — Software of Unknown Provenance — covers any software that was not developed specifically for your device, or for which adequate lifecycle development records don't exist. The IEC 62304 definition at §3.1.7 is deliberately cast wide: it captures open-source libraries, commercial software, legacy drivers, pre-trained AI/ML models, cloud service SDKs, and even software your own company wrote for a prior product if the documentation trail isn't intact.
Concrete examples: Windows, Linux, Android (operating systems), Bluetooth and USB stacks (drivers), TensorFlow, OpenSSL, React (libraries), MySQL, PostgreSQL (databases), VxWorks, FreeRTOS (RTOS), AWS and Azure SDKs (cloud APIs).
The core challenge with SOUP
Standard software lifecycle management assumes you wrote the code, you hold the requirements documents, and every line traces back to a design decision. With SOUP, none of that is true. You have a library that does what it says on the label — most of the time — and a version number. You cannot audit how it was developed, you cannot guarantee the author followed any medical software standard, and you cannot control whether they release patches or when.
That is not a theoretical concern. It is the practical situation for the majority of the software in most devices.
IEC 62304 SOUP requirements by safety class:
Class A (no injury possible if the software fails): Identify the SOUP item and version. Minimal additional documentation required.
Class B (non-serious injury possible): Class A requirements, plus documented functional requirements for the SOUP, conditions of use, and known anomalies.
Class C (serious injury or death possible): Class B requirements, plus all available information about the SOUP's development history and testing, with an adequacy evaluation.
Under QMSR, ISO 13485 §7.3 (design and development) now governs how SOUP is integrated into the device design. §7.4 governs supplier evaluation and monitoring for SOUP vendors. Both are now inspectable under US law. If your SOUP registry and supplier qualification records don't hold up to ISO 13485 scrutiny, you have a QMSR gap — not just an IEC 62304 documentation issue.
Real-world example: An ECG monitor uses a popular open-source waveform rendering library from GitHub — hasn't been touched in 18 months. A new contributor introduces a regression that causes incorrect waveform scaling in certain display conditions. Without version pinning and post-market surveillance on CVE and release feeds, the MDM finds out when a clinician flags anomalous readings. With a proper SOUP registry, the new release triggers a review before it gets anywhere near the device.
OTS and COTS: The Distinction That Matters for Documentation
OTS (Off-the-Shelf) software is any pre-built software not designed for your device — built for general use, integrated into your product, source code typically not accessible for modification. COTS (Commercial Off-the-Shelf) is the commercially licensed subset: a vendor sells it, charges for it, owns the IP. So all COTS is OTS, but not all OTS is COTS — open-source software is OTS without being commercial. Both categories qualify as SOUP under IEC 62304, and both must appear in your SBOM.
The documentation implications differ. Open-source OTS gives you access to the codebase and development history, even if that history wasn't produced under medical software standards. Commercial OTS typically gives you neither — just a license agreement and whatever testing the vendor performed on their own terms.
FDA's OTS guidance requires evidence that OTS software won't degrade device performance or safety: a documented rationale for selecting it, testing evidence that it works correctly in your specific device context, and a plan for managing vendor lifecycle events. IEC 62304 requires that validation even if the software is completely unmodified. Vendor testing doesn't count as your testing.
The lifecycle exposure that often gets underestimated: when a COTS vendor announces end-of-life for something embedded in your device, the options are limited. Extended support negotiation is expensive. Forking the codebase is usually impossible under the license. Redesigning around a replacement, in a regulated context, may mean a new 510(k). Under QMSR, ISO 13485 §7.4 requires you to have evaluated this lifecycle risk before selection and to monitor it throughout the product's commercial life — not discovered it after a vendor EOL announcement.
Custom Code | Open-Source (SOUP) | OTS/COTS (SOUP) | |
|---|---|---|---|
IEC 62304 class | A, B, or C | B or C if safety-critical | B or C if safety-critical |
FDA 524B SBOM | Required | Required | Required |
Accepted SBOM format | SPDX or CycloneDX (machine-readable) | ||
Risk analysis | ISO 14971 risk management | SOUP risk analysis Functional + safety impact | SOUP risk analysis |
CVE monitoring | You own it fully | NVD + CISA KEV | NVD + vendor advisories |
Source code access | Full access | Usually full access | Usually closed |
Patch control | You control release timing | Fork or wait for upstream | Vendor dependent |
License type | Proprietary | MIT, Apache, GPL, BSD | Commercial license required |
Real world examples | Device UI logic, Dosing algorithm, Sensor fusion code | Openssl, libcurl, Linux kernel | Windows 10, VxWorks, Azure SDK |
When Unknown Provenance Costs More Than Compliance Points
In December 2021, the log4shell vulnerability (CVE-2021-44228) hit Apache Log4j — a Java logging library embedded in a significant portion of enterprise software worldwide. CVSS 10.0. Remote code execution via a single malicious string in a log entry.
Medical device manufacturers were among those scrambling. The specific problem: many couldn't answer whether their devices used Log4j at all, because they had no reliable component inventory. Some ran it in backend cloud systems that processed device data. Others had it embedded in a third-party component integrated years earlier. FDA issued a Safety Communication in January 2022 specifically addressing Log4j in medical devices.
Companies with maintained SBOMs and SOUP registries assessed their exposure in hours. Companies without them spent weeks — and some couldn't reach full certainty.
The same pattern recurred with OpenSSL (CVE-2022-0778, CVE-2022-3786), with embedded Linux kernel vulnerabilities, and with supply chain attacks against CI/CD infrastructure used in device development. In late 2025, FDA warned that Abbott's FreeStyle Libre 3 sensors were delivering incorrect low-glucose readings due to a firmware defect — seven deaths and over 700 injuries. Software defects in devices where the stack isn't fully understood and controlled have clinical outcomes.
Unknown provenance is a patient safety variable.
The Regulatory Landscape in 2026
Regulation | What it requires | Status |
|---|---|---|
FDA §524B (FD&C Act) | Machine-readable SBOM (SPDX or CycloneDX) covering all commercial, open-source, and OTS components | In force March 2023; enforced Oct 2023 |
FDA June 2025 Final Guidance | Clarifies §524B scope for device modifications; adds Section VII for cyber devices | Active |
FDA QMSR (21 CFR Part 820) | ISO 13485:2016 incorporated by reference — purchasing controls (§7.4), design controls (§7.3), and supplier monitoring now US law | Effective February 2, 2026 |
IEC 62304 | SOUP management, risk analysis, version documentation for Class B and C software | Active international standard |
EU Cyber Resilience Act | SBOM required for all products with digital elements sold into EU | In force Dec 2024; SBOM compliance due Dec 11, 2027 |
ISO 14971 | Risk management framework; SOUP risks must be incorporated | Active international standard |
Executive Order 14028 | SBOM for federal procurement | Optional |
One practical consequence of QMSR that catches teams off guard: FDA investigators will now review your QMS records against ISO 13485 requirements, including records created before February 2026. If your SOUP management processes, supplier qualification documentation, and design control records for third-party components don't map cleanly to ISO 13485, that gap will show up in an inspection — not just in a notified body audit.
On SBOM as a living document: Device modifications — software updates, supplier changes, new component integrations — may require a new premarket submission. When they do, §524B applies fully, which means a complete and current SBOM. The SBOM produced at initial clearance is not the artifact that carries you through the device's commercial life.
10 Practices Worth Enforcing in 2026
1. Generate SBOMs from the build, not from memory. Hand-curated SBOMs are stale the moment a dependency changes. SCA tools integrated directly into your CI/CD pipeline produce SBOMs that are versioned, signed, and accurate to the build.
2. Cover the container layer. For cloud-connected devices, the SBOM must include every layer of the container image — base OS, runtime, middleware — not just application code. The component that introduces the vulnerability is often not the one you wrote.
3. Separate the SBOM from the SOUP registry. The SBOM tells you what's there. The SOUP registry records the risk analysis, the version you're pinned to, known anomalies, and vendor support timelines. Different artifacts, different owners, both required.
4. Pin versions. Floating dependencies mean the device software changes without a deliberate decision. Under IEC 62304, a version change to a SOUP item is a device software change. Treat it that way.
5. Monitor CVE feeds continuously for every SOUP component. NVD, OSV, and vendor security advisories all need to be in scope. When a new CVE hits something in your SBOM, you need a documented response process ready — not a week of triage to figure out who owns it.
6. Classify SOUP by safety class before you integrate it. A display formatting library and an insulin dosing algorithm have completely different IEC 62304 documentation requirements. Make that classification call explicitly and document the rationale. Retroactive classification under audit pressure is not a good process.
7. Run your own validation on OTS/COTS components. Vendor testing tells you the software works in the vendor's environment. You need evidence it works in yours — with your hardware, under your operating conditions, in the safety class context you've assigned it.
8. Record vendor lifecycle commitments in the SOUP registry. When this vendor plans to end support for this version is a risk factor your ISO 13485 §7.4 process should have captured at selection. If it wasn't, document what you know now and flag the gap.
9. Treat AI/ML models as SOUP. A pre-trained model from a third party, a fine-tuned foundation model, a model trained on a pipeline you don't fully control — all of these have unknown development provenance under IEC 62304. They need the same risk analysis as any other SOUP item, plus specific attention to training data integrity and model version control.
10. Extend SBOM coverage to cloud infrastructure. For cloud-connected devices, the operational dependency graph includes virtual machine images, container registries, cloud-native services, and third-party APIs. The SBOM that stops at application code doesn't cover the component that gets exploited.
Frequently Asked Questions
Is Windows an example of SOUP?
Yes — and so is Linux, Android, and any other OS you didn't develop under your own quality management system. Under IEC 62304 §3.1.7, Windows qualifies because adequate records of its development process per the standard don't exist. Microsoft's internal testing and your IEC 62304 SOUP validation are different things.
Is an SBOM required by FDA for all medical devices?
The mandatory requirement under §524B covers cyber devices specifically — devices with software the manufacturer validates or authorizes, plus the ability to connect to the internet or another device. For non-cyber devices that still contain software, FDA strongly recommends an SBOM. The June 2025 guidance didn't change that scope, but it did clarify that certain modifications to existing devices trigger full §524B compliance.
What SBOM format does FDA accept?
SPDX (maintained by the Linux Foundation) and CycloneDX (maintained by OWASP) are both accepted. A spreadsheet or PDF doesn't qualify as machine-readable under FDA's definition. Both formats support the NTIA minimum elements FDA references in its guidance.
What is the difference between COTS and OTS?
OTS is the broader category — any pre-built software not designed for your device. COTS is commercially licensed OTS: you pay for it, a vendor owns it. Open-source software is OTS but not COTS. In practice the compliance obligations are similar, but the documentation paths differ because COTS vendors typically control source access and patch timing in ways open-source maintainers don't.
Does open-source software count as SOUP?
Yes. Open-source code is developed outside your QMS. The fact that a project is well-documented or widely used doesn't change the IEC 62304 classification — adequate development records under the standard don't exist for open-source projects because the standard wasn't part of how they were built. Risk analysis appropriate to the safety class you assign is required.
What happens when a SOUP component reaches end-of-life mid-lifecycle?
The MDM must assess whether the device can still be maintained in a cybersecure state. If security patches won't be available for newly discovered vulnerabilities, the device risks becoming "unable to be reasonably protected against current cybersecurity threats" — the threshold in FDA's postmarket cybersecurity guidance that triggers disclosure and potential remediation obligations. Under QMSR, your ISO 13485 §7.4 supplier monitoring process should have flagged this risk before it materialized.
How Interlynk Helps?
Keeping an accurate, living SBOM across a device portfolio — cloud components, open-source SOUP, COTS dependencies, AI/ML models — is an operational problem. It requires automation at the build level, continuous vulnerability monitoring tied to device context, structured SOUP risk tracking, and the ability to generate FDA-compliant artifacts on demand. QMSR adds the requirement that all of this sits inside a QMS that maps to ISO 13485.
Interlynk builds that infrastructure: automated SBOM generation, SOUP registry management, supplier monitoring, CVE tracking per device, and post-quantum cryptography readiness assessment.
Book a demo or explore our open-source toolset.