The authoritative reference

Back to Standards Stack for Medical Devices

StandardsSoftware Lifecycle Quality System

IEC 62304

Lifecycle requirements for medical device software.

Reviewed by Christian Espinosa, Founder, Blue Goat CyberLast reviewed September 19, 2026

Definition

IEC 62304:2006 (with Amendment 1:2015) defines the lifecycle requirements for medical device software, including software development planning, requirements analysis, architectural design, implementation, integration, testing, release, and maintenance - scaled by software safety classification (Class A, B, C). IEC 62304 assumes the manufacturer has a QMS (such as ISO 13485) and a risk management process (ISO 14971) in place. Its key processes are software development, maintenance, risk management, configuration management and problem resolution. It is recognized by FDA and harmonised under the EU MDR. A second edition has been in development for several years to broaden its scope to health software and update the classification approach.

What the regulation says

IEC 62304:2006, amended by Amendment 1:2015, sets lifecycle requirements for MedTech medical device software. It is a consensus standard, not legislation or a standalone approval pathway. FDA recognises IEC 62304 as a consensus standard; manufacturers should check the recognition entry for the accepted edition and any limitations. Use of recognised standards is generally voluntary. Separately, FDA's Quality Management System Regulation, effective 2 February 2026, requires manufacturers subject to 21 CFR 820.10 to maintain a quality management system meeting applicable ISO 13485:2016 requirements and additional FDA requirements. IEC 62304 supports software lifecycle controls within that broader system. Regulation (EU) 2017/745, adopted on 5 April 2017 and generally applicable from 26 May 2021, requires software development to reflect lifecycle, risk management, information security, verification and validation principles under Annex I, Section 17.2. Article 8 provides a presumption of conformity only for requirements covered by harmonised standards whose references are published in the EU Official Journal. IEC publication alone does not establish MDR harmonisation. IEC 62304 safety classes A, B and C scale required lifecycle activities according to potential harm. Conformity to the standard does not replace device-level risk management, clinical evaluation or the applicable conformity assessment.

What this means in practice

IEC 62304 is a recognized consensus standard by FDA and a harmonized standard under EU MDR. It is foundational for SaMD and software-containing devices. The standard scales its expectations by software safety class: Class A (no injury possible) requires the lightest process, Class B (non-serious injury) adds detailed design and integration testing, and Class C (death or serious injury) adds unit testing, more rigorous architecture, and stronger SOUP controls.

Examples

A Class C infusion pump control application with unit tests, formal architectural design records, and full SOUP evaluation for the RTOS and TLS stack.
A Class B mobile SaMD dose calculator with documented software requirements, integration tests, and a maintained anomaly list.

Use cases

1 scenario

1

Legacy infusion pump firmware refresh

Software lead

A team refactoring 10-year-old C firmware classifies the safety class as C, retrofits a software development plan, traces requirements to unit tests, and documents SOUP for the RTOS and TCP/IP stack.

OutcomeThe refresh ships with full IEC 62304 evidence, satisfying both 510(k) reviewers and an EU MDR notified body.

Common pitfalls

•Under-classifying software to avoid Class C obligations. Auditors and reviewers actively challenge classifications that do not align with the device's hazard analysis.
•Skipping SOUP (Software of Unknown Provenance) requirements for open-source libraries and third-party components.
•Treating IEC 62304 as an alternative to ISO 14971. It complements risk management; it does not replace it.
•Losing traceability between software requirements, architecture items, unit tests, and integration tests.

Frequently asked questions

Class A: no injury or damage to health is possible. Class B: non-serious injury is possible. Class C: death or serious injury is possible. The class is set based on the hazard analysis and may be reduced by external risk controls (hardware safeguards, alarms, procedural controls).

Cross-references

Governs

Things this term applies rules or requirements to.

Uses

Concepts or artefacts this term builds on.

Grouped by theme

Editor's picks

· Hand-selected related concepts

Software Safety Classification

IEC 62304 classes A, B, C reflecting potential harm from software failure.

Software as a Medical Device(SaMD)

Software intended for medical purposes that performs without being part of a hardware device.

Software of Unknown Provenance(SOUP)

Software not developed for medical device use, or lacking adequate development records, incorporated into a device.

International standard for the application of risk management to medical devices.

SaMD & AI/ML Devices

· From this learning path

Software in a Medical Device(SiMD)

Software embedded in or required to operate a hardware medical device.

Adjacent lesson

Clinical Decision Support(CDS)

Software providing healthcare professionals with knowledge and patient-specific information.

Predetermined Change Control Plan(PCCP)

FDA mechanism to pre-authorize specific modifications to AI/ML-enabled devices.

Good Machine Learning Practice(GMLP)

Guiding principles for the development of AI/ML-enabled medical devices.

Standards Stack for Medical Devices

· From this learning path

International standard defining secure-product-lifecycle activities for health software, including medical devices.

EMC requirements for medical electrical equipment.

Adjacent lesson

Application of usability engineering to medical devices.

Adjacent lesson

General requirements for basic safety and essential performance of medical electrical equipment.

Software Team Onboarding

· From this learning path

Section 524B of the FD&C Act(524B)

The federal statute that gives FDA explicit premarket authority over cybersecurity for cyber devices.

Secure Product Development Framework(SPDF)

A documented, risk-based set of processes that build cybersecurity into a medical device across its full lifecycle.

Software Bill of Materials(SBOM)

A machine-readable inventory of all software components, including open-source and third-party libraries, used to build a medical device.

Threat Modeling

A structured analysis that identifies how an attacker could compromise a medical device and what controls mitigate each threat.

Cited by

Where this term appears across MedTech Terms.

Learning paths (3)

SaMD & AI/ML DevicesLesson 3 of 9
Standards Stack for Medical DevicesLesson 5 of 10
Software Team OnboardingLesson 3 of 12

Ecosystems (2)

Comparisons (1)

IEC 62304 vs ISO 14971vs ISO 14971

Latest in MedTech

Sources

3 sources

Every citation below opens the original document. Each is graded against our source-tier hierarchy so you can see what rests on binding law versus commentary.

Tier 1Binding law and standards· 2Tier 2Regulator guidance and consensus· 1

Link health: 2 verified 1 unchecked· last checked 2026-06-20

ISO·1FDA·1IEC·1

Inline markers like [1] jump to the matching reference above.

My progress

All terms0 / 513

Standards0 / 25

Saved on this device, and to your account when signed in. View studied terms

Browse all terms A to Z, each with a short definition.

On this term

Category: Standards
Sources: 3
Use cases: 1
Updated: 9/19/2026

Compare with another term

Learn in 60 seconds

Lifecycle requirements for medical device software.

·IEC 62304 is a recognized consensus standard by FDA and a harmonized standard under EU MDR.
·It is foundational for SaMD and software-containing devices.
·IEC 62304 assumes the manufacturer has a QMS (such as ISO 13485) and a risk management process (ISO 14971) in place.

Remember this

Watch out: Under-classifying software to avoid Class C obligations. Auditors and reviewers actively challenge classifications that do not align with the device's hazard analysis.

Related terms

You may also need

Auto-suggested from Standards and shared keywords.

All Standards terms

From the Blue Goat network

Related resources and services on this topic.