--- title: Open Source Software in Medical Devices Under MDR description: How open source software medical devices MDR IEC 62304 SOUP rules, SBOM, licensing, and cybersecurity fit together for compliant SaMD. authors: Tibor Zechmeister, Felix Lenhard category: Software as a Medical Device primary_keyword: open source software medical devices MDR IEC 62304 canonical_url: https://zechmeister-solutions.com/en/blog/open-source-software-medical-devices source: zechmeister-solutions.com license: All rights reserved. Content may be cited with attribution and a link to the canonical URL. --- # Open Source Software in Medical Devices Under MDR *By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.* > **Open source software in a medical device is treated as SOUP (software of unknown provenance) under EN 62304:2006+A1:2015. That means clauses 5.3.3, 5.3.4, 7.1.3, and 8.1.2 apply: you must specify its functional and performance requirements, identify potential failure modes, include it in configuration management, and evaluate it for known anomalies. Cybersecurity obligations from MDR Annex I §17.2 and §17.4 and the methods of EN IEC 81001-5-1:2022 apply on top.** **By Tibor Zechmeister and Felix Lenhard.** ## TL;DR - Open source software (OSS) in a medical device is SOUP under EN 62304:2006+A1:2015. There is no separate "open source exemption" in MDR or the standard. - Clauses 5.3.3 and 5.3.4 require functional and performance requirements for each SOUP item and an assessment of hardware and software required by the SOUP. - Clause 7.1.3 requires that potential causes of contributing to hazardous situations from SOUP are identified and evaluated in the risk analysis. - Clause 8.1.2 requires that SOUP items are under configuration management, with version and supplier information controlled throughout the lifecycle. - A software bill of materials (SBOM) is the operational backbone of SOUP and cybersecurity obligations. MDR Annex I §17.2 and §17.4 and EN IEC 81001-5-1:2022 make it de facto mandatory. - License obligations (GPL, LGPL, Apache, MIT, BSD, and copyleft variants) are a legal issue, not a regulatory one, but they shape whether you can use the OSS component at all. - The fact that an OSS component has millions of users does not reduce its SOUP obligations. It can reduce the effort needed to satisfy them, but the records must still exist. ## Why this matters Every modern medical software product contains open source. A Linux kernel, a Python runtime, a React component library, an image processing library, an HTTP client, a database driver — the list runs into hundreds of components for even a simple SaMD. A founder who says "we wrote everything ourselves" is either wrong or shipping something unsafe. The problem is not that OSS is in medical devices. The problem is that startups often treat OSS as outside the regulated perimeter, something that lives in package.json or requirements.txt and does not need documentation. That is the view that gets notified body nonconformities and, worse, leaves real cybersecurity and safety gaps in a field where both matter. Open source is not a loophole and is not a shortcut. It is an engineering choice that must be defended with the same rigour as an in-house component. The good news: EN 62304 and EN IEC 81001-5-1:2022 give you a playbook. The bad news: you have to actually run it. ## What MDR actually says MDR Annex I §17.2 requires that software be developed and manufactured in accordance with the state of the art, taking into account the principles of development lifecycle, risk management including information security, verification and validation. EN 62304:2006+A1:2015 is the harmonised standard for this clause. MDR Annex I §17.4 requires manufacturers to set out minimum requirements concerning hardware, IT network characteristics, and IT security measures, including protection against unauthorised access, necessary to run the software as intended. EN IEC 81001-5-1:2022 is the relevant state-of-the-art standard for the security lifecycle of health software. EN 62304 defines SOUP 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 (also known as off-the-shelf software) or software previously developed for which adequate records of the development processes are not available. Open source software fits this definition exactly in the vast majority of cases. Open source that you have adopted without having participated in its development is SOUP. Full stop. The relevant clauses are: - **5.3.3 Specification of functional and performance requirements for SOUP items.** For each SOUP item, specify the functional and performance requirements that are necessary for its intended use. - **5.3.4 Specification of system hardware and software required by SOUP items.** Specify the system hardware and software required to support the proper operation of the SOUP item. - **7.1.3 SOUP integration risk analysis.** Identify potential causes of contributing to hazardous situations from SOUP, including abnormal operation and failure, and evaluate whether these are controlled. - **8.1.2 SOUP configuration items.** SOUP items must be under configuration management, with title, manufacturer, and unique designator identified and retained. For cybersecurity, EN IEC 81001-5-1:2022 adds expectations on vulnerability management, secure coding, and lifecycle security activities. The SBOM is the operational backbone. MDCG 2019-16 Rev.1 on cybersecurity reinforces these expectations and expects SBOMs in the technical documentation. There is no "open source exemption" in MDR or any harmonised standard. Open source gets the same SOUP treatment as commercial off-the-shelf software. ## A worked example A startup builds a Class IIa image analysis SaMD for dermatology. The software stack includes: - **Ubuntu LTS** (operating system) — OSS, GPL/LGPL, millions of users - **Python runtime** — OSS, PSF licence - **NumPy and SciPy** — OSS, BSD, scientific computing - **OpenCV** — OSS, Apache 2.0, image processing - **A deep learning framework** — OSS, Apache 2.0 - **FastAPI** — OSS, MIT, API layer - **Several internal analysis modules** — written in-house, not SOUP SOUP evaluation: **Inventory.** Each OSS component goes into the SBOM with name, version, supplier (the upstream project), licence, and a link to the upstream repository. The SBOM is generated automatically from the build system and checked into configuration management at every release. **Functional requirements (clause 5.3.3).** For each SOUP component, the team writes a short requirements specification: what function the component provides to the device, the performance envelope it must meet (e.g. image decode latency, numerical precision), and the conditions under which it is exercised. The deep learning framework gets a more detailed specification because it is on the safety-critical path. FastAPI, which serves API endpoints not on the inference path, gets a shorter one. **System requirements (clause 5.3.4).** The team documents the host OS version, CPU architecture, memory, and supporting libraries each SOUP item needs. Version pinning in the build system enforces compliance. **Risk analysis (clause 7.1.3).** The team runs a SOUP-specific FMEA. For each component, they ask: what failure modes could contribute to a hazardous situation? For the deep learning framework, failure modes include silent numerical errors, version-specific regression bugs, and GPU driver incompatibilities. Each gets a mitigation: input validation, pinned versions, regression test suite, hardware qualification. For OpenCV, the failure modes include codec-specific image corruption on edge-case inputs; the mitigation is input validation and format whitelisting. **Anomaly evaluation.** For each component, the team checks published CVE databases and upstream issue trackers for known anomalies that could affect the intended use. Results are logged in the SOUP record. Any open issue that is not mitigated is carried as a residual risk into the risk management file. **Configuration management (clause 8.1.2).** Every SOUP item is pinned to an exact version in the build manifest. Upgrades are handled as design changes with impact analysis. The SBOM is regenerated and compared on every build. **Cybersecurity (MDR Annex I §17.2, §17.4).** The team subscribes to CVE feeds for each SOUP component. A monthly vulnerability review assesses whether any new CVE affects the device. The process follows the lifecycle activities of EN IEC 81001-5-1:2022. **Licensing.** Legal review confirms that Ubuntu LTS GPL/LGPL components are used in ways compatible with the commercial distribution model. The image analysis modules do not statically link GPL code; they run as separate processes, preserving the commercial licensing posture. The total effort for this stack is substantial on day one and modest thereafter. The day-one cost is the price of doing SaMD properly. ## The Subtract to Ship playbook **Step 1. Generate an SBOM from day one.** Not from an audit deadline. From the first build. Use tooling that produces a machine-readable SBOM (CycloneDX or SPDX) on every release. If it is not automated, it will not be current. **Step 2. Treat OSS as SOUP, unconditionally.** Do not argue with your auditor about whether "widely used OSS" needs SOUP records. It does. The effort can be scaled to risk, but the records must exist. **Step 3. Scale the SOUP effort to the safety class of the item.** For Class A or background SOUP, a short record per component is enough. For SOUP on the safety-critical path in Class B or C software, the requirements, risk analysis, and anomaly evaluation need to be substantive. **Step 4. Pin versions. Always.** A SOUP record referencing "latest" is not a record. The version must be pinned in the build manifest and locked in configuration management. **Step 5. Subscribe to vulnerability feeds.** CVE, GitHub advisories, upstream project security announcements. Assign a named owner who reviews them on a fixed cadence. Document the review. **Step 6. Review licences before you write a line of code.** GPL, LGPL, AGPL, MPL, and other copyleft licences have real distribution implications. Get a legal opinion on your chosen stack before you commit. Changing core OSS components late in the lifecycle is expensive. **Step 7. Build an update decision process.** Not every OSS update needs to be applied immediately. Some fix security vulnerabilities that require urgent action. Others are routine. Write the decision tree once and follow it. **Step 8. Connect SOUP to the risk management file.** Every SOUP item with a potential hazardous contribution should be traceable to an entry in the risk management file under EN ISO 14971:2019+A11:2021. If the SOUP FMEA and the device risk analysis live in separate documents that never cite each other, you have a gap. **Step 9. Document the cybersecurity lifecycle separately.** EN IEC 81001-5-1:2022 expects distinct security development activities. Do not fold them into the safety lifecycle as a single process. Keep the records separate and cross-referenced. ## Reality Check 1. Do you have an automatically generated SBOM for your most recent release, and can you produce it in under one minute? 2. Is every OSS component in your product on the SOUP list with functional requirements, version, and supplier? 3. When was the last time you reviewed CVEs affecting your OSS components, and where is that review documented? 4. Are your OSS components version-pinned in the build, or does your build pull "latest" in any place? 5. Have you obtained legal clarity on the licences of every OSS component you distribute? 6. Does your risk management file reference specific SOUP items where they contribute to a hazardous situation? 7. Do you have a documented update decision process for OSS, including security versus non-security updates? 8. Can you demonstrate to an auditor how you satisfy both EN 62304 SOUP clauses and EN IEC 81001-5-1:2022 cybersecurity expectations for the same components, without duplicate effort? ## Frequently Asked Questions **Is open source software banned in medical devices?** No. OSS is widely used and fully acceptable under MDR, provided it is treated as SOUP under EN 62304 and the cybersecurity expectations of MDR Annex I §17.2 and §17.4 are met. **Do I need an SBOM?** In practice, yes. MDR Annex I §17.4, MDCG 2019-16 Rev.1 on cybersecurity, and EN IEC 81001-5-1:2022 all point to component-level transparency that an SBOM satisfies. Notified bodies expect one. **Can I use GPL software in a commercial medical device?** Maybe. It depends on how you use it and distribute it. Static linking of GPL code into proprietary binaries triggers strong copyleft obligations. Running GPL components as separate processes or using LGPL components with dynamic linking is usually manageable. Get a legal opinion. **Does "widely used" OSS like the Linux kernel still count as SOUP?** Yes. EN 62304 defines SOUP by whether you have adequate records of its development, not by its popularity. The Linux kernel is SOUP. So is Python. So is every NPM package in your app. **How do I handle OSS updates after release?** Through your change control and cybersecurity processes. Security-critical updates may trigger an expedited path; non-security updates follow normal impact analysis. Document the decision for each update. **Are test frameworks and build tools also SOUP?** Generally no, because they are tools used during development rather than software items that run on the device in intended use. The line is: if the component executes as part of the delivered product, it is SOUP. If it only runs in your CI pipeline, it is a tool qualification question, not SOUP. ## Related reading - [SOUP and off-the-shelf software under MDR](/blog/soup-ots-software-mdr) — the SOUP concept in depth - [How to evaluate and document SOUP components](/blog/evaluate-document-soup-ots-components) — the practical documentation flow - [MDR software lifecycle under IEC 62304](/blog/mdr-software-lifecycle-iec-62304) — the full lifecycle context for OSS components - [Software safety classification under IEC 62304](/blog/software-safety-classification-iec-62304) — how class A, B, and C drive SOUP effort - [MDR software compliance checklist for startups](/blog/mdr-software-compliance-checklist-startups) — end-to-end verification of SaMD obligations ## Sources 1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §17.2 and §17.4. 2. EN 62304:2006+A1:2015, Medical device software — Software life cycle processes. Clauses 5.3.3, 5.3.4, 7.1.3, 8.1.2. 3. EN IEC 81001-5-1:2022, Health software and health IT systems safety, effectiveness and security — Part 5-1: Security — Activities in the product life cycle. 4. MDCG 2019-16 Rev.1, Guidance on Cybersecurity for medical devices. --- *This post is part of the [Software as a Medical Device](https://zechmeister-solutions.com/en/blog/category/samd) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*