26 June 2026
Steven Byrne
IEC 81001-5-1:2021 has become the industry standard for demonstrating cybersecurity compliance to EU MDR. Its consideration is essential for developing secure medical device software.
An introduction to IEC 81001-5-1
As healthcare has become more digital, cybersecurity has become essential to medical device development, where the security of devices, patient records, and connected platforms is paramount to patient safety, privacy, and trust.
International regulatory groups have responded with a growing body of guidance: the IMDRF's Principles and Practices for Medical Device Cybersecurity (2020), the FDA's Cybersecurity in Medical Devices premarket guidance, and the EU's MDCG 2019-16, Guidance on Cybersecurity for medical devices. Although this guidance remains relevant, IEC 81001-5-1:2021 is now considered the state-of-the-art international cybersecurity standard for the certification of medical devices under the EU MDR.
IEC 81001-5-1:2021, Health software and health IT systems safety, effectiveness and security, Part 5-1: Security, Activities in the product life cycle was published in December 2021. The standard is process oriented rather than prescriptive: instead of mandating specific technical solutions, such as a particular encryption algorithm or secure coding standards, it defines the activities, tasks, and documentation a manufacturer must embed in its QMS to develop and maintain secure medical device software.
Implementing a secure SDLC
A key strength of IEC 81001-5-1 is that its structure mirrors IEC 62304 so it shows you how to embed security at each phase of an existing IEC 62304-compliant software development lifecycle (SDLC). The aim is security by design: security treated as a design input from the outset, not bolted on at the end. For each SDLC activity, the standard expects specific security considerations:
Software development planning: Your development plan must explicitly address security. This includes nominating secure coding standards appropriate to your languages and platforms, defining how third-party and open-source components will be managed, and defining the security activities and competent resources required across the lifecycle
Requirements: Alongside functional and safety requirements, the device must meet security requirements. These are derived from your threat analysis and intended use, and typically cover authentication and authorisation, data confidentiality and integrity (in transit and at rest), logging and auditability, secure update mechanisms, and resilience.
Architecture and design: Secure design principles must be applied and dcumented, including defence-in-depth, least privilege, secure failure modes, and minimising the attack surface. Particular attention is paid to interfaces and trust boundaries. Every point where the device exchanges data with users, networks, companion apps, cloud services, or third-party components must be analysed and protected. The security architecture should show explicitly how each design choice mitigates an identified threat
Implementation: Code is written in accordance with the secure coding standards defined in the plan, supported by activities such as static analysis and code review. Third-party components are tracked in a software bill of materials (SBOM) to identify and manage known vulnerabilities in dependencies
Verification and validation: Security V&V testing can consist of multiple activities, including automated vulnerability scanning, functional security testing, and penetration testing. The type and depth of security testing should be commensurate with the device's cybersecurity risk level and sufficient to demonstrate that the security risk controls are effectively implemented and that the security requirements have been met
Cybersecurity risk management, a cohesive story
Telling a cohesive cybersecurity risk management story through documentation is essential to demonstrating that your medical device is secure and compliant. The thread that holds it together is traceability. Every cybersecurity risk should connect to the hazardous situations and harms in your risk management file, and be evaluated and controlled through your risk management process.
In practice, the story is built in five connected stages:
Define the product security context and plan the relevant cybersecurity risk management activities in accordance with IEC 81001-5-1 and ISO 14971
Identify threats and vulnerabilities using risk assessment activities appropriate to your device. Threat modelling, vulnerability scanning, and penetration testing are the common techniques; not all are mandatory, and your chosen combination should be informed by the software system's risk and adequate to unearth the relevant threats and vulnerabilities
Threat modelling should be conducted using industry-standard methodologies. For example, STRIDE supported by data-flow diagrams and trust-boundary analysis
Automated vulnerability-scan tools can be used to identify weaknesses in your own code and, just as importantly, in any third-party and open-source components. A managed SBOM makes this an ongoing, automatable activity rather than a one-off check
Penetration testing can uncover vulnerabilities that a scanner would miss and validate that your defined security requirements are genuinely met. This does not have to be outsourced to a third party; it can be performed in-house, provided you can evidence the tester(s)' competence and independence from the software design and development
Evaluate the identified risks against your ISO 14971 risk evaluation criteria, documenting them in a cybersecurity risk assessment matrix and tracing each to the hazardous situations and harms in the risk management file to determine which are unacceptable. Risks can be scored using industry-standard systems such as the Common Vulnerability Scoring System (CVSS)
A caution on scoring: standard CVSS was designed for enterprise IT and does not account for patient safety, so applying it unmodified can produce clinically misleading priorities. Each vulnerability's impact on the device's intended use and patient safety must be analysed
Control the unacceptable risks by implementing and verifying risk controls that mitigate the identified threats and reduce the risk of patient harm as far as possible, collating evidence of both their implementation and effectiveness. This is commonly achieved by tracing to software implementation and security testing artefacts
Conclude by documenting the outcomes, including the acceptability of the residual cybersecurity risk, and ensuring these align with the overall residual risk evaluation and conclusions in the device's risk management report
Maintaining security in production
Security does not end at release. New vulnerabilities are disclosed in third-party components and operating systems long after a device ships, so IEC 81001-5-1 requires a defined plan for post-market cybersecurity monitoring, incident resolution, and vulnerability patching.
In practice, you should:
Continuously monitor your SBOM and threat-intelligence sources for newly disclosed vulnerabilities
Implement logging, auditing, and monitoring to detect and respond to security incidents
Update your cybersecurity risk assessment matrix and risk management file to reflect new vulnerabilities and their impact on intended use and patient safety
Triage and resolve security issues through your software problem-resolution process
Deliver security updates through a secure, verifiable update mechanism
Maintain communication channels with stakeholders to share security issues and updates and to receive incident reports
Under the EU MDR, these activities feed directly into your post-market surveillance system.
Conclusion
In modern digital healthcare, cybersecurity is an essential pillar of medical device development. The EU MDR mandates that any medical device containing software be designed and developed in accordance with the state of the art, and for cybersecurity, IEC 81001-5-1 is now the benchmark. Its strength is that it does not treat security as a separate, after-the-fact exercise: it integrates with IEC 82304-1 and IEC 62304 across the product and software lifecycles, plugs into ISO 14971 for risk management, and demands traceability from threat through to patient harm.
For manufacturers, the practical takeaway is to embed the standard's activities into the processes you already run, rather than maintaining a parallel cybersecurity workstream.