IEC 81001-5-1 is the security lifecycle standard for health software. It defines the security activities a manufacturer must perform across the life cycle, from secure development and verification to release and maintenance, to reduce cybersecurity risk in medical devices and health IT systems. It complements the safety-focused software lifecycle in IEC 62304. Together, these standards help manufacturers address both safety and security throughout the development process.
What is IEC 81001-5-1?
IEC 81001-5-1, titled “Health software and health IT systems safety, effectiveness and security, Part 5-1: Security, Activities in the product life cycle,” was published in 2021. It sets out the cybersecurity processes that manufacturers apply when building and supporting software that runs in or on a medical device.
The standard sits alongside IEC 62304, which governs the software development lifecycle for medical device software but does not cover security in depth. Where IEC 62304 asks whether the software is built and maintained safely, IEC 81001-5-1 asks whether it is built and maintained securely. It draws heavily on IEC 62443-4-1, the secure development standard from industrial automation, and reframes those activities for health software and Software as a Medical Device (SaMD). This connection helps show how security activities fit into an existing lifecycle.
Why IEC 81001-5-1 Matters in Medical Device Development
Connected devices fail in ways that hurt patients. A compromised infusion pump, patient monitor, or diagnostic platform can leak data, stop working, or behave unpredictably. IEC 81001-5-1 provides manufacturers with a recognized way to demonstrate that their software was designed to resist such failures.
Regulators now expect it. In the EU, cybersecurity is treated as part of the general safety and performance requirements under EU MDR 2017/745, and guidance such as MDCG 2019-16 points to secure-by-design lifecycle practices. The U.S. FDA has recognized IEC 81001-5-1 as a consensus standard, so conformance supports premarket submissions, including 510(k) and PMA filings.
Skipping it costs time. Auditors and notified bodies ask for evidence of a secure development lifecycle, so teams without one face deficiency letters, delayed approvals, and expensive rework late in the program when changes are hardest to make.
How IEC 81001-5-1 Works
The standard organizes security work into activities mapped to the product life cycle. A manufacturer establishes a documented process and produces evidence at each stage. Core activities include:
- Security risk management, run in tandem with safety risk management under ISO 14971, identifies threats, vulnerabilities, and their impact.
- Security requirements that define what the software must do to protect confidentiality, integrity, and availability.
- Secure architecture and design, including defense-in-depth, threat modeling, and a documented security architecture.
- Secure implementation and coding practices, with controls against known classes of weaknesses.
- Security verification and validation, covering vulnerability testing, penetration testing, and review of third-party and open-source components (the software bill of materials, or SBOM).
- Secure release, including configuration, default settings, and security documentation for users and integrators.
- Post-release activities: vulnerability monitoring, coordinated disclosure, patch and update management, and secure decommissioning.
Each activity ties back to records the manufacturer keeps in the design history file and technical documentation. The standard expects traceability from security requirements through to verification evidence, similar to how IEC 62304 traces software requirements. It applies whether the software is embedded in hardware, runs as SaMD, or operates as part of a wider health IT system. This traceability helps connect development work to evidence of compliance.
Common Challenges and Best Practices
Teams often bolt security on at the end. By then, the architecture is fixed, and fixes are costly. Build threat modeling into early design instead.
A second mistake is treating safety risk and security risk as separate files that never meet. ISO 14971 risk management and IEC 81001-5-1 security risk management should inform each other, because a security flaw can become a safety hazard.
Open-source dependencies cause repeated trouble. Maintain an SBOM, track vulnerabilities in your components, and have a plan to patch them after release, because unpatched libraries can continue to generate post-market surveillance findings.
Good practice looks like a documented, secure development lifecycle that an auditor can follow end-to-end, security gates within your existing phase-gate process, and a vulnerability-handling procedure that is live rather than theoretical. Align the work with IEC 62304 and IEC 62366-1 so that evidence of security, software, and usability reinforce one another rather than duplicate.
How SJML Helps with IEC 81001-5-1
SJML supports software and connected-device programs that require an IEC 81001-5-1-aligned security lifecycle. Its engineering teams cover embedded systems and device software, with risk management aligned with ISO 14971 and usability engineering aligned with IEC 62366 built into the design process. On the compliance side, SJML offers SaMD support spanning the IEC 62304 software lifecycle and IEC 81001-5-1 cybersecurity risk assessment, as well as regulatory strategy and technical documentation for FDA and EU MDR pathways. This pairs secure development work with the QARA evidence that submissions require.
Talk to SJML’s QARA team →
Frequently Asked Questions
IEC 81001-5-1 is not a law by itself, but regulators treat it as the state of the art for health software security. The FDA recognizes it as a consensus standard, and EU notified bodies expect evidence of secure development under the EU MDR 2017/745. In practice, conforming to it is the most direct way to satisfy cybersecurity expectations during premarket review and audits.
IEC 62304 governs the medical device software lifecycle from a safety and quality angle: planning, requirements, architecture, integration, and maintenance. IEC 81001-5-1 covers security activities throughout the lifecycle, such as threat modeling, security testing, SBOM management, and vulnerability management. They are complementary. Most software teams apply both, mapping security activities onto their existing IEC 62304 process.
Yes. IEC 81001-5-1 applies to health software whether it is embedded in a device or runs as Software as a Medical Device (SaMD). It also covers software in wider health IT systems. Any team building connected or networked medical software should treat it as the reference for a secure product development lifecycle.
A software bill of materials (SBOM) is an inventory of every component in your software, including open-source and third-party code. IEC 81001-5-1 requires manufacturers to track these components so that known vulnerabilities can be identified and patched. Regulators, including the FDA, increasingly ask for an SBOM as part of premarket cybersecurity documentation.
Related Terms
- IEC 62304
- ISO 14971
- IEC 62366-1
- Software as a Medical Device (SaMD)
- Medical Device Cybersecurity
