IEC 62304

IEC 62304 is the international standard for the life cycle of medical device software: how you plan, build, test, release and maintain it, scaled to a software safety class. Notified bodies, UK approved bodies and the US FDA expect it. It is not certifiable on its own: you show conformity inside your device’s conformity assessment.

What it is and who it applies to

The formal designation is IEC 62304:2006+AMD1:2015, Medical device software, software life cycle processes, published by the International Electrotechnical Commission. The edition in use is the 2006 first edition with Amendment 1 of 2015, which the IEC also sells as one consolidated text. Amendment 1 rewrote how you assign a safety class and added a route for legacy software. The IEC was preparing a second edition in 2026, with a simpler two-level safety classification planned; until it is published, the amended first edition is the one assessors use.

The standard applies to any manufacturer whose medical device is software or contains software. That covers software as a medical device (SaMD), such as a diagnostic app or a clinical decision tool, and firmware embedded in a physical device such as an infusion pump. It covers maintenance as well as development, so a team that only updates a released product is in scope too.

IEC 62304 assumes two systems are already in place. You develop the software inside a quality management system, usually ISO 13485, and you manage risk with ISO 14971, the device version of the method in the risk assessment guide. The standard does not repeat either; it plugs into them.

Whether your software is a medical device at all is a question of intended purpose under the regulation, not of this standard. MDCG 2019-11 is the European guidance on qualifying and classifying software; MDCG 2019-16 covers cybersecurity. IEC 82304-1 covers health software products more widely, and IEC 81001-5-1 adds security activities to the same life cycle.

This is guidance to help you understand the requirement, not legal advice.

Structure

Clauses 1 to 3 set out the scope, references and definitions. The requirements sit in clauses 4 to 9. Each process requirement says which safety classes it applies to, so a class A product does less than a class C one. The table paraphrases each part.

The three safety classes

IEC 62304:2006 4.3 asks you to classify each software system by what a software failure could lead to, after counting risk controls outside the software. Class A means the software cannot contribute to a hazardous situation, or the resulting risk is acceptable; class B means it can lead to an unacceptable risk whose worst possible harm is a non-serious injury; class C means that harm could be death or serious injury. Until you have assigned a class, the class C requirements apply.

You may split a system into software items with different classes, but only where the architecture shows the lower-class item cannot affect the higher-class one. Class A needs the least: planning, requirements, system testing, release, maintenance, risk management, configuration management and problem resolution. Class B adds architectural design (IEC 62304:2006 5.3), unit verification and integration testing. Class C adds detailed design of each unit (IEC 62304:2006 5.4) and extra acceptance criteria for units.

Software of unknown provenance and legacy software

Almost every product uses software it did not write: an operating system, a database driver, an open-source library. IEC 62304 calls this software of unknown provenance (SOUP), and it also covers code you wrote earlier without adequate development records. You record each SOUP item by title, maker and version under configuration management, and state the functional and performance requirements it must meet. Risk management then has you review its published anomaly list for anything that could contribute to a hazardous situation (IEC 62304:2006 7.1).

IEC 62304:2006 4.4, added by Amendment 1, gives a route for legacy software already on the market: assess its post-market history, run a gap analysis against the standard, and close the gaps that matter to safety, rather than redocumenting the whole product.

Certification and enforcement

No accredited certification scheme exists for IEC 62304 in the way one does for ISO 13485, and no certificate to it opens a market. Some testing organisations offer a voluntary assessment against the standard; it is not a conformity assessment route. What counts is how your software evidence fares in your device’s own conformity assessment.

In the EU

The EU MDR asks for software to be developed and manufactured in line with the state of the art, taking account of the development life cycle, risk management including information security, and verification and validation (EU MDR Annex I, section 17.2). The technical documentation must hold the software verification and validation evidence (EU MDR Annex II).

As at the amendment of 11 June 2026, EN 62304 was not among the harmonised standards listed under Regulation (EU) 2017/745 in Implementing Decision (EU) 2021/1182. Following it therefore gives no automatic presumption of conformity. Notified bodies nevertheless treat it as the state of the art, so in practice you either follow it or justify an equivalent process in your technical documentation.

The device’s class sets who checks the work. Software that informs diagnostic or therapeutic decisions is at least class IIa under EU MDR Annex VIII Rule 11, and higher where a wrong decision could cause serious or irreversible harm. A notified body then audits your quality system and reviews technical documentation: on a sampling basis for class IIa and IIb, and for every class III device. Class I software is self-declared, with no notified body.

In Great Britain and the US

In Great Britain, EN 62304:2006 with its 2008 corrigendum has been a designated standard under UK MDR 2002 since 1 January 2021; the designation does not include Amendment 1. A UK approved body reviews the software evidence for devices above Class I. In the US, the FDA lists the amended IEC 62304 among its recognised consensus standards, so a submission can declare conformity with it.

What triggers trouble is a documentation gap: no safety class rationale, a SOUP list that does not match the build, or anomalies released without evaluation. These appear as notified body nonconformities and delay the certificate until they are closed.

How the pieces fit

The processes form a loop around risk management. Risk analysis tells you the safety class and the risk controls the software must carry. Planning (IEC 62304:2006 5.1) fixes how you will work. Requirements (IEC 62304:2006 5.2) turn intended use and risk controls into testable statements. Architecture and detailed design break the software into items. Units are built and verified (IEC 62304:2006 5.5), integrated (IEC 62304:2006 5.6) and tested as a system (IEC 62304:2006 5.7). Release (IEC 62304:2006 5.8) records exactly what shipped and which known anomalies remain.

After release, maintenance (IEC 62304:2006 6) and problem resolution (IEC 62304:2006 9) send every field problem and change request back into the loop: each change is risk-assessed (IEC 62304:2006 7) and goes through the same development steps at its class. Configuration management (IEC 62304:2006 8) runs underneath all of it, so you can always say which version of which item, including every SOUP item, is in a given release.

Traceability is what an assessor follows. They pick a hazard from the risk file, find the requirement that controls it, the design item that implements it, the test that verifies it and the release that shipped it. A broken link anywhere on that chain is the first finding.

In this section

IEC 62304 is covered on this page; it has no sub-pages. The topics it depends on and feeds into have their own pages:

• ISO 13485 design and development: how design planning, reviews, verification and validation work for the device as a whole?
• ISO 13485 quality management system: what quality system must your software process sit inside?
• EU MDR classification: what class does Rule 11 give your software, and who assesses it?
• EU MDR technical documentation: where does your software evidence go in the file a notified body reviews?
• UKCA marking under UK MDR 2002: how does the same software evidence support a UKCA mark in Great Britain?
• IEC 62366-1: how do you engineer and evaluate the user interface your software presents?

How Sted maps it

IEC 62304 is one of the standards, regulations and schemes in Sted’s catalogue.

Sted treats it as mandatory when a product that is or contains software carries design responsibility under a device regulation that applies to you, or when a clinical investigation is planned or running. It carries forward the highest software safety class you recorded, and while the device regulation is still pending, so is IEC 62304. Those rules work from your recorded answers; the AI model does not decide them.

Sted recommends it with its reasons, and you select it or leave it. Administrators and Policy and Process Owners make that choice. Choosing it and pressing Update and generate framework builds the documents it needs.

For IEC 62304 Sted’s knowledge base carries the Software Development Lifecycle Procedure (PRC-SDLP), the Software Maintenance Procedure (PRC-SWMAINT) and their record templates, from the Software Development Plan (REC-SDP) to the SOUP Item Record (REC-SOUP) and the Software Release Record (REC-SR), over a 13-row process catalogue. The procedures are drafted for your organisation for you to review and approve, and each record template gives your evidence a fixed shape. The software risk work sits in the medical device risk management plan and file under the Risk Management Procedure. Because the standard has a catalogue, adopting it also gives you a Statement of Applicability for its 13 process rows, where you can mark a row excluded with a reason, such as detailed design for a class A product. See Records, Documents and Classification and applicability for how they work in StedOS.

Sted does not assign your safety class, review your code or test your software. It holds the procedures, plans and records an assessor samples, as documented information under your own document control.

Frequently asked questions