IEC 62304 software maintenance and change management processes — patch management applies these processes to security updates.
§524B(b)(2)(A) requires a reasonably justified regular patch cycle; IEC 81001-5-1 §6.1.1 five-factor severity assessment; signed update delivery with rollback capability.
Severity-tiered SLA timelines, signed update delivery mechanism, and emergency out-of-cycle patch procedure.
Maps to
FDA Cybersecurity Guidance: §Appendix 1.H Firmware and Software Updates, §VI.B Cybersecurity Management Plans, §VII.C.1 Plans and Procedures (Section 524B(b)(1))
Pre-QMSR Part 820: §820.90 Nonconforming product.
IEC 62304: §6.2 Problem and modification analysis
IEC 81001-5-1: §6 SOFTWARE MAINTENANCE PROCESS
Requirement text
Per §524B(b)(2)(A) and (B) of the FD&C Act, the sponsor of an application or submission described in section 524B(a) of the FD&C Act for a cyber device must make available postmarket updates and patches to the device and related systems to address, on a reasonably justified regular cycle, known unacceptable vulnerabilities and, as soon as possible out of cycle, critical vulnerabilities that could cause uncontrolled risks. FDA's Premarket Cybersecurity Guidance recommends that cybersecurity management plans include the timeline to develop and release patches, update processes, and patching capability (i.e., rate at which update can be delivered to devices), and recommends that manufacturers implement a secure process and mechanism for providing validated software updates and patches for users.
Why this clause exists
A device that cannot be patched after market clearance is a device whose security posture can only degrade over time — every new vulnerability published against its components permanently reduces its defensive capability. Section 524B(b)(2) of the FD&C Act requires the sponsor to "make available postmarket updates and patches to the device and related systems to address ... on a reasonably justified regular cycle, known unacceptable vulnerabilities". IEC 81001-5-1 §6.1.1 says the manufacturer shall establish "a policy that specifies the timeframes for delivering and qualifying SECURITY updates to PRODUCT users", and that "At a minimum, this policy shall consider the following factors": the potential impact of the vulnerability, public knowledge of the vulnerability, whether published exploits exist for it, the volume of deployed products that are affected, and the availability of an effective external control when no health software update is being provided. A moderately scored vulnerability with a published exploit affecting a high-volume deployed fleet can warrant faster response than a higher-scored vulnerability with no known exploit on a device with compensating network isolation. FDA Appendix 1.A recommends requiring authentication before software or firmware updates, and Appendix 1.D recommends allowing installation only of cryptographically authenticated updates. An update mechanism that can itself be compromised — accepting unsigned or tampered update packages — converts the patch channel into an attack vector, inverting its purpose.
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)
- Patch management plans lack procedural detail — Plans state an intent to provide security updates but lack specific procedures: who decides when to patch, what validation is required, how patches are delivered (including secure boot, signed firmware, and rollback capabilities), how customers are notified, and response timelines by severity. For marketed devices where comprehensive design mitigations are not possible, FDA guidance V.A says "compensating controls should be considered."