ISO 14971 §5.4 hazard identification and IEC 62304 §7.1.3 SOUP anomaly evaluation — SOUP risk assessment applies the existing safety risk process to third-party component known anomalies.
IEC 62304 §7.1.3 requires, for Class B and C software where failure or unexpected results from SOUP is a potential cause of the software item contributing to a hazardous situation, evaluating as a minimum any anomaly list published by the supplier of the SOUP item for the version used.
Version-specific anomaly review for safety-critical SOUP, ISO 14971 file integration, and vendor support adequacy — generic rationale without anomaly review fails IEC 62304.
Maps to
Pre-QMSR Part 820: §820.30(g) Design validation.
ISO 14971: §5.4 Identification of hazards and hazardous situations
IEC 62304: §7.1.3 Evaluate published soup anomaly lists
Requirement text
If failure or unexpected results from SOUP is a potential cause of the software item contributing to a hazardous situation, the manufacturer shall evaluate, as a minimum, any anomaly list published by the supplier of the SOUP item relevant to the version of the SOUP item used in the medical device, to determine if any of the known anomalies result in a sequence of events that could result in a hazardous situation (software safety classes B and C).
Why this clause exists
Selecting a SOUP item based on reputation, community size, or general reliability is not the same as evaluating whether the specific version in use, with its specific known defects, introduces an unacceptable risk in the specific safety context where it is deployed. IEC 62304 section 7.1.3 establishes the anomaly-review obligation (for Class B and C software, where failure or unexpected results from SOUP is a potential cause of a hazardous situation) because safety-critical functions implemented through SOUP carry the risk of the SOUP item's own known failure modes into the device's safety profile — a bug in a cryptographic library fulfilling authentication requirements for access-controlled device functions is a different risk category than the same bug in a UI formatting utility. The vendor support adequacy evaluation exists to surface a frequently overlooked risk: an abandoned or community-maintained SOUP item with no active maintainer will not receive security patches for newly discovered vulnerabilities, converting it into a permanently accumulating risk source. This failure mode — a device's safety-critical function depending on an unmaintained library accumulating unaddressed CVEs — was observable in pre-2023 device field populations and is directly addressed by the requirement to evaluate support adequacy as a risk factor at the time of SOUP selection and at each review cycle.
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)
- SOUP risk assessment ignores known anomalies for specific versions — Risk assessments evaluate general risk ('is this a reputable library?') rather than reviewing specific known anomalies — published bugs, CVE entries, errata, and security advisories for the exact version in use. Safety-critical SOUP does not receive enhanced scrutiny.