What Is IEC 62304? Medical Software Guide

Audit week rarely goes smoothly for medical device software teams. Engineers spend days reconciling requirements against tests, chasing down Software of Unknown Provenance (SOUP) version records, and justifying a safety class nobody wrote a rationale for when it was assigned. IEC 62304 exists to prevent that scramble by building lifecycle evidence into daily development instead of gathering it after the fact.

Real auditors have to sign off on that evidence. The United States (US) Food and Drug Administration (FDA) and European Union (EU) notified bodies both evaluate medical device software against IEC 62304’s lifecycle processes today, and documentation expectations may broaden once the draft Edition 2 revision replaces the three-class safety model.

This guide covers who falls in scope, the companion standards IEC 62304 relies on, the lifecycle activities each safety class requires, and what changes once Edition 2 is finalized.

What Is IEC 62304?

IEC 62304, formally titled Medical device software: Software life cycle processes, defines lifecycle requirements for software that is a medical device or is embedded in one. It sets minimum requirements across development, maintenance, risk management, configuration management, and problem resolution.

Two things IEC 62304 does not cover are device validation and organizational certification. ISO 13485 supplies the certification framework instead, and design validation activities sit under the manufacturer’s broader quality management system, not IEC 62304 itself. Compliance is shown through technical documentation that the FDA or a European notified body evaluates during submissions and audits, not through a certificate issued for the standard itself.

The standard treats software failure as a design problem to plan for, not an edge case to react to, and the eight Clause 5 development activities scale with how much harm a failure could cause rather than how likely the manufacturer thinks it is.

Who Needs to Comply with IEC 62304, and What Standards Come With It?

Any manufacturer whose software is itself a medical device, or is embedded in one, falls in scope. IEC 62304 also operates with companion standards.

Software as a Medical Device (SaMD) and Software in a Medical Device (SiMD)

Under IEC 62304, SaMD performs one or more medical purposes without being part of a hardware medical device, as with a diagnostic mobile app or cloud-hosted analysis tool. Software embedded in or integral to hardware, such as insulin pump firmware or ventilator monitoring logic, falls under SiMD. Manufacturing or service software, such as test tooling or source code management, is out of scope.

Companion Standards for Risk and Quality Management

IEC 62304 makes a normative reference to the ISO risk management standard, ISO 14971, which connects system-level risk management to daily software development. ISO 13485 supplies the quality management system (QMS) framework, and design and development requirements, including the file most teams still call the design history file, come from ISO 13485 Clause 7.3 and the FDA’s Quality Management System Regulation (QMSR).

IEC 81001-5-1 and IEC 82304-1 for Health Software and Cybersecurity

For standalone health software, IEC 82304-1 provides a product safety standard that relies on IEC 62304 for development. IEC 81001-5-1 adds cybersecurity requirements across the software lifecycle and entered the FDA-recognized standards database in December 2022. Manufacturers can use it as a Secure Product Development Framework under the FDA’s premarket cybersecurity guidance.

US and Other National Adoptions

In the US, the identical national adoption, American National Standards Institute (ANSI)/Association for the Advancement of Medical Instrumentation (AAMI)/IEC 62304 2006 with A1 2016, is published through AAMI, and IEC 62304 Edition 1.1 is listed among FDA recognized consensus standards under recognition number 13-79. In Europe, EN 62304 2006 with A1 2015 is harmonized under the Medical Device Regulation (MDR) and In Vitro Diagnostic Regulation (IVDR), and conforming manufacturers receive a presumption of conformity.

IEC 62304 Terminology and Concepts

The standard’s vocabulary shapes how architecture and risk documentation get organized, and teams should use these terms precisely and consistently.

Software Items and the Three-Level Hierarchy

IEC 62304 organizes software as an integrated software system: a collection of software items arranged to accomplish a function or set of functions. Software items are identifiable parts of a computer program, while software units are items that are not subdivided further. Manufacturers decide where decomposition stops, and units can be logical constructs or physical artifacts. One device can contain more than one software system.

Safety Requirements and Hazard Classification

IEC 62304 classifies software by the potential harm a failure could cause, not by how likely that failure seems, and that classification stays anchored to the ISO 14971 risk analysis rather than to an independent probability estimate.

Software of Unknown Provenance (SOUP)

SOUP covers software already developed and generally available that wasn’t built for incorporation into the medical device, including operating systems, drivers, and third-party libraries, along with previously developed software lacking adequate process records. A manufacturer shouldn’t declare its own medical device software system to be SOUP, and the term isn’t interchangeable with the FDA’s Off-the-Shelf (OTS) software category.

SOUP obligations run through the lifecycle. Teams should identify each item in the architecture, document requirements and prerequisites, feed published anomaly lists into risk analysis, and monitor components after release for new anomalies and security vulnerabilities.

The IEC 62304 Software Development Lifecycle

Clause 5 defines eight development activities, and the assigned safety class determines which ones apply. Traceability is planned before development starts and verified at each later stage.

Planning and Requirements Analysis

The Software Development Plan must exist before development starts and stay current throughout. It covers deliverables and problem resolution, defines configuration and change management including SOUP, and explains how system requirements, software requirements, system tests, and risk controls will stay linked. Requirements analysis then produces a Software Requirements Specification whose entries must be unambiguous, verifiable, testable, and consistent with system requirements.

Architectural and Detailed Design

Architectural design, required for Classes B and C, identifies software items and units, specifies interfaces, and documents the requirements and prerequisites for each SOUP component. Detailed design, required only for Class C, refines architectural elements into units a developer can implement directly.

Implementation, Verification, and Testing

Unit verification establishes acceptance criteria such as event sequences, fault handling, memory management, and boundary conditions. Integration testing exercises data and control transfer across internal and external interfaces, with test documentation traced back to the architecture. System testing verifies integrated software against all requirements, while release requires a documented list of unresolved anomalies with risk justification.

IEC 62304 Software Safety Classification (Classes A, B, and C)

Manufacturers scale IEC 62304 rigor by assigning each software item to a safety class. An unjustified assignment can draw scrutiny during audits because the class determines required lifecycle evidence.

How Safety Classes Are Determined

Classification depends on the severity of harm a software failure could cause. Class A applies when software can’t contribute to a hazardous situation, or when external risk controls make the risk acceptable. Class B covers software that can lead to a hazardous situation without serious injury, and Class C covers software that can lead to serious injury or death.

External hardware risk controls can lower the class, but user information such as training or warnings in the manual can’t. Each software item is classified individually, the highest class of any item sets the class of the system, and an undocumented classification defaults to Class C.

What Each Safety Class Requires

Clause 5 mandatory activities change by class. The differences concentrate in architecture and design evidence, and in whether unit verification is required at all.

Lifecycle Activity	Class A	Class B	Class C
Development planning	Required	Required	Required
Requirements analysis	Required	Required	Required
Architectural design	Not required	Required	Required
Detailed design	Not required	Not required	Required
Software unit implementation	Required	Required	Required
Software unit verification	Not required	Required	Required
Integration testing	Not required	Required	Required
System testing	Required	Required	Required
Software release	Required	Required	Required

What separates B from C is chiefly detailed design, plus the additional unit acceptance criteria Class C carries. Edition 2 removes that distinction entirely.

The Four Supporting Processes Beyond Clause 5

Four additional lifecycle processes support software development: software maintenance, software risk management, software configuration management, and software problem resolution.

• Software maintenance: Establish and maintain a software maintenance plan, evaluate feedback and modification requests, analyze the impact of proposed changes, and implement and verify approved modifications.

• Software risk management: Identify how software items, including failing SOUP components, could contribute to hazardous situations, and verify the risk controls implemented in software.

• Software configuration management: Control versions and changes for every software item, including SOUP components.

• Software problem resolution: Investigate reported problems, assess their safety impact, and carry corrections through re-verification. Post-release changes need the same documented impact analysis.

These four processes generate the audit trail auditors expect to see connected to the classification and lifecycle activities above.

What’s Changing in IEC 62304 Edition 2?

Edition 2 remains in draft form, and publication timing is still subject to final IEC scheduling.

From Three Safety Classes to Two Process Rigor Levels

The current draft replaces Classes A, B, and C with two process rigor levels:

• Level I: Roughly matches the old Class A, applying when product-level risk analysis shows the software can’t contribute to a hazardous situation.

• Level II: Covers the rest, so former Class B steps up to the documentation and verification depth once reserved for Class C.

• Terminology shift: Drops hazardous situation language in favor of harm, aligning with ISO 14971.

• Broader scope: Extends from medical device software to health software generally.

• Reference changes: Removes ISO 13485 and ISO 14971 as normative references.

• New annex: Adds an informative agile annex based on AAMI TIR45 2023.

New Provisions for Artificial Intelligence (AI) and Machine Learning Software

A new planning clause requires manufacturers to plan for devices using AI, including decision trees, machine learning, deep learning, reinforcement learning, and large language models. The requirement applies at both rigor levels and addresses data management, model training, change control, and post-deployment monitoring, held to one normative clause plus an informative annex. Teams building this planning process can also look to established practices for AI and machine learning in medical device and life sciences development.

Common IEC 62304 Compliance Challenges

Audit findings against IEC 62304 often cluster in four areas, and each can grow worse as a product ages:

• Broken trace links: Requirements without a linked test, or tests without a linked requirement, surface at integration and system testing.

• Missing SOUP documentation: Each third-party library typically needs version information, known anomalies, and a record of its role in the system.

• Insufficient change control: Bug fixes, enhancements, and cybersecurity updates need impact analysis with risk assessment and verification evidence.

• Unjustified safety classification: A class assigned without documented reasoning invites questions, especially when software hazards don’t connect to the ISO 14971 risk file.

When trace links and SOUP records live apart from risk items, evidence gets assembled retroactively, and each reconstruction introduces inconsistencies.

How Jama Connect Supports IEC 62304

Jama Connect® is a requirements management and traceability platform with a pre-built medical device framework aligned to IEC 62304, ISO 14971, ISO 13485, and FDA QMSR. Its SaMD framework includes ISO-aligned document templates and customization capabilities for software lifecycle documentation.

Live Traceability™ keeps requirements, risk records, design outputs, and test cases connected as requirements or designs change. For review evidence, Jama Connect supports structured review workflows with audit trails and FDA 21 Code of Federal Regulations (CFR) Part 11 electronic signatures. TÜV SÜD has validated Jama Connect as a software tool for medical device development according to IEC 62304.

Jama Connect maps directly to the challenges above. Live Traceability™ keeps requirements, risk items, and tests linked as they change, so a missing link surfaces when it is created rather than at audit. The SaMD framework’s document templates support SOUP documentation with a consistent record for each third-party component. Structured review workflows and audit trails strengthen change control by capturing impact analysis and verification evidence at each revision. And because classification decisions live alongside the risk record, safety classification stays tied to documented rationale instead of an isolated judgment call.

Make IEC 62304 Evidence Part of Daily Work

The Edition 2 transition will reward teams that generate lifecycle evidence during development instead of treating it as a pre-audit deliverable. A former Class B team facing Level II documentation depth will feel the step up hardest if its trace matrix and risk file get rebuilt by hand at each milestone.

If your engineers spend the week before every audit reconciling requirements with tests and risk items across documents, it may be time to make lifecycle evidence part of daily workflow. You can start a free 30-day trial to see how connected traceability works in Jama Connect.

Frequently Asked Questions About IEC 62304

Is IEC 62304 certification mandatory?

No formal IEC 62304 certification exists for manufacturers, unlike ISO 13485. Submissions and audits usually include a development plan, requirements, required architecture, verification records, traceability, SOUP records, unresolved anomaly assessment, and maintenance evidence, each mapped to the assigned safety class. Compliance audits tend to check whether that mapping is documented, not just whether the artifacts exist.

What is the difference between IEC 62304 and IEC 82304-1?

IEC 62304 covers embedded and standalone medical software as a process standard, while IEC 82304-1 sets product safety requirements for standalone health software only. IEC 82304-1 matters when a standalone product needs product-level validation beyond IEC 62304’s lifecycle evidence, and teams often evaluate it for health software delivered outside a hardware device submission.

Does IEC 62304 support agile development methodologies?

Yes, because the standard mandates activities and outputs, not a methodology. Teams can use waterfall or agile/hybrid models as long as lifecycle activities are documented, and agile teams usually map backlog items, reviews, test evidence, and release decisions to IEC 62304 outputs. AAMI TIR45 2023 covers applying agile practices under FDA guidance and international standards, and it became an FDA-recognized consensus standard in May 2025.

Where can I find the latest version of IEC 62304?

The current version is the consolidated IEC 62304 Edition 1.1, which combines the 2006 standard and 2015 amendment. It is available through the IEC Webstore in electronic and hardcopy formats. US teams can purchase the identical ANSI/AAMI adoption through AAMI.

This article was authored by Tom Rish and published on August 20, 2026.