IEC 62304 was first published in 2006. Amendment 1 followed in 2015, and the current consolidated version, IEC 62304:2006+AMD1:2015 (edition 1.1), was published on 26 June 2015 (IEC). FDA recognised edition 1.1 in full on 14 January 2019, under recognition number 13-79. In the EU, it does not appear on the Commission's summary list of MDR harmonised standards generated on 17 June 2026 (European Commission).
IEC 62304 is the standard behind almost every medical device software file. This article explains what it covers, the safety classes, the lifecycle processes, SOUP and legacy software, and how FDA and the EU treat it.
What IEC 62304 covers
According to IEC, the standard defines the life cycle requirements for medical device software. It applies to the development and maintenance of software that is itself a medical device, or that is an embedded or integral part of a medical device.
It does not cover validation and final release of the medical device, even when the device consists entirely of software. That needs separate evidence. For health software products, IEC 82304-1 covers product validation.
In our view, three points matter in practice:
It is a process standard. It sets out processes, activities and tasks, not a document format or a development method. Agile development is compatible, provided the required tasks are done and recorded.
Maintenance counts as much as development. Most of a software file's life happens after the first release.
It sits inside a QMS and a risk management process. It assumes ISO 13485 and ISO 14971 are already in place.
The software safety classes
Clause 4.3 requires a software safety class for each software system. Since Amendment 1, the classification takes into account risk control measures outside the software.
| Class | When it applies |
|---|---|
| A | The software cannot contribute to a hazardous situation, or it can but the risk is acceptable after external risk control measures |
| B | The software can contribute to a hazardous situation that results in unacceptable risk after external risk control measures, and the possible harm is non-serious injury |
| C | As for class B, but the possible harm is death or serious injury |
Source: IEC 62304:2006+AMD1:2015, clause 4.3.
The class decides which tasks apply. Each requirement states which classes it applies to, and Annex A summarises them. Class C software needs the most detail, for example in architecture, detailed design and unit verification.
In our view, record the classification rationale at software system and item level, including which external risk controls you rely on. If the intended use, interfaces or those external controls change, revisit the class.
The lifecycle processes
| Clause | Process |
|---|---|
| 4 | General requirements: quality management system, risk management, software safety classification, legacy software |
| 5 | Software development, from planning (5.1) to release (5.8) |
| 6 | Software maintenance |
| 7 | Software risk management |
| 8 | Software configuration management |
| 9 | Software problem resolution |
Source: IEC 62304:2006+AMD1:2015.
Clause 5 runs from development planning through requirements, architecture, detailed design, unit implementation and verification, integration, system testing and release. Clause 6 covers maintenance: the maintenance plan, problem and modification analysis, and modification implementation.
Clause 7 adds software-specific risk management to ISO 14971: identifying software that could contribute to hazardous situations, risk control measures, their verification, and risk management of software changes. Clauses 8 and 9 keep releases identifiable and reproducible, and make sure problems are investigated, tracked and closed.
In our view, a change is where most files fall short. Every change after release should go through problem and modification analysis, with its risk effects assessed before the change is coded, not after testing.
SOUP and legacy software
SOUP (software of unknown provenance) is software the manufacturer did not develop under its own process, such as an open-source library or an operating system. The standard requires it to be identified as a configuration item, with its title, manufacturer and version, and its use to be justified in the context of the device.
Legacy software is covered by clause 4.4, added in Amendment 1, for software designed before the current version of the standard existed. The manufacturer has to assess what evidence exists, what is missing and whether continued use is justified.
In our view, list every third-party component and every pre-existing software item, with version and supplier, before writing the development plan. That list decides where SOUP and legacy reasoning belong in the file.
IEC 62304 at FDA
FDA's recognition 13-79 covers IEC 62304 edition 1.1 and its US adoption, ANSI/AAMI/IEC 62304:2006/A1:2016. According to FDA's premarket software guidance, a sponsor can provide a Declaration of Conformity to the parts of IEC 62304 that cover development, configuration management and maintenance practices. FDA adds that a Declaration of Conformity to the complete standard "is not needed due to known differences in categorization of device software functions and other recommended documentation".
FDA's guidance uses its own documentation levels, Basic and Enhanced, rather than the IEC 62304 safety classes. In our view, keep the IEC 62304 class in the design file and map it to the FDA documentation level in the submission.
IEC 62304 under the EU MDR
MDR Annex I Section 17.2 requires software to be developed and manufactured in accordance with the state of the art, taking into account the development life cycle, risk management including information security, and verification and validation.
EN 62304 is not on the Commission's summary list of MDR harmonised standards, so it gives no presumption of conformity under Article 8. It is still the main evidence of a state-of-the-art software life cycle. Our article on what state of the art means under the MDR explains how to document that.
| EU (MDR) | US (FDA) | |
|---|---|---|
| Status | Not harmonised under the MDR (summary list, 17 June 2026) | Recognised in full, number 13-79 |
| How it is used | Evidence of the state of the art under Annex I Section 17.2 | Declaration of Conformity to the relevant parts in a premarket submission |
| Scaling | Software safety class A, B or C | FDA Basic or Enhanced documentation level |
Sources: European Commission; FDA.
Related standards
ISO 14971: the risk management process IEC 62304 relies on.
IEC 82304-1: health software products, including product validation.
IEC 81001-5-1: security activities that extend the IEC 62304 processes. Our article on IEC 81001-5-1 covers it.
A hypothetical example
Hypothetical example: a Dutch start-up develops standalone software that flags suspected fractures on X-ray images for clinician review.
Scope: the software is itself a medical device, so its development and maintenance fall under IEC 62304.
Systems: it works under an ISO 13485 QMS and opens its ISO 14971 risk file before finalising requirements.
Class: it assigns a safety class based on the possible harm from a missed or false finding, taking into account clinician review as an external control, and writes down the rationale.
Plan: its development plan maps clause 5 to its two-week sprints and names the deliverables for each.
SOUP: the open-source imaging library is listed by name and version, with its known anomalies assessed.
Changes: each model update goes through problem and modification analysis, with risk effects assessed under clause 7.
Validation: product validation is handled outside IEC 62304, for example under IEC 82304-1.
Our article on SaMD technical documentation explains where these records sit in the file.
Conclusion
IEC 62304 sets the processes for developing and maintaining medical device software, scaled by safety class. FDA recognises it; in the EU it is not harmonised under the MDR but remains the main evidence of a state-of-the-art life cycle.
In our view, the most useful next step is a gap map: set your current life cycle, change control, SOUP list and risk file against clauses 4 to 9, and give each gap an owner and a date.
If you need help with your software life cycle, our software lifecycle management team can help, or contact MedQAIR.
Frequently asked questions
Is IEC 62304 mandatory?
No standard is mandatory in itself. FDA recognises IEC 62304, and in the EU it is the main evidence for the software life cycle requirement in MDR Annex I Section 17.2.
Is IEC 62304 harmonised under the MDR?
No. EN 62304 is not on the Commission's summary list of MDR harmonised standards generated on 17 June 2026, so it gives no presumption of conformity.
What are the IEC 62304 safety classes?
Class A, B and C, based on whether the software can contribute to a hazardous situation and how severe the possible harm is after external risk controls.
Does IEC 62304 cover validation?
No. It does not cover validation and final release of the medical device. Product validation needs separate evidence, for example under IEC 82304-1.
Can I use agile with IEC 62304?
Yes. The standard does not prescribe a life cycle model, so agile works if the required tasks are performed and recorded.
