IEC 62304: Software Life Cycle Requirements for Medical Device Software

IEC 62304 is the international standard for the life cycle of medical device software. It tells manufacturers what processes they need to develop and maintain software safely, from planning and requirements through design, testing, release and post-market maintenance. It applies to software embedded in devices and to standalone software as a medical device (SaMD), such as diagnostic apps and clinical decision software.

Regulators rely on it heavily: the US FDA recognises it as a consensus standard, and in the EU it is harmonised for showing conformity with the Medical Device Regulation. The current version is Edition 1.1 (2006 with a 2015 amendment), and a second edition with a broader scope is in development. This guide explains safety classes, required processes, SOUP, documentation, regulatory use, agile adoption and what software partners need to know.

What is IEC 62304?

IEC 62304 defines life cycle requirements for medical device software, as a framework of processes, activities and tasks. It is process-based rather than prescribing specific methods, so manufacturers can use waterfall, iterative or agile approaches as long as the required outputs and controls exist. It works within a quality management system, typically ISO 13485, and with risk management according to ISO 14971.

The first edition was published in 2006. Amendment 1 in 2015 clarified software safety classification, added requirements for legacy software and updated several areas; the consolidated version is often called Edition 1.1. It is maintained jointly by the IEC subcommittee on medical electrical equipment software and the ISO committee responsible for medical device quality management, which is why it fits closely with ISO 13485 and ISO 14971.

Who should use it?

• Medical device manufacturers with software in or as their devices.
• Digital health companies building software that meets the definition of a medical device.
• Software development partners working under contract for manufacturers, who must follow the manufacturer's IEC 62304 processes or their own conforming ones.
• Notified bodies and regulators, who assess conformance.

Is it mandatory or voluntary?

Voluntary in principle, but in practice expected. Regulators accept other approaches only if they provide equivalent assurance, which is difficult to argue. For FDA submissions, manufacturers can declare conformance to the recognised standard. Under the EU MDR, applying the harmonised standard gives a presumption of conformity with relevant software requirements.

Is my software a medical device?

IEC 62304 applies when software is a medical device or part of one, so the first question is regulatory. In the US, software functions intended to diagnose, cure, mitigate, treat or prevent disease can be device software functions, while FDA has said it does not intend to focus oversight on certain low-risk wellness and administrative functions, and some clinical decision support software is excluded from the device definition if it meets statutory criteria. In the EU, software intended by its manufacturer for medical purposes is a medical device, and the MDR's Rule 11 classifies many decision support and monitoring apps as Class IIa or higher. Hospital administration, scheduling and billing systems are usually not medical devices, though they may still face other rules such as HIPAA and the Cures Act. Get a clear regulatory determination before deciding the development approach.

Software safety classification

Class	Definition	Effect on requirements
Class A	No injury or damage to health is possible.	Fewest requirements.
Class B	Non-serious injury is possible.	More documentation, architecture and testing requirements.
Class C	Death or serious injury is possible.	Full requirements, including detailed design and unit-level verification.

Classification considers the hazards the software could contribute to and the risk control measures external to the software. Amendment 1 clarified that classification is based on the severity of possible harm after considering external risk controls, not on probability of software failure. Software systems can be divided into items with different classes if the architecture provides adequate segregation.

The required processes

• Software development process: development planning, requirements analysis, architectural design, detailed design, unit implementation and verification, integration and integration testing, system testing, and release.
• Software maintenance process: maintenance planning, problem and modification analysis, and implementing modifications after release.
• Software risk management process: identifying software contributions to hazardous situations, defining and verifying risk control measures, and managing risks from changes, integrated with ISO 14971.
• Software configuration management process: identifying configuration items, controlling changes and recording status.
• Software problem resolution process: documenting, investigating and resolving problems, and analysing trends.

Requirements scale with safety class: for example, detailed design and unit verification are required for Class C but not Class A.

SOUP: software of unknown provenance

Most medical software uses third-party components such as operating systems, libraries and frameworks. IEC 62304 calls these SOUP. Manufacturers must identify each SOUP item and version, specify functional and performance requirements for it, specify the hardware and software it needs, evaluate known anomalies and their risk, and monitor for new issues. A well-maintained software bill of materials and vulnerability monitoring make this manageable, and they also support cybersecurity expectations from regulators.

Documentation regulators expect

• Software development plan and maintenance plan.
• Software safety classification rationale.
• Software requirements specification with traceability to system requirements and risk controls.
• Software architecture, and detailed design for Class C items.
• Verification plans and results at unit, integration and system levels as required.
• SOUP list with requirements and anomaly evaluations.
• Risk management file entries for software.
• Configuration management records and release documentation, including known residual anomalies.
• Problem reports and change records.

Using IEC 62304 with FDA and the EU MDR

In the US, FDA's guidance on the content of premarket submissions for device software functions sets documentation levels based on risk, and conformance to IEC 62304 supports the software documentation in a submission. FDA also expects cybersecurity documentation for devices with connectivity, including an SBOM, under its premarket cybersecurity guidance and the statutory requirements for cyber devices. In the EU, the MDR's general safety and performance requirements require software to be developed according to the state of the art, taking into account the development life cycle, risk management, verification and validation, which is where IEC 62304 applies, alongside IEC 82304-1 for health software products and the MDR's cybersecurity guidance.

Cybersecurity for medical device software

IEC 62304 addresses security only indirectly, through risk management and SOUP, but regulators now expect much more. FDA requires manufacturers of cyber devices to submit cybersecurity plans, design devices with security controls, provide an SBOM and maintain processes to address vulnerabilities after release. EU guidance under the MDR sets similar expectations. Manufacturers typically combine IEC 62304 with IEC 81001-5-1 for security activities in the health software life cycle, threat modelling, penetration testing and coordinated vulnerability disclosure. Security practices from ISO/IEC 27001 support the organisational side, especially for cloud-hosted SaMD.

Legacy software

Amendment 1 added a process for legacy software: software that was legally placed on the market before current standards were applied, and for which full documentation may not exist. Manufacturers can use a risk-based approach to assess the legacy software, considering post-market feedback, performing a gap analysis against IEC 62304, and closing gaps that affect safety, rather than recreating all historical documentation. Any changes to legacy software must then follow the full maintenance process.

Working with development partners

Manufacturers often outsource development, but they remain responsible for conformance. Contracts and quality agreements should specify which processes the partner follows, which tools are used for requirements, code, tests and traceability, how SOUP is managed, how defects and changes are reported, and how records are handed over. Partners experienced in regulated development can save time by working inside the manufacturer's quality system rather than producing separate documentation that later has to be reconciled. Audits of the partner's practices are a normal part of supplier control under quality management expectations and ISO 13485.

Agile development under IEC 62304

IEC 62304 does not prohibit agile. Many manufacturers use iterative sprints while maintaining the required outputs: a living development plan, requirements managed in a tool with traceability, architecture updated as the system evolves, automated unit and integration tests as verification evidence, definition of done that includes documentation and risk analysis, and controlled releases with full verification. The technical information report AAMI TIR45 gives practical guidance on applying agile in regulated medical software.

Edition 2

A second edition of IEC 62304 has been in development for several years. Published commentary indicates it will broaden the scope from medical device software to health software more generally, and replace the A, B and C safety classes with two levels of process rigour. As of mid-2026, sources differed on its stage and expected publication date, with some describing a further committee draft. Until a new edition is published and recognised by regulators, Edition 1.1 remains the reference. Manufacturers should track the revision and plan a transition once timelines are confirmed.

How to implement, step by step

1. Confirm the software is a medical device or part of one under applicable regulations.
2. Classify software safety with documented rationale linked to the risk analysis.
3. Write the development plan describing processes, tools, deliverables and how agile or other methods meet requirements.
4. Set up traceability from system requirements to software requirements, design, code, tests and risk controls.
5. Manage SOUP with an inventory and anomaly monitoring.
6. Verify at the levels required by safety class, automating where possible.
7. Control configuration and releases, documenting known anomalies.
8. Plan maintenance and problem resolution for post-market changes.

Post-market maintenance

Software does not stop changing after launch. Bug fixes, operating system updates, security patches and new features all go through the maintenance process: analysing the problem or change request, assessing its effect on safety and existing risk controls, implementing it under the development process requirements appropriate to the safety class, verifying it, and releasing it with updated documentation. Regulators may also require a new submission or notified body review for significant changes. Feedback from users, complaints and vulnerability reports should feed into problem resolution, with trends analysed to find recurring issues. For cloud-based SaMD with frequent releases, an efficient, automated maintenance pipeline is essential.

Timeline and cost considerations

For a new SaMD product, setting up IEC 62304 conformant processes and tooling typically takes weeks to a few months, with ongoing effort throughout development. Class C software requires significantly more design documentation and verification than Class A. Retrofitting documentation to existing software is costly and often requires redesign or extensive testing, which is why starting with the standard is recommended.

Common mistakes

• Classifying software too low without considering external risk controls properly.
• Missing traceability between requirements, risks and tests.
• Undocumented SOUP, including transitive dependencies.
• Development partners working outside the manufacturer's processes.
• Treating maintenance releases as uncontrolled hotfixes.
• Writing documents after the fact instead of as part of development.

Best practices, tools and technologies

• Use an application lifecycle management tool for requirements, risks and traceability.
• Automate tests and capture results as verification records.
• Generate SBOMs in the build and monitor vulnerabilities in SOUP.
• Use code review and static analysis as part of verification.
• Keep architecture documentation close to code and update it each release.

We work on regulated healthcare software with requirements traceability, documented architecture, automated verification and controlled releases through our healthcare and custom software development work.

How it relates to other standards

Standard or rule	Relationship
ISO 13485	Quality management system within which IEC 62304 processes operate.
ISO 14971	Risk management for medical devices, integrated with software risk management.
IEC 82304-1	Product-level requirements for health software products.
21 CFR Part 11	Electronic records and signatures for FDA-regulated records, relevant to quality systems.
SBOM	Component inventory supporting SOUP management and cybersecurity.

Real-world example

A European startup develops a Class IIa SaMD that analyses ECG data, with an Indian development partner. The startup classifies the software as Class B, writes a development plan describing two-week sprints, and requires the partner to use its requirements and traceability tool, automated unit and integration tests, and code review. The partner maintains a SOUP list generated from the build and monitors vulnerabilities. Each release includes verification results, known anomalies and traceability reports, which feed into the notified body review of the technical file.

Next steps

1. Confirm device status and safety class.
2. Write a development plan.
3. Set up traceability and SOUP management.
4. Automate verification.
5. Track Edition 2.

Frequently asked questions

What is IEC 62304?

The international standard defining software life cycle processes for medical device software.

Does IEC 62304 apply to standalone software?

Yes. It applies to software as a medical device as well as software embedded in devices.

What are the IEC 62304 safety classes?

Class A (no injury possible), Class B (non-serious injury possible) and Class C (death or serious injury possible).

Is IEC 62304 mandatory?

Not by law, but regulators expect it, and the FDA recognises it while the EU harmonises it under the MDR.

What is SOUP?

Software of unknown provenance: third-party components not developed under the manufacturer's IEC 62304 process, such as operating systems, open source libraries and commercial components.

Can agile be used with IEC 62304?

Yes, if required outputs, traceability and controls are maintained; AAMI TIR45 gives guidance.

What is the current version?

Edition 1.1, IEC 62304:2006 with Amendment 1:2015, which remains the version regulators recognise until a new edition is published and adopted.

What will Edition 2 change?

Commentary indicates a broader health software scope and two process rigour levels replacing classes A, B and C; publication timing was not settled as of October 2026.

Does IEC 62304 cover cybersecurity?

Only partly, through risk management and SOUP; regulators set separate cybersecurity expectations.

How does IEC 62304 relate to ISO 14971?

Software risk management under IEC 62304 is part of the overall device risk management under ISO 14971.

Can a development partner be responsible for IEC 62304?

The manufacturer remains responsible, but partners must follow conforming processes defined in contracts and quality agreements.