IEC 81001-5-1:2021, edition 1.0, was published on 16 December 2021. In December 2025, IEC issued Interpretation Sheet 1 and a corrected version that includes it. FDA recognised the standard in full on 19 December 2022 (recognition number 13-122).
IEC 81001-5-1 is the security lifecycle standard most health software manufacturers now cite. This article explains what it covers, how it fits with IEC 62304, and how it is used in the EU and the US.
What the standard covers
According to IEC, the standard "defines the life cycle requirements for development and maintenance of health software needed to support conformance to IEC 62443-4-1", taking the specific needs of health software into account. Its purpose is to increase the cybersecurity of health software, and the security of the lifecycle processes themselves.
Three points from the scope:
it applies to health software, including software in a medical device and software as a medical device;
it excludes the content of accompanying documentation;
the balance between safety, effectiveness and security is discussed in ISO 81001-1.
The full title is "Health software and health IT systems safety, effectiveness and security – Part 5-1: Security – Activities in the product life cycle". It comes from IEC subcommittee SC 62A and has a stability date of 2028.
How it fits with IEC 62304
IEC 81001-5-1 follows the structure of IEC 62304, so its security activities sit alongside the software lifecycle processes most manufacturers already run.
| Clause | Topic |
|---|---|
| 4 | General requirements, including the quality management system and security risk management |
| 5 | Software development, from planning to release, including security testing |
| 6 | Software maintenance, including monitoring for new vulnerabilities |
| 7 | Security risk management |
| 8 | Software configuration management |
| 9 | Software problem resolution, including vulnerability handling |
Source: IEC 81001-5-1:2021.
In our view, the standard is best implemented as an extension of an existing IEC 62304 process, not as a separate security programme. Each clause adds security tasks to a process that already exists, and the evidence belongs in the same records.
Security testing is only one part. Requirements, design, maintenance and problem resolution are what make the test results traceable to identified risks.
Legacy and third-party software
The standard includes an annex for transitional health software: software that already existed before the manufacturer adopted the standard. Interpretation Sheet 1, now included in the corrected version, clarifies how the standard applies to software the manufacturer uses but does not develop itself.
In our view, manufacturers should decide early how each third-party component is treated, because that decision drives what security maintenance is owed after release. Reconstructing it later from contracts and release notes is harder and less convincing.
The EU position
Under Article 8 of the MDR, only harmonised standards whose references are published in the Official Journal give a presumption of conformity. Check the current list under Implementing Decision (EU) 2021/1182 before claiming a presumption for IEC 81001-5-1. The most recent amendment, Implementing Decision (EU) 2026/1231 of 11 June 2026, covers other areas, such as biological evaluation, symbols and medical electrical equipment.
Where no presumption applies, the standard can still show the state of the art. MDR Annex I Section 17.2 requires software to be developed in accordance with the state of the art, taking into account the development life cycle, risk management including information security, and verification and validation. Section 17.4 requires the minimum IT security measures to run the software as intended. Our article on what state of the art means under the MDR explains how to document this.
MDCG 2019-16 Rev.1, the MDCG guidance on cybersecurity, predates the standard. Its Annex III lists, for information only, a document then designated "ISO/IEC 80001-5-1" on product lifecycle security, alongside IEC 62443-4-1.
In our view, cite IEC 81001-5-1 in the technical documentation with a short rationale: why it applies, which edition you use, and how its activities extend your IEC 62304 process. Our article on SaMD technical documentation shows where that belongs.
The US position
In the US, the standard is FDA-recognised in full, so a declaration of conformity can be used in a premarket submission.
FDA's cybersecurity guidance of February 2026 names IEC 81001-5-1 as one example of a medical device-specific secure product development framework. It also lists the standard among those that may partially meet FDA's security testing recommendations. Recognition does not replace the cybersecurity content FDA expects in a submission, including for cyber devices under section 524B.
| EU (MDR) | US (FDA) | |
|---|---|---|
| Status | Check the Official Journal list; otherwise evidence of the state of the art | Recognised in full, number 13-122 |
| Use | Rationale against Annex I Sections 17.2 and 17.4 | Declaration of conformity in a premarket submission |
| Guidance | MDCG 2019-16 Rev.1 predates the standard | FDA cybersecurity guidance (February 2026) names it as an example framework |
Sources: MDR; MDCG 2019-16 Rev.1; FDA.
Our article on AAMI medical standards covers the related US security standards, such as SW96.
A hypothetical example
Hypothetical example: a Dutch company sells a cloud-connected SaMD in the EU and plans a US submission. It already runs an IEC 62304 process.
Gap analysis: it maps its IEC 62304 procedures against Clauses 4 to 9 and adds the missing security tasks.
Third-party software: it records how each library and cloud service is treated, using the corrected version with Interpretation Sheet 1.
Testing: it adds security testing to its verification plan.
Legacy version: an older release built before the company adopted the standard is handled through the annex for transitional health software.
EU file: it cites the standard as state of the art with a rationale against Annex I Sections 17.2 and 17.4.
US file: it includes a declaration of conformity to recognition 13-122, plus the cybersecurity documentation FDA's guidance describes.
Conclusion
IEC 81001-5-1 adds security to the software lifecycle rather than building a separate process. In the US it is recognised in full; in the EU, check the Official Journal before claiming a presumption and otherwise cite it as the state of the art.
In our view, the practical step is simple: extend your IEC 62304 process now, using the corrected version, and review the citation whenever the standard or the harmonised list changes.
If you need help implementing IEC 81001-5-1, our cybersecurity and privacy team can help, or contact MedQAIR.
Frequently asked questions
Is IEC 81001-5-1 harmonised under the MDR?
A presumption of conformity applies only if its reference is published in the Official Journal under Implementing Decision (EU) 2021/1182. Check the current list. Otherwise, cite it as evidence of the state of the art.
Does FDA recognise IEC 81001-5-1?
Yes. FDA recognised edition 1.0 in full on 19 December 2022, under recognition number 13-122.
Do I need IEC 62304 first?
The standard follows the IEC 62304 structure and adds security tasks to those processes. Most manufacturers implement it as an extension of their existing IEC 62304 process.
What changed in December 2025?
IEC issued Interpretation Sheet 1 and a corrected version of the standard that includes it. The edition is still 1.0.
Does IEC 81001-5-1 replace ISO 27001?
No. ISO 27001 covers the organisation's information security management system; IEC 81001-5-1 covers the security of the health software lifecycle. Our article on ISO 27001 requirements covers the ISMS side.
