IEC 81001-5-1: health-software security lifecycle
Sytance · Updated
IEC 81001-5-1 is a health-software lifecycle cybersecurity standard. It sets out processes for secure development and maintenance, including threat modelling, updates and accompanying-documentation review. Those records can support medical-device regulatory submissions.
Health software focus
IEC 81001-5-1:2021 applies to health software, including medical-device software. Its scope is wider than regulated medical devices, and its legal effect depends on the jurisdiction using it. It is therefore best treated as a lifecycle process standard that supports a regulatory file rather than as the regulatory file itself.
Published status
ISO and IEC list IEC 81001-5-1:2021 as the published first edition. ISO also lists a second edition project under development, so the 2021 edition remains the current published edition until the replacement is issued. IEC’s December 2025 corrected version incorporates Interpretation Sheet 1 (ISH1:2025); the updated copy retains the first-edition number.
FDA recognition
FDA recognises IEC 81001-5-1 Edition 1.0 from 2021 as consensus standard 13-122. That recognition can support FDA evidence, but it does not replace FDA premarket guidance or section 524B duties.
EU use
In an EU file, the standard can help organise software lifecycle, cybersecurity risk management and maintenance evidence. The manufacturer still has to map the evidence to MDR or IVDR requirements.
Lifecycle activities
IEC 81001-5-1 integrates cybersecurity into the software lifecycle. Security activities are planned and performed during development, reviewed and documented, then maintained after release.
The standard links secure health-software development to a quality-management system and a risk-management process. The evidence should show how requirements, design, implementation, verification, validation, change control and maintenance remain traceable.
Development planning sets out how security requirements will be implemented and checked, and how changes will be recorded. It also defines the development environment and coding practices, together with responsibility for product support and security updates.
The threat model describes the software and its interfaces, including maintenance or debug access that could create an attack path. It explains the attack conditions and proposed controls. The development team reviews the model and updates it when a released product or its threat environment changes.
The lifecycle should include a way to receive, analyse, prioritise and resolve cybersecurity problems after release. That includes vulnerability handling, security maintenance, updates, patches, support records and communication with users or operators.
Security documentation explains how the software is protected and which external controls it needs. Users need to know how to configure and maintain those controls, obtain security updates and report problems. Component information supports their assessment of software dependencies.
The scope excludes specification of accompanying-documentation contents. That does not remove documentation activities from the lifecycle: ISH1:2025 clarifies the review activity in 4.1.9 and points to security guidelines in 5.8.2 and 5.8.7. It also explains support categories and risk transfer between manufacturers and operators. The applicable medical-device rules still determine the regulatory user-information content.
Relationship to IEC 62443-4-1
IEC 81001-5-1 was developed to support a secure health-software lifecycle while taking account of IEC 62443-4-1 concepts. Compliance with IEC 81001-5-1 does not automatically prove full IEC 62443-4-1 conformance for an industrial automation and control system product.
- Use IEC 81001-5-1 to frame secure health-software lifecycle work.
- Use IEC 62443-4-1 concepts when the product or customer environment calls for an industrial-control-system approach.
- Keep the evidence device-specific: intended use, intended environment, safety impact, update model and operator responsibilities matter more than broad standard-name references.
Use with regulation
A manufacturer can use IEC 81001-5-1 lifecycle records to support FDA secure product development, EU MDR software lifecycle and cybersecurity risk-management evidence, SBOM maintenance, threat-model governance, patch planning and user documentation.
FDA
Map IEC 81001-5-1 records to FDA premarket guidance topics such as SPDF, threat modelling, security architecture, security testing, SBOM, labelling and the cybersecurity management plan.
EU MDR and IVDR
Map the lifecycle records to Annex I software, information-security and operating-environment requirements, then into Annex II technical documentation and Annex III PMS evidence.
SBOM and component security
Use the SBOM as a maintained lifecycle artefact, not a one-time submission attachment. Component inventory, support status and vulnerability monitoring must remain aligned after release.
Postmarket updates
The standard's maintenance and problem-resolution expectations can support vulnerability handling, security updates, patch validation and customer communication across the supported life of the software.