ISO 13485 §7.4.1 purchasing process — supplier evaluation, selection and monitoring for purchased product; the clause does not mention licenses.
FDA guidance (Appendix 1.H) recommends maintaining the third-party licenses necessary to keep a device updatable throughout its supported lifespan; it does not address copyleft licenses, so copyleft compatibility analysis and an isolation strategy are manufacturer practice, not FDA submission requirements.
Copyleft isolation or linking strategy for GPL/LGPL/AGPL components, fulfilled attribution notices in product documentation, and pre-adoption license review gate — missing compliance strategy for copyleft components is a moderate-severity gap.
Maps to
ISO 13485: §7.4.1 Purchasing process
Pre-QMSR Part 820: §820.50 Purchasing controls.
Requirement text
The manufacturer shall identify, evaluate, and comply with the license terms of all open-source software components used in the medical device software. A license inventory must be maintained, license compatibility must be verified, and attribution requirements must be fulfilled. License obligations that could affect the proprietary status of the device software (e.g., copyleft provisions) must be identified and managed.
Why this clause exists
A copyleft license that requires source disclosure for combined works, applied to software incorporated into a proprietary medical device without a compliance strategy, creates a legal encumbrance that can prevent the manufacturer from lawfully distributing or modifying the device software — including applying emergency security patches. Restrictive copyleft licenses can become a cybersecurity and patient-safety risk because a manufacturer obligated by GPL or AGPL terms it has not fulfilled may face legal exposure that blocks or delays patch deployment, converting a license-compliance gap into a patient safety gap. FDA's cybersecurity guidance does not discuss copyleft licenses; its related recommendation is in Appendix 1.H (Firmware and Software Updates), which lists among the recommendations that can help a manufacturer plan for the rapid testing, evaluation, and patching of devices in the field: 'Maintain necessary third-party licenses throughout the supported lifespan of the device.' The attribution failure mode is more routine but structurally similar: unfulfilled attribution requirements generate downstream legal liability that can interfere with commercial distribution, creating a risk materialized through a routine compliance omission rather than a deliberate security decision. The pre-adoption review gate requirement reflects the principle that license risk is easiest to manage before a component is incorporated — retroactively replacing a dependency that drives copyleft obligations through a widely-integrated transitive chain is significantly more disruptive than evaluating the license at the point of first adoption.
What changed
The FDA's September 2023 final guidance replaced the October 2014 final guidance 'Content of Premarket Submissions for Management of Cybersecurity in Medical Devices'. The guidance is headed 'Contains Nonbinding Recommendations' and states that, in general, FDA guidance documents 'do not establish legally enforceable responsibilities' and should be viewed only as recommendations, unless specific regulatory or statutory requirements are cited; it recommends how to meet the requirements of Section 524B of the FD&C Act (added by FDORA, enacted December 29, 2022), which became effective March 29, 2023. FDA's cybersecurity Refuse to Accept (RTA) policy for cyber devices, issued March 29, 2023, expired on October 1, 2023; from that date FDA expects sponsors of cyber devices to have had sufficient time to prepare premarket submissions that contain the information Section 524B requires (FDA CDRH webinar, November 2, 2023).
Section 524B created new statutory requirements for 'cyber devices' — any device that includes software validated, installed, or authorized by the sponsor as a device or in a device, has the ability to connect to the internet, and contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats. Under Section 524B(b), the sponsor must (1) submit a plan to monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure and related procedures; (2) design, develop, and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure, and make available postmarket updates and patches on a reasonably justified regular cycle for known unacceptable vulnerabilities and as soon as possible out of cycle for critical vulnerabilities that could cause uncontrolled risks; (3) 'provide to the Secretary a software bill of materials, including commercial, open-source, and off-the-shelf software components'; and (4) comply with such other requirements as the Secretary may require through regulation to demonstrate reasonable assurance that the device and related systems are cybersecure.
The statute says nothing about SBOM format, depth or end-of-support dates. Those come from the guidance (Section V.A.4), which recommends that manufacturers provide machine-readable SBOMs consistent with the NTIA minimum elements and, for each software component, the 'software level of support' and the end-of-support date, and says 'Industry-accepted formats of SBOMs are encouraged.' The guidance names no format; SPDX and CycloneDX are formats used in practice, not named by the statute or by the guidance. The guidance describes a robust SBOM as including 'the upstream software dependencies' of proprietary, purchased/licensed, and open-source software (V.A.4(a)), and recommends that an SBOM or an equivalent capability be maintained as part of configuration management and regularly updated to reflect changes to the software in marketed devices. Section V.C lists 'Software composition analysis of binary executable files' among the testing and analyses for which it recommends providing details and evidence.
Common gaps (what we see in audits)
- License compliance unmanaged for medical device software — Open source components are used without tracking license obligations. Copyleft licenses (GPL, LGPL, AGPL) are included without compliance strategies. Restrictive licenses can become a security risk if they prevent the manufacturer from modifying or patching code in an emergency; FDA guidance Appendix 1.H recommends maintaining necessary third-party licenses throughout the supported lifespan of the device. Attribution requirements are not fulfilled.