Maps to
QMSR / ISO 13485: §820.90
IEC 62304: §6.2
IEC 81001-5-1: §6
FDA Cybersecurity Guidance: §Appendix 1.H, VI.B, VII.D
Requirement text
The manufacturer shall establish a plan for delivering security patches and updates throughout the product's supported lifecycle. The plan must define how patches are developed, validated, and delivered to end users, including timelines for addressing vulnerabilities by severity level and mechanisms for authenticated and verified update delivery.
What changed
The FDA's September 2023 final guidance replaced the October 2014 draft and represented a fundamental shift from voluntary best practices to mandatory, enforceable requirements backed by Section 524B of the FD&C Act (PATCH Act, effective October 1, 2023).
Section 524B created new statutory requirements for 'cyber devices' — any device that includes software, connects to the internet (directly or indirectly), or could be vulnerable to cybersecurity threats. Manufacturers must submit: a plan for postmarket vulnerability monitoring and patching, evidence of secure development processes (SPDF), and a machine-readable SBOM in SPDX or CycloneDX format including transitive dependencies and end-of-support dates.
FDA can now refuse to accept (RTA) premarket submissions lacking adequate cybersecurity documentation. Since October 2023, there has been a 700% increase in cybersecurity-related deficiency letters, with an average of 15 deficiencies per letter when cybersecurity is cited. Threat modeling deficiencies appear in a majority of these letters. The SBOM requirement goes significantly beyond the 2014 guidance — binary analysis is expected to find hidden components, and SBOMs must be continuously maintained, not static snapshots.
Atomic constraints
- •A documented patch and update management plan must exist with defined processes for the full patch lifecycle.
- •Patch response timelines must be defined by vulnerability severity (e.g., critical within 30 days, high within 60 days).
- •The plan must define how patches are validated (regression testing, security verification) before deployment.
- •Update delivery mechanisms must be defined (OTA, manual, field service) with integrity verification (signed updates).
- •The plan must address out-of-cycle emergency patches for critical vulnerabilities.
- •Customer communication procedures for security updates must be documented.
Common gaps
Patch management plans lack procedural detail
majorPlans 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. FDA expects 30-day notification and 60-day remediation for critical risks. If a device cannot be patched, compensating control guidance for users is required.
Evidence signals
- •
FILE_EXISTS
Patch.*Management|Update.*Management|Security.*Update|Patch.*Plan|Software.*Maintenance
- •
CONTENT_MATCH
Does this document define a patch and update management plan with severity-based response timelines, patch validation procedures, update delivery mechanisms with integrity verification, and customer notification processes for security updates?
Audit defense
The Patch and Update Management Plan for [your product] (Doc ID: [your document ID]) defines our security update lifecycle per FDA Premarket Cybersecurity Guidance, with severity-based SLAs, validation requirements, signed update delivery, and customer notification procedures.