IEC 81001-5-1: IEC 81001-5-1 – Tutorial (about 60 minutes)

IEC 81001-5-1 is the international standard that tells manufacturers of health software which security activities to carry out at each stage of the product life cycle, from planning and design through testing, release and years of maintenance. It is used by medical device manufacturers, developers of stand-alone health apps and clinical IT systems, their suppliers, and the auditors and regulators who review their work. After this tutorial you will be able to explain what the standard requires, map its activities onto an existing software life cycle, recognise the evidence an assessor expects, and plan how a real product team would apply it.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: the current and only published edition is IEC 81001-5-1:2021, edition 1.0, Health software and health IT systems safety, effectiveness and security – Part 5-1: Security – Activities in the product life cycle, published by the International Electrotechnical Commission (IEC) on 16 December 2021. It was prepared by IEC subcommittee SC 62A (common aspects of medical equipment, software and systems) in joint work with ISO technical committee TC 215 (health informatics). An Interpretation Sheet (ISH1) was issued on 4 December 2025, and the IEC webstore now sells a corrected version of the document that includes it; the interpretation sheet clarifies the text but does not create a new edition. The webstore lists a stability date of 2028. A second edition is in preparation but not published: the IEC project page shows edition 2.0 at the "approved for committee draft" stage with a forecast publication date in August 2028. In the United States the US Food and Drug Administration (FDA) lists edition 1.0 as a recognised consensus standard (recognition number 13-122, complete standard, since December 2022). In Europe the standard has been adopted as EN IEC 81001-5-1, but the European Commission's summary list of harmonised standards for the Medical Device Regulation did not cite it when checked. This course teaches edition 1.0 as amended by the interpretation sheet. Verified 2026-10-29 against the IEC webstore entry and project data for IEC 81001-5-1, the FDA Recognized Consensus Standards database and the European Commission's list of harmonised standards for medical devices.

Who it is for: software engineers, architects, testers, DevOps and platform engineers, product security specialists, quality and regulatory professionals, and project or product managers who work on software used in healthcare. It is equally useful for people who already know IEC 62304 and need to add security to an existing process, and for security professionals from other industries who are moving into medical technology.

Prerequisites: none. A general idea of how software is built and released helps. Familiarity with IEC 62304 or ISO 14971 is useful but not required; every term you need is explained in Lesson 2.

Learning objectives. After the seven lessons you will be able to:

Explain why IEC 81001-5-1 exists, which software it covers and how it grew out of IEC 62443-4-1 and IEC 62304.
Use the core vocabulary correctly, including health software, threat model, vulnerability, defence in depth and transitional health software.
Describe the structure of the standard: the general requirements and the five process groups that mirror IEC 62304.
Plan the security activities for each life cycle stage, including the four kinds of security testing and the work needed at release.
Run a post-market vulnerability handling process that connects security risk to patient safety.
Explain how conformity is demonstrated to the FDA, to European notified bodies and to customers, and what the standard does not certify.
Position IEC 81001-5-1 alongside IEC 62304, ISO 14971, IEC 62443-4-1, IEC 80001-1 and related documents.

Lesson 1 – Origins, purpose and scope

Why health software needed its own security life cycle standard

For a long time, medical software was treated mainly as a safety problem. The question regulators asked was: could a software defect hurt a patient? Standards such as IEC 62304 answered it with a disciplined development process, and ISO 14971 provided a way to analyse hazards and control risks. Security, if it appeared at all, was usually limited to user passwords and data protection rules.

That view stopped being adequate once health software became connected. Infusion pumps talk to hospital networks, implant programmers use wireless links, imaging systems store data in shared archives, patients wear sensors that send data to cloud platforms, and clinicians use web portals and mobile apps to review results. Every connection is also a route for an attacker. Incidents such as the 2017 WannaCry ransomware outbreak, which disrupted parts of the UK National Health Service and forced appointments to be cancelled, showed that a security failure can quickly become a care delivery problem and, in the worst case, a patient safety problem. Regulators responded: European medical device law now requires software to be developed with information security in mind, and US law gives the FDA explicit powers to demand cybersecurity evidence for connected devices.

Manufacturers therefore needed a clear answer to a practical question: what exactly should we do, and when, so that our software is secure by design and stays secure after release? General security management standards such as ISO/IEC 27001 describe how an organisation protects its own information; they do not describe how to engineer a secure product. The industrial world already had such a description in IEC 62443-4-1, which defines a secure product development life cycle for automation and control components. IEC 81001-5-1 takes that idea, adapts it to health software and fits it into the life cycle that medical software teams already follow under IEC 62304.

Purpose

The standard has two closely linked goals. The first is to increase the security of the health software product itself, by adding security activities and tasks to each stage of its life cycle. The second is to make the life cycle processes themselves more secure, for example by protecting source code, build tools and release packages from tampering. Both goals serve a third, higher aim described in the companion document ISO 81001-1: keeping a balance between safety, effectiveness and security, because a security control that blocks clinicians from treating a patient is not a good control.

Scope

IEC 81001-5-1 applies to health software, a deliberately broad term. It includes software that is itself a medical device, software embedded in a medical device, and software used in health care that is not regulated as a device at all, such as some wellness, scheduling or clinical information systems. The standard speaks to the organisation that develops and maintains the software, which is usually called the manufacturer. It covers the whole life cycle: development, maintenance, security risk management, configuration management and problem resolution.

Some things are deliberately outside its scope. It does not tell a hospital how to operate its network securely; that is the role of IEC 80001-1. It does not specify the technical security capabilities a product must have, such as particular encryption algorithms or authentication methods; it requires the manufacturer to decide on security requirements through risk analysis. It also excludes the specification of the contents of accompanying documentation, even though it expects security-related information to be given to users. Finally, it is not a management system standard, so it does not ask for an information security management system across the whole company.

Old software is not forgotten

Many products in hospitals today were designed long before this standard existed. Re-developing all of them from scratch is unrealistic. The standard recognises this with the idea of transitional health software: legacy health software that is already released and in use but was not developed under the secure life cycle this standard describes. A dedicated annex (Annex F) describes how such software can be brought under the security life cycle in a proportionate way, focusing on assessing and managing its security risks and supporting it in the field, rather than pretending that the original development followed processes that did not exist at the time.

Lesson 2 – Key concepts and vocabulary

The standard uses many terms that come from IEC 62304, ISO 14971, IEC 62443-4-1 and ISO 81001-1. The definitions below are explanations in plain language, not the official definitions, which you should read in the standard itself.

Health software – any software intended to be used specifically for managing, maintaining or improving the health of people or for delivering care, including software that is part of a medical device.
Health software life cycle – the full span of activities from the first idea and planning of a product, through development and release, to maintenance and eventual retirement.
Security – the state in which information and systems are protected so that only authorised people and processes can read, change or use them, and so that they are available when needed. Security is often summarised as confidentiality, integrity and availability.
Threat – a potential cause of an unwanted event, such as an attacker trying to change dosing parameters, a malware infection or an insider misusing access.
Vulnerability – a weakness in the software, its design, its configuration or its process that a threat could exploit.
Security risk – the combination of how likely it is that a threat exploits a vulnerability and how severe the consequences would be, including consequences for patient safety, care delivery and data privacy.
Threat model – a structured description of the product, its data flows, its trust boundaries, the threats against it and the mitigations chosen. It is a living artefact that is updated as the design changes.
Attack surface – the sum of all the points where an attacker can try to enter or extract data: network ports, interfaces, user inputs, update channels, removable media and so on.
Defence in depth – a design approach that uses several independent layers of protection so that the failure of one control does not expose the whole system.
Intended environment of use – the setting in which the software is expected to operate, including the networks, users, other systems and security controls that the operator is assumed to provide. Security requirements depend heavily on it.
Third-party component – software the manufacturer did not develop for this product, such as an operating system, an open-source library or a commercial database. IEC 62304 calls this kind of item SOUP (software of unknown provenance).
Software bill of materials (SBOM) – a machine-readable inventory of the components and versions that make up the product. It is not a term defined by IEC 81001-5-1, but it is the usual way manufacturers keep track of third-party components and it is required by US law for many connected devices.
Secure coding standard – a documented set of programming rules that prevent common vulnerability types, such as input validation, memory safety and error handling rules for the languages used.
Security update – a change released to fix a vulnerability or strengthen protection, often called a patch.
Coordinated vulnerability disclosure – a process in which people who find vulnerabilities report them to the manufacturer, which investigates, fixes and communicates them in an orderly way before or together with public disclosure.
Healthcare delivery organisation (HDO) – the hospital, clinic or other provider that operates the health software. Security is a shared responsibility between the manufacturer and the HDO.
Transitional health software – legacy health software that was released before it could be developed under IEC 81001-5-1, and which is brought under the standard through the special provisions of Annex F.

Safety and security are linked, not identical

A recurring idea in the standard is that security risk and safety risk are different, but connected. A vulnerability that lets an attacker read patient records is a privacy and security problem even if no one is physically hurt. A vulnerability that lets an attacker change a ventilator setting is a security problem that can lead directly to a safety hazard. The standard therefore asks manufacturers to run a security risk management process and to make sure that its outputs feed into the safety risk management process of ISO 14971 whenever a security issue could affect safety or essential performance. The two processes share information but keep their own criteria.

Processes, activities and tasks

Like IEC 62304, IEC 81001-5-1 is organised as processes, which are broken down into activities, which in turn contain tasks. Conformity means that the manufacturer has implemented the required processes, activities and tasks and can show records of having done so. The standard rarely prescribes a specific tool or technique; it says what outcome is needed and leaves the method to the manufacturer, as long as the choice is justified.

Lesson 3 – Structure of the standard

If you know IEC 62304, the structure of IEC 81001-5-1 will feel familiar, and that is intentional. The authors aligned the clause numbers with IEC 62304 so that a manufacturer can add security tasks to the same development, maintenance, risk, configuration and problem resolution processes it already runs, instead of building a separate security process alongside them.

Figure 1 – General requirements frame five process groups whose numbering mirrors IEC 62304, with a special annex for older released software.

Clauses 1 to 3: scope, references and terms

Clause 1 sets out the purpose and field of application and explains what conformity means. Clause 2 lists the documents that are needed to apply it. Clause 3 defines the terms, many of which are shared with IEC 62304, IEC 62443-4-1 and ISO 81001-1. Note the typographic convention: terms defined in the standard are printed in small capitals in the original text.

Clause 4: general requirements

Clause 4 sets up the organisational foundation that the processes rely on. In summary, it expects the manufacturer to:

carry out the security activities within a quality management system, so that plans, records, reviews and corrective actions follow controlled procedures;
assign responsibilities for security activities and make sure the people involved have adequate security expertise, through training or by involving specialists;
establish a security risk management approach that is applied across the life cycle and linked to safety risk management;
consider the security of components and services obtained from suppliers, because weaknesses in a supplier's product become weaknesses in yours;
improve the secure life cycle over time, learning from incidents, vulnerabilities and audits.

Clause 5: software development process

Clause 5 follows the same sequence of activities as the development process in IEC 62304: development planning, requirements analysis, architectural design, detailed design, unit implementation and verification, integration testing, system testing and release. For each activity it adds security tasks. Examples are documenting the security context of the product during requirements analysis, applying defence in depth and reviewing the threat model during architectural design, following secure coding standards during implementation, and running specific security tests before release. Lesson 4 walks through these in order.

Clause 6: software maintenance process

Clause 6 covers the period after release. It expects a maintenance plan that includes monitoring for new vulnerabilities, analysing reported problems for security relevance, and delivering security updates in a timely and controlled way. It also recognises that the manufacturer must tell operators about updates and about vulnerabilities that cannot be fixed immediately, so that they can apply compensating controls.

Clause 7: security risk management process

Clause 7 describes the risk process specific to security: identifying threats and vulnerabilities, estimating and evaluating security risks, deciding on controls, verifying that the controls work, and monitoring risks throughout the life of the product. It mirrors the role clause 7 plays for safety risk in IEC 62304, and it requires a connection to ISO 14971 so that security risks with safety consequences are handled in the safety risk file as well.

Clause 8: software configuration management process

Clause 8 adds security to configuration management. Beyond identifying items and controlling changes, the manufacturer must protect the integrity of the code base and build environment, keep track of third-party components and their versions, and make sure that what is released is exactly what was tested.

Clause 9: software problem resolution process

Clause 9 deals with security-related problems: receiving vulnerability reports from inside and outside the company, reviewing and analysing them, deciding what to do and tracking them to closure. It is where coordinated vulnerability disclosure lives.

Annexes

The annexes are mostly informative. They explain the rationale for the requirements, give guidance on implementing the security activities (including threat modelling), show how the activities relate to the practices of IEC 62443-4-1, and help with documentation. Annex F, on transitional health software, is the one most teams read early, because almost every manufacturer has products already on the market.

How it maps to IEC 62443-4-1

IEC 62443-4-1 organises its requirements into eight practices: security management, specification of security requirements, secure by design, secure implementation, security verification and validation testing, management of security-related issues, security update management, and security guidelines. IEC 81001-5-1 covers the same ground but redistributes it into the IEC 62304 process structure. A company that already works to IEC 62443-4-1 for industrial products will find most of its practices reusable; the main adaptations concern health-specific risk thinking, the link to ISO 14971 and the use of medical software vocabulary.

Lesson 4 – How it works in practice

This lesson follows a product through its life cycle and shows which security activities a team performs at each stage, what artefacts it produces and who is typically involved. The standard does not prescribe a waterfall model; agile and continuous delivery teams apply the same activities iteratively, as long as the outcomes and records exist.

Figure 2 – Security tasks added to each development activity, with maintenance feeding new threats back into the design.

Roles

The standard assigns work to the manufacturer rather than to named job titles, but in practice the following roles appear. A product security lead owns the security plan and the threat model. Developers and architects implement security requirements and follow the coding rules. Testers, some of whom must be independent of the developers for certain tests, verify the controls. The quality and regulatory team integrates the activities into the quality management system and prepares regulatory submissions. A product security incident response team (often abbreviated PSIRT) receives and handles vulnerability reports after release. Small companies combine several roles; the key is that each responsibility is assigned and the person has the necessary competence.

Planning

The development plan describes which security activities will be performed, by whom, using which tools, standards and test methods, and how results will be recorded. It also states how security risk management connects to safety risk management and how third-party components will be selected and monitored. A useful plan is specific: it names the secure coding standards for each language, the static analysis tools, the threat modelling method and the criteria for passing security tests.

Requirements: define the security context

Before deciding what the software must do, the team describes where and how it will be used. Who are the users? Which networks will it connect to? What security measures will the hospital or patient provide, and which must the product provide itself? This description of the intended environment and its assumptions is the foundation for security requirements. Requirements then cover topics such as authentication and authorisation, protection of data at rest and in transit, logging and audit trails, secure update mechanisms, safe behaviour when security controls fail, and the ability to recover. Each requirement must be verifiable, because it will later be tested.

Architecture and design: threat modelling and defence in depth

Threat modelling is the heart of secure design. The team draws the architecture, marks data flows and trust boundaries, and systematically asks what could go wrong at each element. A common technique is STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege), although the standard leaves the method open. For each credible threat the team chooses mitigations, records them as requirements or design decisions, and estimates the remaining risk. The threat model is reviewed whenever the architecture changes.

Defence in depth means that the design does not rely on a single barrier. For example, a device might authenticate every network message, run services with minimal privileges, separate safety-critical functions from user interface functions, and log security events so that an attack can be detected. If one layer fails, the others still limit the damage. The design should also reduce the attack surface: close unused ports, remove debug interfaces from production builds and disable services that are not needed.

Implementation: secure coding and review

Developers follow the secure coding standards chosen in the plan and use tools such as static code analysis to find common weaknesses. Code reviews include security criteria. Third-party components are selected deliberately, with attention to their security history and maintenance status, and recorded with exact versions. The build environment itself is protected: access to repositories is controlled, build pipelines are hardened, and signing keys are protected so that attackers cannot insert malicious code.

Verification: four kinds of security testing

The standard expects system-level security testing that goes beyond functional testing. It is useful to think of four complementary kinds of tests:

Security requirements testing checks that every security requirement is met, for example that an account is locked after repeated failed logins.
Threat mitigation testing checks that the mitigations chosen in the threat model actually work against the threats they were meant to address.
Vulnerability testing looks for weaknesses nobody planned for, using techniques such as fuzzing (feeding malformed inputs), scanning for known vulnerabilities in components, and analysing the attack surface.
Penetration testing has skilled testers act like attackers and try to break the product as a whole, chaining small weaknesses into real attacks.

Because developers tend to test what they expect to work, the standard requires the manufacturer to manage conflicts of interest between testers and developers, which in practice means that some testing, especially penetration testing, is done by people independent of the development team, either an internal team or an external provider.

Release

Before release the team confirms that all planned security activities are complete, that open security issues have been evaluated, and that the remaining security risk is acceptable and documented. The release must be protected against tampering, for example by digitally signing the software and its updates so that operators can check its integrity. Users receive security-related information: how to install and configure the product securely, which security controls the environment is expected to provide, which ports and services the product uses, how updates are delivered, and how to report a vulnerability. Many manufacturers also prepare an SBOM and a Manufacturer Disclosure Statement for Medical Device Security (MDS2), a form widely used by hospitals, to help HDOs assess the product.

Maintenance and problem resolution

Security work increases after release. New vulnerabilities are published every day in operating systems and open-source libraries, and attackers keep developing new techniques. The maintenance plan therefore includes continuous monitoring of vulnerability sources for every third-party component, a channel for receiving reports from researchers and customers, a triage process, and criteria for how quickly different kinds of issues must be addressed.

Figure 3 – A security problem resolution flow that links vulnerability analysis to safety risk management and ends with process improvement.

When a vulnerability is confirmed, the team analyses which product versions are affected, how easily it could be exploited in the intended environment and what harm could follow. If patient safety could be affected, the safety risk file is updated too. The team then decides whether to release a security update, provide compensating measures that operators can apply until a fix is ready, or accept the risk with justification. Customers are informed in a way that helps them act without giving attackers a recipe. Finally, the team asks why the vulnerability got in and whether the process should change, for example by adding a coding rule or a test.

Artefacts you will typically see

Life cycle stage	Typical security artefacts
Planning	Security section of the development plan, roles and competence records, tool list
Requirements	Description of the intended environment and assumptions, security requirements
Design	Threat model, architecture showing trust boundaries and defence in depth
Implementation	Secure coding standards, static analysis results, review records, component inventory
Verification	Security test plans and reports, penetration test report, evidence of tester independence
Release	Residual security risk evaluation, signed release package, security information for users
Maintenance	Vulnerability monitoring records, problem reports, security advisories, update records

Lesson 5 – Assessment, certification and compliance

There is no single "IEC 81001-5-1 certificate" that settles everything

IEC 81001-5-1 is a process standard. The IEC itself does not certify companies against it, and conformity is not a legal requirement in its own right. Instead, the standard is a recognised way of showing regulators, notified bodies and customers that security has been built into the product life cycle. How that conformity is demonstrated depends on who is asking.

Conformity is also not graded. Unlike maturity models, the standard does not define levels from one to five. A manufacturer either performs the required activities and tasks with adequate records, or it does not; where a requirement does not apply, the manufacturer documents why. Assessors look for this justification as carefully as they look for the evidence itself.

United States: FDA

The FDA lists IEC 81001-5-1 edition 1.0 as a recognised consensus standard. A manufacturer can declare conformity to it in a premarket submission, which can reduce the amount of supporting detail the FDA needs to see for the topics the standard covers. The FDA's recognition entry is explicit, however, that conformity may not satisfy every cybersecurity requirement of section 524B of the Federal Food, Drug, and Cosmetic Act or every recommendation of its premarket cybersecurity guidance. Section 524B, added by law in 2022 and applied from March 2023, covers "cyber devices": devices that include software, can connect to the internet and could be vulnerable to cybersecurity threats. For such devices the manufacturer must provide a plan to monitor and address post-market vulnerabilities, including coordinated vulnerability disclosure, processes that give reasonable assurance of cybersecurity including the ability to deliver updates, and an SBOM. Following IEC 81001-5-1 builds most of the processes needed, but submissions still need the specific documents the FDA expects, such as threat models, security architecture views and testing evidence.

European Union: MDR and IVDR

The EU Medical Device Regulation (MDR) and In Vitro Diagnostic Medical Device Regulation (IVDR) contain general safety and performance requirements for software. They require software to be developed according to the state of the art, taking into account the development life cycle, risk management including information security, and verification and validation, and they require manufacturers to set minimum IT security requirements, including protection against unauthorised access. The Medical Device Coordination Group guidance MDCG 2019-16 explains how these requirements apply to cybersecurity.

A standard only gives a legal "presumption of conformity" when it is harmonised, meaning its reference is published in the Official Journal of the EU. When checked for this course, the European version EN IEC 81001-5-1 was not on the Commission's list of harmonised standards for the MDR. That does not make it irrelevant: notified bodies widely treat it as the state of the art for secure health software development, and manufacturers routinely reference it in their technical documentation. Always check the current list before stating in a submission that the standard is harmonised.

How an assessor looks at it

Whether the assessor is an FDA reviewer, a notified body auditor or a hospital's security team, the questions are similar:

Is the secure life cycle defined in controlled procedures, and are responsibilities and competence clear?
For this product, is there a documented security context, a threat model and a set of security requirements traceable to tests?
Were the four kinds of security testing performed, with appropriate independence, and were findings resolved?
Is the remaining security risk evaluated and accepted by the right people, and is it linked to the safety risk file?
Are third-party components inventoried and monitored, and is there a working process to receive, analyse and fix vulnerabilities?
Do users receive the information they need to operate the product securely?

Voluntary third-party assessment

Several independent testing and certification bodies offer audits against IEC 81001-5-1 and issue certificates or attestation reports. Such certificates can be useful in sales conversations with hospitals and as preparation for regulatory review, but they are voluntary. They do not replace the regulator's own assessment of the product, and their value depends on the scope that was actually assessed: a certificate for a company's process says little about whether a particular product release followed it.

Customers and procurement

Hospitals increasingly ask suppliers about secure development practices during procurement. Answering with "we follow IEC 81001-5-1" is useful only when backed by evidence: a summary of the process, recent penetration test results, the SBOM, the vulnerability disclosure policy and a commitment on how long security updates will be provided.

Lesson 6 – Worked example

This example is fictional but realistic. PulseTrail is a 120-person company that makes a remote cardiac monitoring system. A patient wears an adhesive sensor patch that records heart rhythm. A mobile app on the patient's phone collects the data over Bluetooth Low Energy and uploads it to a cloud service. Algorithms in the cloud flag possible arrhythmias, and cardiologists review flagged recordings in a web portal. The system is regulated as a medical device in the EU and the US. PulseTrail already develops software under IEC 62304 and manages risk under ISO 14971, but its security work has been informal: a yearly penetration test and a password policy.

Step 1: gap analysis and plan

The quality manager and a newly hired product security lead compare the company's procedures with IEC 81001-5-1. Because the clause structure mirrors IEC 62304, they go through the existing development, maintenance, risk, configuration and problem resolution procedures one by one and list missing security tasks. The gaps are clear: no threat model, no secure coding rules, no systematic monitoring of open-source components, no vulnerability intake channel, and no defined link between security findings and the safety risk file. They update the procedures, train the developers, and add a security section to the development plan for the next release.

Step 2: security context and requirements

The team describes the intended environment. Patients use their own phones, which may be outdated or compromised. The cloud runs on a major hosting provider. Cardiologists access the portal from hospital networks and sometimes from home. The team records its assumptions, such as that hospitals provide managed workstations, and the controls it must provide itself, such as encryption and strong authentication. Security requirements follow: the patch only pairs with an authorised app, data is encrypted end to end, the portal requires multi-factor authentication, all access to patient data is logged, and the app keeps buffered data safe if the phone is lost.

Step 3: threat model and design

Using STRIDE, the team examines each data flow. Threats include an attacker spoofing a patch to inject false rhythm data, tampering with uploads to hide an arrhythmia, a denial of service that delays alerts, and theft of portal credentials. Some threats have safety consequences: missed or delayed alerts could harm a patient. These are entered into the ISO 14971 risk file as well as the security risk file. Mitigations include signed sensor data, server-side plausibility checks, rate limiting, alerting if data stops arriving, and separation of the alert-generation service from the portal front end so that a portal compromise cannot suppress alerts. This is defence in depth: no single control protects the alert path.

Step 4: implementation and components

The team adopts secure coding rules for its Kotlin, Swift, C and Python code and adds static analysis to the build pipeline, failing builds on high-severity findings. It generates an SBOM for the app, the cloud services and the patch firmware, and connects it to a service that monitors public vulnerability databases. Access to the source repository requires multi-factor authentication, and firmware and app releases are signed with keys kept in a hardware security module.

Step 5: security testing

Testers verify every security requirement and write tests for each threat mitigation, for example attempting to pair an unauthorised app with the patch. They fuzz the Bluetooth protocol parser and the upload API, scan all components for known vulnerabilities, and review the attack surface of the cloud deployment. An external firm, independent of the developers, performs a penetration test of the whole system and finds that an old debug endpoint remains reachable in the cloud environment. It is removed, a configuration check is added to the pipeline, and the threat model is updated.

Step 6: release

Before release, the product security lead reviews remaining issues. Two low-severity findings are accepted with documented justification; one medium finding is fixed. The residual security risk, together with its safety implications, is presented to the release board. Hospitals receive a security guide describing network requirements, recommended portal access settings, update procedures and the vulnerability reporting address. An SBOM and an MDS2 form are made available to customers on request.

Step 7: a vulnerability after release

Eight months later, a serious vulnerability is published in an open-source compression library used by the upload service. The monitoring service alerts the PSIRT within hours. Analysis shows the library is reachable from the internet-facing API, so the risk is high; because tampered uploads could hide arrhythmias, the safety risk file is reviewed too. The team releases a fixed service within days, after regression and security tests, and publishes an advisory explaining that no customer action is needed because the cloud is centrally managed. For the mobile app, which also includes the library but does not expose the vulnerable function, the fix is scheduled into the next regular release with a documented rationale. Finally, the root-cause review leads to a new rule: components must be updated to supported versions at least every quarter.

Step 8: the older product

PulseTrail also supports a previous generation of the patch whose firmware was released years before the company adopted the standard. Rather than claim the old development followed the new process, the team treats it as transitional health software under Annex F: it performs a threat analysis of the existing design, reviews known vulnerabilities in its components, adds compensating controls in the cloud where the device cannot be changed, tells customers about remaining risks and plans an end-of-support date.

What the example shows

The standard did not require PulseTrail to throw away its process. It required the company to add specific security tasks at each step, to connect security risk to safety risk, to test like an attacker, and to keep working after release. The evidence produced along the way is what regulators and hospitals later review.

Lesson 7 – Relationship to other standards and frameworks

IEC 81001-5-1 is one part of a larger set of documents. Understanding its neighbours prevents two common mistakes: expecting it to cover topics that belong elsewhere, and duplicating work that another standard already defines.

Figure 4 – How IEC 81001-5-1 draws on concepts, industrial practice and quality management, and feeds the software, risk and operator standards.

Standard	Focus	Relationship to IEC 81001-5-1
IEC 62304	Software life cycle processes for medical device software	Provides the process structure that IEC 81001-5-1 mirrors; IEC 81001-5-1 adds security tasks to each process
ISO 14971	Risk management for medical devices, focused on harm	Receives security risks that could affect safety; security risk management runs alongside it with its own criteria
IEC 62443-4-1	Secure product development life cycle for industrial automation components	The source model; its eight practices are redistributed into the health software processes
ISO 81001-1	Principles, concepts and terms for safety, effectiveness and security of health software	Provides the shared vocabulary and the idea of balancing the three key properties
IEC 80001-1	Risk management by organisations that operate IT networks incorporating health software	Covers the hospital side; manufacturers supply the information HDOs need for it
IEC 82304-1	Product safety and validation of stand-alone health software	Covers the product level; IEC 81001-5-1 supplies the security life cycle within it
ISO 13485	Quality management system for medical device organisations	Provides the quality system in which the security activities are planned and recorded
ANSI/AAMI SW96	US standard for security risk management by device manufacturers	Goes deeper into security risk management; often used together with IEC 81001-5-1 for FDA submissions
ISO/IEC 27001	Information security management system for an organisation	Protects the company's own information; complements but does not replace product security engineering

Technical capabilities versus process

IEC 81001-5-1 tells you how to develop securely; it does not list the security features a product must have. For medical electrical equipment, the technical report IEC TR 60601-4-5 offers guidance on technical security capabilities, based on the industrial component requirements in IEC 62443-4-2. Many manufacturers use the two together: the process standard to decide and verify requirements, the capability guidance as a catalogue of options.

Regulations and guidance

Regulations set legal obligations and refer to standards as one way to meet them. In the EU, the MDR, IVDR and MDCG 2019-16 frame the expectations. In the US, section 524B and the FDA premarket cybersecurity guidance do the same. Note also that the EU Cyber Resilience Act, which introduces security requirements for many connected products, excludes products already covered by the MDR or IVDR, so medical device software continues to be regulated through medical device law. Other jurisdictions, such as Health Canada and Australia's Therapeutic Goods Administration, publish their own cybersecurity guidance and generally refer to similar life cycle practices.

Choosing what to apply

A practical rule of thumb: use ISO 13485 for the quality system, IEC 62304 for the software life cycle, IEC 81001-5-1 for the security tasks inside that life cycle, ISO 14971 and a security risk method such as AAMI SW96 for risk, IEC 82304-1 if the product is stand-alone software, and provide the information hospitals need for IEC 80001-1. Each piece answers a different question, and together they form a coherent story for auditors.

Common pitfalls and best practices

Common pitfalls

Treating security as a one-off test. A yearly penetration test without threat modelling, secure coding and monitoring cannot show conformity and finds problems too late to fix cheaply.
Building a parallel security process. Running security in a separate document set that developers never read leads to gaps and contradictions; the standard is designed to be embedded in the existing IEC 62304 processes.
Ignoring third-party components. Most vulnerabilities in modern software come from libraries and platforms. Without an accurate inventory and monitoring, the team cannot tell whether a newly published vulnerability affects its product.
Disconnecting security from safety. Evaluating a vulnerability only for data impact may miss the scenario in which an attacker changes therapy or suppresses an alarm.
Letting developers test only their own work. Without independent testing, blind spots stay hidden and assessors will question the results.
Forgetting the operator. If hospitals do not receive clear security information, they cannot configure, patch or monitor the product, and shared responsibility fails.
Claiming legacy products conform fully. Overstating the history of an old product undermines credibility; transitional provisions exist for a reason.

Best practices

Start with a gap analysis against your IEC 62304 procedures and add security tasks where they belong, so that one process serves both.
Make the threat model a living artefact that is reviewed at every significant design change and after every relevant vulnerability.
Automate what you can: static analysis, component scanning and SBOM generation in the build pipeline keep evidence current without extra effort.
Define response targets for vulnerabilities by severity and exploitability, and measure how well you meet them.
Publish a vulnerability disclosure policy with a clear contact so that researchers and customers can report issues easily.
Write security guidance for users early and test it with real hospital IT staff before release.
Plan the support period for security updates and communicate end-of-support dates well in advance.

Summary and key takeaways

IEC 81001-5-1:2021 (edition 1.0, with Interpretation Sheet 1 of 2025) defines the security activities a manufacturer performs across the health software life cycle; a second edition is in preparation but not published.
It applies to health software in a broad sense, including medical device software, stand-alone health software and non-device clinical software.
It adapts the secure development model of IEC 62443-4-1 to healthcare and mirrors the clause structure of IEC 62304, so security tasks fit into existing processes.
Key activities include defining the security context, threat modelling, defence in depth, secure coding, four kinds of security testing with independence, protected release and continuous vulnerability handling.
Security risk management runs alongside safety risk management and passes on any security risk that could affect patient safety.
Older released software is handled through the transitional provisions of Annex F rather than by pretending it was developed under the standard.
Conformity is shown through records in the technical documentation; the FDA recognises the standard, EU notified bodies widely treat it as the state of the art although it is not harmonised, and voluntary third-party certificates exist but replace no regulatory assessment.

Reflection questions

Think of a health software product you know. What does its intended environment of use look like, and which security controls would you expect the operator to provide rather than the product?
Pick one data flow in that product and walk through the six STRIDE categories. Which threat worries you most, and which two independent controls would you put in its way?
Your organisation already follows IEC 62304. Which three security tasks would you add first to your procedures, and why those three?
A vulnerability is published in a component you use, but the vulnerable function is not called by your code. How would you decide whether to release an update, and what would you record?
A hospital asks whether your product is "certified to IEC 81001-5-1". What evidence would you offer, and how would you explain what such a statement does and does not mean?