Regulators now expect medical device and health software makers to show a secure development lifecycle, and IEC 81001-5-1 is the standard most often used to prove one. It adapts the IEC 62443-4-1 product lifecycle to health software and fits it into the process structure that manufacturers already run for IEC 62304 software safety and ISO 14971 risk management. This guide explains what the standard requires, how it differs from 62443-4-1, what evidence a notified body or FDA reviewer will expect, how to handle legacy products, and where the standard sits in the EU and US regimes. It is for product security leads, software quality and regulatory affairs teams at manufacturers of medical devices, software as a medical device and other health software. For the wider medical device picture, including hospital-side controls, see the Medical Device Security Guide.
Key takeaways
- It is the health software version of 62443-4-1. ISO's abstract says the standard supports conformance to IEC 62443-4-1 while adapting that framework to health software.
- It plugs into existing medical device processes. Its clauses follow the shape of IEC 62304, so security activities can be added to the same plans, reviews and records rather than run as a separate programme.
- Security risk is managed separately from safety risk, but linked. Threats are assessed on exploitability, and any security risk that can lead to harm is passed into the ISO 14971 safety risk file.
- Legacy software has its own route. The standard includes provisions for transitional health software that was developed before the standard was applied.
- Revision is under way. ISO shows the 2021 edition at stage 90.92 "to be revised" since 19 September 2025, so watch for a new edition before locking long-term procedures.
What it is and who it applies to
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", is Edition 1, published on 21 December 2021 and developed with ISO/TC 215 (Health informatics). The ISO abstract states that it defines the life cycle requirements for development and maintenance of health software, aims to improve both the cybersecurity of health software and the security of the life cycle processes, and stresses balancing safety, effectiveness and security in line with ISO 81001-1. It does not specify the contents of accompanying documentation. Europe adopted it as EN IEC 81001-5-1.
| Who | Applies? | Notes |
|---|---|---|
| Manufacturer of a medical device containing software | Yes, for the software | Hardware security is outside its scope; combine with device-level requirements |
| Manufacturer of software as a medical device (SaMD) | Yes | Covers cloud components the manufacturer develops and maintains |
| Maker of health software that is not a medical device (for example an EHR module) | Yes, voluntarily | "Health software" is wider than "medical device software" |
| Hospital or health delivery organisation | No | Use it to ask suppliers for evidence; operational controls sit elsewhere (IEC 80001-1, 62443-2-1) |
| System integrator | Only for software it develops | Integration responsibilities are not its focus |
81001-5-1 versus 62443-4-1: both define a secure development lifecycle. Choose 81001-5-1 when the product is health software and you already run IEC 62304, because the evidence lines up with your design history file. Choose 62443-4-1 when the product is an industrial component or when buyers ask for ISASecure certification. Manufacturers serving both markets can run one lifecycle and map it to both; see the IEC 62443-4-1 and 4-2 Secure Product Development Guide.
Structure and key requirements
The standard mirrors the process groups of IEC 62304, adding security activities to each:
| Process area | Key security requirements | Typical records |
|---|---|---|
| General requirements | Security within the quality management system; defined roles and security competence; secure development environment; identification and management of third-party components | Security plan, training records, tool and environment controls, component inventory |
| Development: planning and requirements | Security planning; security requirements derived from intended use, environment and threats, including requirements for the intended operating environment | Security requirements specification, threat model |
| Development: architecture and design | Defence in depth; secure design principles; design reviews against the threat model; documented trust boundaries and external interfaces | Architecture with security views, design review minutes |
| Development: implementation and verification | Secure coding standards; static analysis; review of implementation against security requirements | Coding standard, static analysis results, review records |
| Development: security testing and release | Testing of security requirements, threat mitigation testing, vulnerability testing and penetration testing with appropriate independence; release only with known residual risks accepted | Test reports, residual risk acceptance, release record |
| Maintenance | Monitoring for vulnerabilities in the product and its components; timely security updates; communication with customers | Vulnerability monitoring logs, update records, advisories |
| Security risk management | Threat and vulnerability based risk assessment, controls, residual risk evaluation, link to safety risk management | Security risk file linked to the ISO 14971 file |
| Configuration management and problem resolution | Controlled builds and versions; security issues handled through problem resolution, including reports from outside parties | Configuration records, issue tracker, disclosure handling records |
Transitional health software. Products already on the market cannot be redeveloped from scratch. The standard allows manufacturers to bring such software into the lifecycle with a documented gap assessment, a security risk assessment of the existing design, and full application of the maintenance and problem resolution processes from then on. This is the realistic route for most legacy portfolios.
Security versus safety risk. Safety risk under ISO 14971 relies on probability of occurrence. Security risk depends on an adversary, so it is estimated on exploitability and impact. The two files must be linked: a security risk that can cause harm (a modified infusion rate, an altered image) becomes a hazardous situation in the safety file, and a security control that could delay care (lockout, forced reboot for patching) becomes a safety hazard in its own right.
Identity and NHI requirements
Health software is full of non-human identities: device certificates, service accounts for interfaces to EHRs and PACS, API keys for cloud backends, and maintenance accounts used by field engineers. The standard does not prescribe specific authentication mechanisms, but its requirements bring these into scope through the threat model and security requirements.
- Security requirements for authentication: specify how each interface authenticates users, devices and services, including emergency access that does not block clinicians.
- No hidden maintenance credentials: service and field engineer accounts must be documented, changeable by the operator and logged. A shared hard-coded service password across a product line is a design defect to be fixed, not a residual risk to accept.
- Secrets in the development environment: protect code signing keys, cloud deployment credentials and test accounts used in CI. See the Code Signing Security Guide.
- Interfaces to hospital systems: HL7, FHIR and DICOM integrations use service identities; document their privileges and how operators rotate them. See the DICOM and PACS Security Guide.
- Customer guidance: tell operators which accounts and certificates exist and how to manage them.
Implementation steps
- Gap assess against the QMS (month 1 to 2): for each process area, record whether your IEC 62304 and ISO 14971 procedures already cover it, partly cover it, or not at all.
- Write security into existing procedures: add security planning to the software development plan, a security requirements section to the requirements template, and threat model review to design review checklists. Avoid a parallel "security manual" that nobody follows.
- Define the security risk method: exploitability scoring, impact scale and the rule for passing risks into the safety file. Pilot it on one product.
- Build the component inventory: list third-party and open source components per release, which also gives you the SBOM regulators ask for. See the SBOM Guide.
- Stand up testing: static analysis in the build, vulnerability scanning, fuzzing of network interfaces and an independent penetration test before major releases.
- Set up maintenance and disclosure: vulnerability monitoring, an intake channel and a PSIRT process with defined response times. See the PSIRT Guide.
- Bring legacy products in: run the transitional route for each marketed product, prioritised by connectivity and clinical impact.
- Internal audit, then external review: audit the new procedures on one release before a notified body or FDA submission relies on them. If a procedure proves unworkable, change it through document control rather than letting teams deviate silently.
Small versus large manufacturers: a start-up building a single SaMD can implement the standard with a few procedure updates and a lean security role, provided testing independence is real (for example an external penetration test). A large manufacturer with many product lines should create one corporate procedure set and require product teams to tailor it, with a central PSIRT.
Evidence and assessment
There is no single certification scheme for 81001-5-1. Evidence is assessed as part of regulatory review and QMS audits, and buyers increasingly ask for it in tenders.
| Reviewer | What they typically look for |
|---|---|
| EU notified body (MDR or IVDR) | Procedures and records showing the state of the art for information security under Annex I, typically by reference to EN IEC 81001-5-1; security risk file linked to safety risk; post-market vulnerability handling |
| US FDA (premarket) | Secure product development framework evidence, threat model, risk assessment, SBOM and postmarket plan for cyber devices under section 524B. FDA's premarket cybersecurity guidance was reissued with content current as of 3 February 2026 under the title "Quality Management System Considerations" |
| Hospital procurement | Statement of conformance, SBOM, supported versions, patch timelines, disclosure policy and security documentation for operators |
| Internal audit | Traceability from threats to requirements to tests; residual risk acceptance by authorised roles |
EU harmonisation status, checked 27 October 2026: the Commission's MDR harmonised standards list is built from Implementing Decision (EU) 2021/1182 and its amendments, the latest dated 11 June 2026. The Commission web pages we read do not list individual standards, so confirm in the latest consolidated list or the Official Journal whether EN IEC 81001-5-1 is cited, and with which edition, before claiming a presumption of conformity. Using it to demonstrate the state of the art does not depend on harmonisation; only the legal presumption of conformity does.
Measures that show the lifecycle works:
- Percentage of releases with a reviewed threat model and complete security test evidence.
- Median days from vulnerability disclosure to released fix, by severity.
- Percentage of marketed products through the transitional health software route.
- Count of known exploitable vulnerabilities in third-party components at release (target zero, or each formally accepted).
- Percentage of security risks with a documented safety impact decision.
Mapping to other frameworks
| 81001-5-1 area | IEC 62443-4-1 practice | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|---|
| General requirements and environment | Security management | SA-3, SA-15 | PR.PS-06 |
| Third-party components | Security management | SR-3 | GV.SC-05 |
| Requirements and threat model | Specification of security requirements | SA-8, RA-3 | ID.RA-05 |
| Design and implementation | Secure by design; secure implementation | SA-8, SA-15 | PR.PS-06 |
| Security testing | Security verification and validation testing | SA-11, RA-5 | ID.RA-01 |
| Problem resolution and disclosure | Management of security-related issues | RA-5 | ID.RA-08 |
| Maintenance and updates | Security update management | SI-2, CM-3 | ID.IM-02 |
| Authentication requirements | Specification of security requirements | IA-2, IA-5 | PR.PS-06 |
For US software assurance, the same activities map closely to the NIST Secure Software Development Framework (SSDF, SP 800-218) Guide. EU regulatory detail, including MDCG 2019-16, is in the EU MDR Cybersecurity and MDCG 2019-16 Guide; US detail in the FDA Medical Device Cybersecurity Guide.
Common pitfalls
- A separate security process: running security outside the QMS creates two sets of records that disagree, which auditors find quickly.
- Probability scoring for threats: estimating attack likelihood the way you estimate component failure understates risk for connected devices.
- Safety and security files not linked: a security control that delays therapy, or a threat that alters dosing, missing from the ISO 14971 file.
- Legacy products ignored: applying the standard only to new projects while most fielded units run older software with no maintenance process.
- Penetration testing as the whole programme: one test before submission without threat modelling, coding standards or vulnerability monitoring does not meet the lifecycle requirements.
- Undocumented service accounts: field engineer and integration credentials missing from the threat model and from operator documentation.
Practitioner checklist
- Gap assess IEC 62304 and ISO 14971 procedures against each 81001-5-1 process area.
- Add security planning, requirements and threat model review to existing templates.
- Define an exploitability-based security risk method and its link to the safety risk file.
- Maintain a third-party component inventory and SBOM for every release.
- Run static analysis, vulnerability testing, fuzzing and independent penetration testing.
- Document every user, service and maintenance account and how operators manage it.
- Operate vulnerability monitoring, disclosure intake and timed security updates.
- Bring each marketed product through the transitional health software route.
- Check the EU harmonised standards list and the IEC revision status at each annual review.
Standards and references
- ISO: IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security, Part 5-1
- IEC: IEC 62443-4-1 Secure product development lifecycle requirements
- US FDA: Cybersecurity in Medical Devices, Quality Management System Considerations and Content of Premarket Submissions
- European Commission: Medical devices harmonised standards
- European Commission: Harmonised standards for medical devices (Single Market)
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Medical Device Security Guide · FDA Medical Device Cybersecurity Guide · EU MDR Cybersecurity and MDCG 2019-16 Guide · Secure Software Development Lifecycle (SSDLC) Guide. This guide summarises IEC 81001-5-1 and related regulatory expectations and is not legal advice.