Maps to
IEC 81001-5-1: §9.4
IEC 62443-4-1: §DM-4
Requirement text
Analyse vulnerabilities including: a) assessing impact with respect to technical security context (IEC 62443-4-1), intended environment of use, and defense-in-depth strategy; b) impact per vulnerability scoring (e.g., CVSS); c) identifying all affected product versions; d) identifying root cause; e) identifying related security issues; f) assessing impact on product safety and effectiveness.
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 64 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-112 in December 2022 and references it as providing a framework for the Secure Product Development Framework (SPDF) required by Section 524B.
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.
Atomic constraints
- •Vulnerability analysis SHALL assess impact with respect to the technical security context.
- •Vulnerability analysis SHALL assess impact with respect to the intended environment of use.
- •Vulnerability analysis SHALL assess impact with respect to the defense-in-depth strategy.
- •Vulnerability analysis SHALL include impact scoring using CVSS or equivalent.
- •Vulnerability analysis SHALL identify all affected product versions.
- •Vulnerability analysis SHALL identify the root cause.
- •Vulnerability analysis SHALL identify related security issues.
- •Vulnerability analysis SHALL assess impact on product safety.
- •Vulnerability analysis SHALL assess impact on product effectiveness.
Common gaps
Vulnerability applicability analysis missing
majorWhen CVEs are disclosed for SBOM components, manufacturers do not perform applicability analysis to determine whether the vulnerability is exploitable in their specific product configuration. Either all CVEs are treated as applicable or all are dismissed without analysis.
Evidence signals
- •
FILE_EXISTS
Vulnerability.*Analysis|Security.*Impact.*Assessment|CVSS.*Environmental|Root.*Cause.*Analysis
- •
CONTENT_MATCH
Does this document describe a vulnerability analysis process that includes CVSS scoring, root cause identification, affected version enumeration, and an assessment of impact on product safety and effectiveness in the context of the intended deployment environment?
Audit defense
Our Vulnerability Analysis Procedure (Doc ID: [your document ID]) requires that each confirmed vulnerability in [your product] be analysed against all IEC 81001-5-1 §9.4 criteria, including environmental CVSS scoring, safety impact assessment, and root cause determination. Analysis records are retained in the security file and linked to the Risk Management File.