IEC 62304 — Medical Device Software Lifecycle Processes

Why does it matter?

Establishing the safety and effectiveness of a medical device that contains software means showing that the software does what it is meant to do without causing unacceptable risk. The Introduction also notes that many field incidents relate to service or maintenance, including inappropriate software updates, so IEC 62304 treats maintenance as seriously as development.

Key benefits include:

• Effort scaled to risk

Clause 4.3 assigns each software system a safety class, and compliance is defined by class (1.4), so a low-risk component carries a lighter documentation load than a high-risk one.

• One risk process

ISO 14971 is the normative reference for risk management, and clause 7 adds the software-specific steps inside the device risk management process.

• Maintenance held to the same standard

Clause 6 requires a maintenance plan (6.1), problem and modification analysis (6.2) and controlled modification (6.3).

• Controlled change and problem handling

Clause 8 covers configuration identification, change control and status accounting, and clause 9 sets eight steps for software problem resolution.

• Recognized by regulators

The FDA's June 2023 premarket software guidance lets a sponsor declare conformity to named clauses of the FDA-recognized version of IEC 62304, including 5.1.1 to 5.1.3, clause 6 and clause 8.

How does it work?

The standard has nine clauses followed by four informative annexes. Clause 1 gives the scope and the compliance rule, clause 2 the normative reference (ISO 14971), clause 3 the terms, and clause 4 the general requirements: quality management system (4.1), risk management (4.2), software safety classification (4.3) and legacy software (4.4).

Clause 5 sets out eight development activities: planning (5.1), requirements analysis (5.2), architectural design (5.3), detailed design (5.4), unit implementation and verification (5.5), integration and integration testing (5.6), system testing (5.7) and release (5.8). Clause 6 reuses several of them for maintenance.

Annex A gives the rationale, Annex B guidance on each provision, Annex C the relationship to other standards, and Annex D implementation help, including a checklist for small companies without a certified quality management system (Table D.1). Table A.1 summarizes the requirements by software safety class.

Key Elements

• Software safety classification (4.3)

The manufacturer assigns a safety class of A, B or C by the possible effect on the patient, operator or others of a hazard to which the software contributes. Class A means no injury is possible, B non-serious injury, and C death or serious injury. Amendment 1 made the classification risk-based.

• Development process (clause 5)

Planning must cover, among other things, verification, risk management, documentation and configuration management (5.1.6 to 5.1.9). Later activities build requirements, architecture, detailed design, unit verification, integration and system testing.

• Maintenance process (clause 6)

The manufacturer establishes a maintenance plan, analyzes each problem report or modification request, and implements modifications using the development activities.

• Software risk management (clause 7)

Clause 7 has four parts: analysis of software contributing to hazardous situations (7.1), risk control measures (7.2), verification of risk control measures (7.3) and risk management of software changes (7.4).

• Configuration and problem resolution (clauses 8 and 9)

Clause 8.1.2 deals with software of unknown provenance. Clause 9 covers problem reports (9.1) through trend analysis (9.6) and verification of the resolution (9.7).

• Legacy software (4.4)

Amendment 1 added requirements for legacy software, meaning software whose design predates the current version of the standard, to help manufacturers show compliance to meet European Directives.

What does it cover?

IEC 62304 applies to the development and maintenance of medical device software, whether the software is itself a medical device or an embedded or integral part of one (1.2). It applies regardless of the storage device or delivery method used. It does not cover validation and final release of the medical device, even for a device that is entirely software; those system-level activities are found in related product standards such as IEC 60601-1 and IEC 82304-1.

What are its objectives?

Clause 1.1 states the purpose, and the Introduction adds the design intent.

Define the life cycle requirements for medical device software and give a common framework of processes, activities and tasks.

Embed software risk management in the device risk management process under ISO 14971.

Keep software maintenance and updates under the same discipline as development.

Add configuration management and problem resolution as processes essential to safe software.

Leave the choice of life cycle model, organization and documentation format to the manufacturer.

Framework in Context

IEC 62304 is used with other device standards, and Annex C relates it to ISO 13485, ISO 14971, IEC 60601-1 and ISO/IEC 12207 (Tables C.1 to C.5). In the United States the FDA accepts a declaration of conformity to the FDA-recognized version for parts of a premarket submission, and 21 CFR Part 820 now incorporates ISO 13485:2016 by reference (89 FR 7496, effective 2 February 2026). EN 62304 does not appear on the European Commission's summary list of harmonized standards under Regulation (EU) 2017/745 generated 17 June 2026. The IEC shows an Edition 2.0 project in preparation.

Common Framework Mappings

IEC 62304 is often mapped to other medical device, quality, and information security frameworks to ensure lifecycle control, regulatory compliance, and harmonization across software development and cybersecurity requirements.

Mapped frameworks include:

FDA 21 CFR Part 820

IEC 60601-1

IEC 81001-5-1

ISO 13485:2016

ISO 14971:2019

ISO 27001

ISO 27018

NIST CSF 2.0

IEC 62366-1