IEC 81001-5-1: security activities in the health software product life cycle, explained

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 the standard that tells a health software manufacturer what security work has to happen at each stage of development and maintenance — planning, design, implementation, testing, release, and the vulnerability handling that follows. Published in December 2021 as a joint IEC/ISO double-logo standard, it layers security activities onto the same life cycle structure IEC 62304 already uses for safety, and is explicitly written to help a manufacturer support conformance with IEC 62443-4-1, the industrial secure-development-lifecycle standard, adapted for health software's specific needs.

Who wrote it, and for what

Per its own Foreword, IEC 81001-5-1 "has been prepared by a Joint Working Group of IEC subcommittee 62A: Common aspects of electrical equipment used in medical practice, of IEC technical committee 62: Electrical equipment in medical practice, and ISO technical committee 215: Health informatics. It is published as a double logo standard." Its Clause 1 (Scope) states its purpose directly: "to increase the cybersecurity of health software by establishing certain activities and tasks in the health software life cycle processes and also by increasing the security of software life cycle processes themselves," while maintaining "an appropriate balance of the key properties safety, effectiveness and security as discussed in ISO 81001-1." Notably, Clause 2 (Normative references) is empty — "there are no normative references in this document" — meaning the standard is self-contained even though its own terms clause sources definitions from ISO/IEC 27000, IEC 62443-4-1, IEC 62304, ISO 81001-1 and several other documents.

What counts as "health software" here

Per Clause 0.2 (Field of application), the standard applies to:

• software as part of a medical device;
• software as part of hardware specifically intended for health use;
• software as a medical device (SaMD); and
• software-only products for other health use.

A medical device's own software is therefore only one subset of what this standard calls "health software" — the scope is deliberately wider than "medical device software" alone, and its Introduction notes the standard's field of application also looks ahead to future ISO/IEC 81001-5 parts covering the implementation, operations and use phases at healthcare delivery organizations.

The six process clauses

Clause	Process	What it covers
4	General requirements	Quality management, security risk management context, and software-item classification relating to risk transfer — the foundation the rest of the document assumes
5	Software development process	Development planning, requirements analysis, architectural and detailed design, unit implementation and verification, integration and system testing (including security requirements testing, threat mitigation testing, vulnerability testing and penetration testing), and release
6	Software maintenance process	Establishing a maintenance plan, timely delivery of security updates, problem/modification analysis (including monitoring public incident reports), and modification implementation
7	Security risk management process	Risk management context, identifying vulnerabilities/threats and adverse impacts, estimating and evaluating security risk, controlling it, and monitoring control effectiveness
8	Software configuration management process	(Title only in the table of contents of the publicly available preview; detailed sub-clauses sit in the paywalled text)
9	Software problem resolution process	Receiving, reviewing and analysing vulnerability notifications, and addressing security-related issues

Per the Introduction, Clauses 5 through 8 "are arranged in the ordering of IEC 62304" specifically so that a manufacturer already running an IEC 62304-conformant life cycle can extend it with these clauses rather than build a second, parallel process.

Built to support, not replace, IEC 62443-4-1

Clause 0.3 (Conformance) is explicit about the relationship: "This document is designed to assist in the implementation of the processes required by IEC 62443-4-1, however, conformance to this document is not necessarily a sufficient condition for conformance to IEC 62443-4-1." Annex D ("Relation to practices in IEC 62443-4-1:2018") gives an informative, bidirectional mapping between the two documents' structures, and Annex E ("Documents specified in IEC 62443-4-1") lets a manufacturer produce documentation aligned to 62443-4-1's own expected deliverables. The exact clause-to-practice correspondence inside those annexes sits in the paywalled text; treat specific mappings as to be confirmed against the purchased standard rather than assumed from this summary. See IEC 62443-4-1: the secure product development lifecycle, explained for that standard's own eight practices.

Two ways to conform: full life cycle, or "Transitional Health Software"

Per Clause 0.3, a manufacturer can claim conformance in one of two ways:

1. For health software generally — implement the requirements in Clauses 4 through 9 in full.
2. For Transitional Health Software — implement only the processes, activities and tasks identified in the normative Annex F.

Annex F exists because software already on the market cannot realistically be run back through a from-scratch secure development life cycle; it defines a narrower, documented gap-closure path (development assessment and gap-closure activities, rationale for use, and post-release activities) instead. Annex A also introduces a related concept, risk transfer, distinguishing between maintained, supported and required software — software items an organization still actively develops versus software it only supports or merely requires, each carrying a different practical security obligation.

Threat modelling techniques the standard points to

Annex C (informative, "Threat modelling") lists specific techniques a manufacturer can draw on, without mandating any single one: attack-defense trees, CAPEC/OWASP/SANS-based approaches, CWSS, DREAD, listing known potential vulnerabilities, OCTAVE, STRIDE, Trike, and VAST. This is guidance, not a requirement to use a named methodology — Clause 5's security requirements and threat-mitigation testing activities are the actual normative obligation.

Recognition and adoption

FDA added IEC 81001-5-1 to its Recognized Consensus Standards database on 19 December 2022, under recognition number 13-122, category Software/Informatics, with extent of recognition listed as "Complete." Independent secondary analysis (not independently verified against FDA's guidance PDF for this guide) describes FDA's evolving premarket cybersecurity guidance — most recently reissued in February 2026 under docket FDA-2021-D-1158 — as naming IEC 81001-5-1 among example Secure Product Development Frameworks a cyber device submission can point to; see FDA premarket cybersecurity for medical devices for the Section 524B duties that framework sits alongside, and always check FDA's live guidance page for the current title and date before citing a specific version. An Interpretation Sheet 1 (IEC 81001-5-1:2021/ISH1:2025), published 4 December 2025, clarifies specific aspects of the base standard; this guide has not purchased or read that sheet's own text, so treat its exact substance as to be confirmed against the sheet itself rather than this summary.

A workable starting point

1. Map your existing IEC 62304 life cycle first — Clauses 5-8 follow 62304's own ordering deliberately, so an existing safety life cycle is the scaffold to extend, not something to replace.
2. Decide early whether a product is "health software" or "Transitional Health Software" — new development goes through Clauses 4-9 in full; software already released may only need the Annex F gap-closure path, and conflating the two creates unnecessary rework.
3. Treat Annexes D and E as your IEC 62443-4-1 bridge, if a connected health device also needs to speak to industrial or hospital-network security buyers who ask for 62443-4-1 evidence.
4. Use Annex C's technique list as options, not a checklist — pick the threat-modelling method that fits your team's existing practice rather than trying to run all of them.
5. Confirm your FDA submission language against the current guidance page, not a cached PDF — the premarket guidance that references this standard has already been reissued three times since 2023.

SoftWSP builds the SBOM, vulnerability-matching and vulnerability-monitoring evidence that both IEC 81001-5-1's Clause 9 problem-resolution process and FDA's Section 524B duties expect: see device & firmware security and PSIRT as a service.

This guide summarises IEC's own published preview text of IEC 81001-5-1:2021, its catalogue record, and independent secondary analysis of the standard; it is not a substitute for the purchased IEC text and does not constitute regulatory or legal advice.