What is IEC 81001-5-1 and who must comply?
IEC 81001-5-1:2021 · First edition · Scope and applicability
The short answer
IEC 81001-5-1:2021 is the international standard for cybersecurity activities in the lifecycle of health software and health IT systems. Any organisation developing, maintaining, or operating health software — including SaMD regulated under EU MDR — must implement the security activities defined in this standard.
Purpose and origin
IEC 81001-5-1 was published in December 2021 by IEC Technical Committee 62 (Electrical equipment in medical practice), Subcommittee 62A. It is Part 5-1 of the IEC 81001 series "Health software and health IT systems safety, effectiveness and security." The standard specifies requirements and recommendations for security activities that shall be performed throughout the software product lifecycle — from concept through development, testing, release, maintenance, and decommissioning.
The standard was developed in response to escalating cybersecurity incidents targeting healthcare infrastructure, and reflects the convergence of safety and security considerations for software-based medical products. It draws heavily on IEC 62443 (industrial automation security), ISO/IEC 27001 (information security management), and IMDRF cybersecurity principles, adapting them to the specific context of health software.
Scope: what software is covered
IEC 81001-5-1 applies to organisations responsible for activities in the lifecycle of health software. The standard uses the IEC 81001 definition of "health software": software intended to be used by or for healthcare professionals, patients, or healthcare organisations for medical purposes. This explicitly includes Software as a Medical Device (SaMD) regulated under EU MDR and IVDR.
| Software type | Covered by IEC 81001-5-1? | Notes |
|---|---|---|
| Software as a Medical Device (SaMD) | Yes | Core target; EU MDR GSPR 17 cybersecurity requirement applies |
| Software in a Medical Device (SiMD) | Yes | Embedded software in hardware devices |
| Clinical decision support software | Yes | If meeting the definition of health software |
| Hospital information systems (HIS/EHR) | Yes | Health IT systems within scope of the standard |
| General-purpose operating systems / infrastructure | No | Infrastructure security addressed by IEC 62443 |
| Non-medical wellness apps | No | No healthcare intended purpose |
Regulatory basis: why IEC 81001-5-1 is mandatory
EU MDR / IVDR — GSPR 17
EU MDR 2017/745 Annex I, General Safety and Performance Requirement 17 explicitly requires that devices incorporating software or that are software shall be designed and manufactured to ensure repeatability, reliability, and performance in line with their intended use — and specifically that devices are protected against unauthorised access. EU MDR GSPR 17.4 states that manufacturers shall establish minimum requirements concerning hardware, IT network characteristics, and IT security measures, including against unauthorised access. EN IEC 81001-5-1 is the principal harmonised standard addressing these requirements for software-based medical devices.
IVDR
EU IVDR 2017/746 contains equivalent cybersecurity requirements in its Annex I GSPRs. Manufacturers of in vitro diagnostic software must demonstrate equivalent cybersecurity provisions.
NIS2 Directive (EU) 2022/2555
The NIS2 Directive, applicable from October 2024, designates healthcare as an "essential entity" sector. Manufacturers and operators of health software may be subject to NIS2 obligations including cybersecurity risk management measures, incident reporting within 24 hours, and supply chain security requirements. IEC 81001-5-1 compliance is a practical foundation for demonstrating NIS2 conformance in the health technology sector.
FDA Cybersecurity Guidance (2023)
The US FDA "Cybersecurity in Medical Devices" final guidance (September 2023) requires premarket submissions to include a Software Bill of Materials (SBOM), a Security Risk Management Report, and a Vulnerability Management Plan. While the FDA does not mandate IEC 81001-5-1, the standard's lifecycle approach aligns closely with FDA expectations and is recognised as an acceptable framework.
Key concepts defined in IEC 81001-5-1
| Term | Definition (IEC 81001-5-1) |
|---|---|
| Security | Property of a system that it does not allow non-authorised access, including accidental or unauthorised access to data and controls |
| Threat | Potential cause of an unwanted incident that may result in harm to a system or organisation |
| Vulnerability | Weakness of an asset or control that can be exploited by one or more threats |
| Security risk | Combination of the probability of a security threat exploiting a vulnerability and the resulting security impact |
| SOUP | Software Of Unknown Provenance — pre-existing software used without access to source code (same as in IEC 62304) |
| Security control | Measure to prevent, detect, or reduce a security risk to an acceptable level |
| TARA | Threat Analysis and Risk Assessment — the security risk identification and evaluation process |
| CVD | Coordinated Vulnerability Disclosure — structured process for receiving and responding to reported vulnerabilities |
Relationship to IEC 62304
IEC 81001-5-1 is designed to complement IEC 62304 (Medical device software lifecycle processes). IEC 62304 governs the functional safety lifecycle of medical device software. IEC 81001-5-1 adds cybersecurity-specific activities — TARA, secure design, security testing, vulnerability management — as parallel tracks within that same lifecycle. Manufacturers implementing IEC 62304 should integrate IEC 81001-5-1 activities at corresponding lifecycle phases to achieve a unified safety and security development process.
IMDRF Cybersecurity Principles
The International Medical Device Regulators Forum (IMDRF) published "Principles and Practices for Medical Device Cybersecurity" (N60) in 2020. IEC 81001-5-1 is closely aligned with IMDRF N60 principles. Both documents agree on: (1) the security of the entire software lifecycle is the manufacturer's responsibility; (2) the total product lifecycle (TPLC) approach is required; (3) transparency about software components (SBOM) is expected; (4) a coordinated vulnerability disclosure process is mandatory.