Software of Unknown Provenance (SOUP) in Medical Devices

In the projects we deliver at Somco for medical device manufacturers, the topic of SOUP almost always comes up. Whether we’re building a user interface in Qt or implementing device logic in C/C++, sooner or later someone asks: “Can we use this library?” or “Does Qt qualify as SOUP?

For medical device manufacturers, this is a constant balancing act — leveraging proven third-party software solutions to accelerate development and reduce costs, while maintaining full control over patient safety and regulatory compliance.

Understanding how to navigate this balance is crucial. Let’s take a closer look at what really matters when working with SOUP.

Here’s what you will learn:

• what SOUP is and why such terminology is used in medical device software development,
• key risks and regulatory challenges it introduces,
• how major standards and regulations (IEC 62304, ISO 14971, FDA, MDR/IVDR) address SOUP management,
• and best practices to ensure compliance and safety, such as using SBOMs and partnering with experienced developers.

Develop medical device software that meets the highest standards of safety and performance.
Start your project with confidence – partner with Somco Software.

 

What Constitutes SOUP in Medical Devices?

In the context of medical device development, SOUP (sometimes called software of unknown pedigree or unknown/uncertain provenance) is defined by IEC 62304 as a “software item that is already developed and generally available and that has not been developed for the purpose of being incorporated into the medical device, or software item previously developed for which adequate records of the development processes are not available.”

In simpler terms, SOUP encompasses any software component used in a medical device without full lifecycle control by the device manufacturer. This can include:

 

• Commercial Off-The-Shelf (OTS) software – e.g. operating systems, drivers, communication stacks – originally created for general or other uses (FDA uses the term Off-The-Shelf Software (OTS) for such components).

 

• Open-source libraries and frameworks – code obtained from open communities (where anyone can contribute or access the source) that the manufacturer leverages.

 

• Third-party libraries and previously developed proprietary code – software modules the manufacturer (or a partner) created for another purpose or product, for which detailed development documentation or verification records are missing.

 

It’s important to note that the device’s own software cannot be declared as SOUP simply to evade development controls – IEC 62304 explicitly clarifies that a medical device software system itself cannot be claimed to be SOUP. Instead, SOUP refers to sub-components integrated into the device’s software. In practice, most modern medical devices contain some SOUP, from underlying OS platforms to math libraries or network communication modules.

Manufacturers choose SOUP to save development time, use proven solutions, or incorporate innovative features. The trade-off, however, is that the manufacturer did not design or validate those components from the ground up, so extra scrutiny is required. To learn how controlled software design and prototyping align with regulatory expectations, see: Medical Device Prototype Development.

 

Risks of Using SOUP in Medical Devices

Using SOUP software introduces risks that must be actively managed across technical/patient safety, cybersecurity, regulatory compliance, and legal domains.

As our CTO, Adam Sowa, puts it:

“SOUP isn’t the issue — poor control and lack of awareness are. What matters is how you manage what you didn’t build yourself.”

 

Technical and Patient Safety Risks

Uncontrolled components can undermine device reliability and safety because their behavior outside the manufacturer’s quality process is uncertain. SOUP may contain latent defects or undocumented failure modes and must not be trusted for safety-related functions without independent risk control measures.

Limited transparency makes safety assessment harder, especially where the software can affect clinical performance. Manufacturers should analyze potential failure effects, isolate safety-critical functions from SOUP influence, and design detection and fail-safe mechanisms so the device enters a safe state on crash or erroneous output.

Compatibility and performance are additional concerns: SOUP often has prerequisites (OS, memory, other resources). If unmet or poorly integrated, the device may behave unpredictably. Treat SOUP as a black box that requires explicit requirements, verification of prerequisites, rigorous integration testing, and defensive design.

 

Cybersecurity Risks

By including SOUP, manufacturers inherit its vulnerabilities. Lack of visibility into sub-components increases exposure and complicates patch management. Outdated or unpatched components expand the attack surface and can compromise safety. Provenance uncertainty also raises supply-chain risks. Mitigation requires maintaining a complete software bill of materials (SBOM), continuous vulnerability monitoring, timely updates, and threat-informed security testing. See Medical Device Cybersecurity Standards for a detailed overview of cybersecurity requirements and best practices.

 

 

Regulatory Compliance Risks

Regulators allow SOUP but expect risk-based controls, documented requirements, verification/validation, and lifecycle maintenance equivalent to those for in-house software. Insufficient documentation, testing, or update planning can jeopardize submissions and audits. Post-market obligations include monitoring third-party issues, assessing impact, and deploying corrective actions or patches as needed.

 

Legal and Liability Risks

Manufacturers remain responsible for harms caused by device software regardless of origin. SOUP can introduce licensing obligations, IP exposure, support and warranty risks if suppliers discontinue maintenance, and potential data protection liabilities when handling patient information. Governance, clear contracts where applicable, license compliance, and reduced uncertainty in the software supply chain are essential.

 

Regulatory Requirements and Expectations for SOUP

Both the U.S. FDA and the EU MDR/IVDR accept the use of third-party software in medical devices but require manufacturers to control associated risks. Compliance is typically demonstrated through IEC 62304 (software lifecycle) and ISO 14971 (risk management), supported by relevant guidance that defines life-cycle requirements for integrating external components.

 

 

U.S. FDA: OTS Software and Guidance for SOUP

Concept. FDA refers to third-party components as Off-The-Shelf (OTS); in practice, this overlaps with SOUP. Manufacturers must apply a risk-based approach and provide thorough documentation.

Premarket documentation. OTS inherits the device’s overall documentation level (Basic or Enhanced).

 

• Basic: description of the OTS, risk evaluation, and evidence of integrated testing.
• Enhanced: plus information on development methodologies and continued maintenance (e.g., update and patch handling). If supplier information is limited, provide additional verification or a risk-based justification.

Risk analysis. Include SOUP failure scenarios in the ISO 14971 file and define mitigations appropriate to device risk. A structured risk assessment should be maintained throughout development and updated as new information becomes available.

Quality system & suppliers. Under 21 CFR 820, verify/validate that third-party software meets specified requirements and apply purchasing controls proportionate to criticality.

Cybersecurity & SBOM. Submissions for cyber devices must include a Software Bill of Materials (SBOM) and plans for monitoring vulnerabilities and issuing updates within a secure product development framework.

 

Europe: MDR/IVDR, IEC 62304 and Related Standards

Lifecycle controls. MDR Annex I requires state-of-the-art development, risk management, verification, and validation for all device software. Under IEC 62304, SOUP is placed under configuration management, given explicit requirements in context, and verified accordingly; its verification rigor follows the system safety class.

Risk management. ISO 14971 obliges identification of hazards from software anomalies and justification that benefits outweigh residual risks, with appropriate technical or labeling controls.

Cybersecurity & PMS. Manufacturers must prevent unauthorized access, maintain update mechanisms, monitor third-party issues post-market, and execute corrective actions as needed. Guidance (e.g., MDCG) encourages maintaining an SBOM and conducting vulnerability assessments.

 

Best Practices for Mitigating SOUP-Related Risks

Effective use of software of unknown provenance (SOUP) in medical devices requires a structured lifecycle approach—from selection and qualification to verification, release, and post-market maintenance.

 

 

1. Selection and Supplier Qualification

 

• Prefer components from reputable and actively maintained sources; assess vendor maturity and QMS.
• Ensure transparency—seek documentation on development, testing, and maintenance.
• Apply minimalism: include only what is necessary for the intended functionality.
• Review license compatibility and long-term support options (e.g., maintenance contracts or escrow).
• Establish a formal approval process (technical, quality, legal review) for all third-party additions.

For example, the Qt framework is often an excellent technology choice for medical devices. It provides a broad and cohesive set of modules — covering communication protocols, databases, settings management, sensors, multimedia, and GUI — all maintained within a single ecosystem. Unlike many frameworks that depend on numerous small external libraries, Qt’s integrated architecture simplifies risk and cybersecurity assessments. You perform SOUP evaluation and maintenance once, across a unified framework, instead of repeatedly for many disparate dependencies.

 

2. Requirements, Risk Analysis, and Hazard Mitigation

 

• Define the SOUP’s intended role and constraints within the system.
• Conduct a focused risk analysis: identify hazards from failure, malfunction, or cybersecurity exposure.
• Implement risk controls—isolation of safety-critical functions, redundancy, watchdogs, input validation, and secure design.
• Maintain full traceability: risk → control → requirement → test evidence. For a step-by-step look at how verification and validation support regulatory compliance, read: Verification and Validation Testing for Medical Devices.

 

3. Verification, Testing, and Documentation

 

• Perform unit and integration testing in the device context; include stress, robustness, and fuzz testing as applicable. For a detailed overview of software testing approaches and tools aligned with IEC 62304 and FDA expectations, explore: Medical Device Software Testing.
• Conduct security testing and vulnerability scans.
• Control versions and configurations; document verification results and any anomalies.
• Keep a concise SOUP summary and maintain clear traceability between requirements, risks, and tests, effectively documenting SOUP to satisfy auditors and ensure transparency.

 

4. Open-Source and License Governance

 

• Enforce an OSS approval process with technical and legal review.
• Maintain a complete and regularly updated Software Bill of Materials (SBOM) listing all components and licenses.
• Ensure license compliance (attribution, disclosure, redistribution obligations) and educate development teams on proper use.

 

5. Post-Market Surveillance and Maintenance

 

• Monitor field performance, vulnerability databases, and vendor updates continuously.
• Apply patches or mitigations promptly; log actions and update risk documentation.
• Define and communicate a support and update policy for all active and legacy devices.

SOUP can be safely used when its provenance, function, and risks are fully understood and controlled—through rigorous qualification, testing, documentation, and ongoing lifecycle management.

 

Partnerships and Provenance Tracking: Reducing the Burden

As a decision-maker considering outsourcing software development or integrating third-party components, it’s worth noting how strategic partnerships and modern provenance tracking tools can make SOUP management far more feasible. Collaborating with experienced developers of embedded software for regulated systems can greatly reduce integration challenges and support smoother regulatory approval.

A good development partner will inherently apply many of the best practices outlined. They are likely to have an established QMS and development methodology (e.g., ISO 13485 and IEC 62304 compliant processes) which ensures that even if they incorporate SOUP into your device software, it is done under structured control. They can assist in vetting and selecting reliable third-party components (perhaps they have preferred, pre-qualified libraries they know to be safe). Such partners often maintain an internal knowledge base of known good software components and known issues in the industry, which can be invaluable.

Moreover, development partners can help generate and manage the documentation burden. They can prepare the necessary software documentation for regulatory submissions, including SOUP item lists, hazard analyses, traceability matrices, etc., since they’ve likely done it before. This can significantly shorten your time-to-market by avoiding back-and-forth with regulators on software issues. Partners can also help implement provenance tracking tools – for instance, setting up automated SBOM generation in the build process, and integrating vulnerability scanning into the development pipeline. By doing so, they ensure that from day one, there is a continuous log of all software ingredients and their statuses.

Another benefit of the right partnership is ongoing support. A responsible software partner will offer maintenance contracts or at least guidance on how to maintain the software post-launch. They might provide patches for any third-party components they integrated, or at least notify you promptly when an update is needed. Essentially, they become an extension of your team in monitoring the software landscape. This can offload your internal team significantly, allowing you to focus on core device design and clinical matters while they handle a lot of the technical under-the-hood upkeep.

Transparency is key in such partnerships. Make sure the partner agrees to deliver a full SBOM and associated documentation upon project completion. Also, ensure there are no “mystery binaries” – any component they introduce should be identified and agreed upon. When you have this level of transparency, the software in your device no longer feels of “unknown” provenance – you will know exactly where each piece came from, who developed it, and how it was integrated. This positions you strongly in front of regulators and in the market, as you can demonstrate control over your product’s software supply chain.

In the bigger picture, regulators themselves encourage leveraging expertise and tools to manage software provenance. The push for SBOMs and cybersecurity best practices is really a push for manufacturers to know their software pedigree deeply. Utilizing modern tools (for automated compliance checks, SBOM management, etc.) and expert partnerships is the practical way to meet these expectations without reinventing the wheel.

 

Extending Provenance Control Beyond Software

While SOUP and SBOM primarily address the software side of medical device development, modern regulatory expectations increasingly extend the same principles to the hardware layer. In other words, it’s not just about knowing your software’s provenance – it’s about knowing every component your product is built on.

 

This approach is captured by the concept of the Hardware Bill of Materials (HBOM) – a structured list of all physical components used in a device, including processors, sensors, boards, and modules, along with their manufacturers and sourcing information. Just like an SBOM helps identify and monitor software dependencies, an HBOM ensures traceability and control over the hardware supply chain.

The hardware equivalent of SOUP is sometimes referred to as Hardware of Unknown Provenance (HOUP). It describes components or modules whose origin, documentation, or security pedigree is unclear – and therefore introduce potential safety, reliability, or cybersecurity risks. This is particularly relevant under new frameworks like the EU Cyber Resilience Act (CRA), which emphasizes transparency and supply-chain security across both hardware and software domains.

At Somco Software, we address this challenge through close collaboration with trusted hardware partners such as Toradex and SoMLabs. These companies provide reliable, well-documented, and where applicable – CRA-ready System-on-Module (SoM) platforms that serve as the foundation for many of our clients’ medical and industrial devices. By combining a controlled hardware base (HBOM) with our rigorous software development and SOUP management processes (SBOM), we help manufacturers maintain end-to-end provenance control from silicon to source code.

 

Conclusion

Software of unknown provenance (SOUP) presents undeniable challenges in developing safe and effective medical devices. But “unknown” doesn’t have to mean “unmanageable.” With a clear understanding of the risks — from technical and cybersecurity issues to regulatory pitfalls — and by applying rigorous controls, manufacturers and software developers can confidently leverage third-party and open-source components while maintaining patient safety and compliance.

SOUP should never be treated as an afterthought. It requires early planning, disciplined engineering, and continuous oversight throughout the product lifecycle. When handled properly, SOUP becomes just another controlled part of the system — one that supports innovation rather than threatens it.

At Somco Software, we’ve seen how structured processes and the right technical expertise turn this challenge into an advantage. With clear provenance tracking, robust validation, and proactive maintenance, third-party software can safely power next-generation medical devices.

Build with control, innovate with confidence — and ensure no software in your product is ever truly “unknown.”

Start your project with confidence — partner with Somco Software.