Overview

The software life cycle standard for medical device software. It defines development, maintenance, risk management, configuration management and problem resolution processes, scaled by software safety class A, B or C. A second edition is in development.

IEC 62304:2006+AMD1:2015, Medical device software — Software life cycle processes, is the standard that defines how medical device software must be developed and maintained. The base standard was published in 2006 and Amendment 1 was published in 2015; a consolidated version incorporating the amendment is what most organizations use. It applies both to software that is itself a medical device and to software that forms part of a medical device.

The organising principle is the software safety classification. Software is assigned to Class A (no injury or damage to health is possible), Class B (non-serious injury is possible) or Class C (death or serious injury is possible), based on the hazards that could arise from software failure, taking account of risk control measures external to the software. The class determines which activities and tasks are required: Class A requires the fewest, Class C the most. Amendment 1 clarified that the classification is made before external risk controls are credited in a way that allows a lower class only where the external control genuinely mitigates the hazard, and introduced the concept of applying the standard to legacy software.

The standard specifies five process groups. The software development process covers planning, requirements analysis, architectural design, detailed design, unit implementation and verification, integration and integration testing, system testing and release. The software maintenance process covers establishing a maintenance plan, analysing feedback and problem reports, and implementing modifications. The software risk management process covers analysis of software contributing to hazardous situations, risk control measures, verification of those measures and management of changes. The software configuration management process covers configuration identification, change control and configuration status accounting. The software problem resolution process covers preparing problem reports, investigating, advising relevant parties, using the change control process and maintaining records.

A concept unique to this standard is SOUP — software of unknown provenance. Third-party, open source and legacy components that were not developed to be part of a medical device are treated explicitly: the manufacturer must specify functional and performance requirements for the SOUP item, specify the hardware and software required for it, evaluate published anomaly lists, and include SOUP in the software risk analysis. This is where most modern device software projects concentrate their effort, since almost all such software includes third-party libraries or an operating system.

IEC 62304 does not stand alone. It makes a normative reference to ISO 14971, requiring the manufacturer to operate a risk management process in accordance with it; the standard assumes a quality management system, typically ISO 13485; and it works alongside IEC 62366-1 for usability and IEC 60601-1 for programmable electrical medical systems. The standard does not prescribe a development model — it can be applied with any life cycle model provided the required activities and outputs exist.

IEC 62304 is not directly certifiable. There is no IEC 62304 certificate for an organization. Conformity is demonstrated in the device technical documentation and assessed during ISO 13485 audits, notified body conformity assessment under EU MDR and IVDR, and regulatory premarket review. Some assessment bodies offer voluntary attestations of a software development process against the standard, but these are not accredited management system certification.

A second edition is in development and had not been published as of August 2026. The draft direction includes a broader scope covering health software rather than only regulated medical device software, replacement of the three safety classes with a smaller number of process rigour levels, and explicit provisions for artificial intelligence and machine learning development. Organizations should continue to work to the 2006+AMD1:2015 text until a new edition is published, after which regulators would be expected to allow a transition period.

Purpose

To define the life cycle requirements for medical device software, establishing a common framework of processes, activities and tasks that provides a basis for demonstrating that safe medical device software has been developed and maintained.

Key Benefits

• Provides the internationally accepted process framework for medical device software
• Scales required rigour to the harm software failure could cause through safety classes A, B and C
• Addresses third-party, open source and legacy components explicitly through SOUP requirements
• Links software risk management directly to ISO 14971 device risk management
• Covers maintenance and problem resolution, not just initial development
• Compatible with any software development life cycle model, including agile approaches
• Recognised by notified bodies and regulators as evidence of a disciplined development process
• Provides traceability from requirements through design, implementation and testing

Key Requirements

• Operate a quality management system and a risk management process in accordance with ISO 14971
• Assign a software safety class (A, B or C) to the software system and its items
• Establish a software development plan covering deliverables, traceability, configuration management and verification
• Define and verify software requirements, including functional, performance and risk control requirements
• Define software architecture, including the segregation of items where used to justify a lower safety class
• Produce detailed design for software units as required by the safety class
• Implement and verify software units against defined acceptance criteria
• Integrate software items and conduct integration testing with recorded results
• Conduct software system testing and evaluate, record and resolve anomalies
• Release software with documented residual anomalies, versions and archived configuration
• Specify requirements for SOUP items, evaluate published anomaly lists and include SOUP in risk analysis
• Perform software risk management: identify contributing software items, define and verify risk control measures
• Operate configuration management: identification, change control and configuration status accounting
• Operate a problem resolution process covering reporting, investigation, notification and change control
• Establish and execute a software maintenance plan, analysing feedback and implementing modifications
• Maintain traceability between requirements, risk controls, design, tests and anomalies

Who Needs This Standard?

Medical device manufacturers developing embedded or accompanying software, developers of software as a medical device including mobile and cloud-based applications, in vitro diagnostic software developers, and contract software development organizations serving the sector. It concerns software engineering, systems, quality and regulatory affairs teams, and is examined by notified bodies, MDSAP auditors and regulatory reviewers.

Related Standards