IEC 62304 §6 software maintenance and IEC 62443-4-1 defect management processes covering software corrections and updates.
Risk-tiered security update policy with defined delivery and qualification timeframes, factoring exploit availability, public disclosure, deployment volume, and compensating control availability.
Security Update Policy with severity-based timelines documented — vague commitments to ‘timely’ updates without defined SLAs do not satisfy clause 6.1.1.
Maps to
IEC 81001-5-1: §6.1.1 Timely delivery of SECURITY updates
IEC 62443-4-1: §DM-3
Requirement text
Establish a policy specifying timeframes for delivering and qualifying security updates, considering: a) potential impact on technical performance, safety, effectiveness, and security; b) public knowledge of the vulnerability; c) whether published exploits exist; d) volume of deployed products affected; e) availability of effective external controls.
Why this clause exists
Post-market security update timeliness is where regulatory cybersecurity requirements have the most direct patient safety consequence: a manufacturer that discovers a critical vulnerability in a deployed medical device and takes eighteen months to release a patch has left patients and operators exposed for eighteen months, without any mechanism to force timely remediation. IEC 81001-5-1:2021 clause 6.1.1 requires a documented policy establishing the timeframes within which security updates will be provided, creating both an internal planning target and an external commitment that regulators and operators can hold manufacturers to. The timeliness requirement is specifically about policy establishment — without a defined target, every update timeline becomes a negotiation, and delays are justified on development resource grounds rather than evaluated against a security risk standard. WannaCry's 2017 impact on NHS hospital systems — where unpatched vulnerabilities caused widespread device and system unavailability — demonstrated the patient safety consequence of delayed security update programs for healthcare infrastructure. FDA's postmarket cybersecurity guidance echoes this structure, expecting manufacturers to have defined patch timelines and to report on cases where critical patches cannot be delivered within those timelines.
What changed
IEC 81001-5-1:2021 is the first standalone cybersecurity standard purpose-built for health software and medical device software. Published in December 2021, it was adapted from IEC 62443-4-1 (industrial control systems security) to address the unique safety and regulatory context of medical devices — adding health-specific requirements that account for patient safety, clinical workflows, and the manufacturer-HDO relationship.
The standard mirrors IEC 62304's lifecycle structure but adds security-specific activities at every phase — planning, development, testing, release, and maintenance. It requires security risk management to be integrated with ISO 14971 safety risk management, not treated as a separate IT concern. FDA formally recognized it as Consensus Standard 13-122 on December 19, 2022 and references it as providing one acceptable framework for satisfying the cybersecurity requirements of Section 524B(b)(2), which requires manufacturers to design, develop, and maintain processes and procedures to provide a reasonable assurance that cyber devices and related systems are cybersecure.
EU MDR harmonization was originally targeted for May 2024 but postponed to May 2028. Despite this delay, Notified Bodies and Competent Authorities universally recognize it as "state of the art" for health software cybersecurity under MDR GSPR Annex I, Section 17.2. Missing or inadequate cybersecurity documentation is already a top cause of Notified Body major non-conformities for SaMD. A December 2025 Interpretation Sheet (ISH1:2025) clarified software item classification into maintained, supported, and required software categories, affecting risk transfer and post-market obligations.
Common gaps (what we see in audits)
- No defined timeline for security patch delivery — Manufacturers commit to 'providing security updates' without defining severity-based timelines (e.g., critical within 30 days, high within 60 days). Without defined SLAs there is no accountability for timely patch delivery.