What Is IEC 62304? A Guide to Medical Device Software

If your medical device software needs to ship in both the United States (US) and the European Union (EU), you need one lifecycle standard that regulators on both sides already accept. IEC 62304 is that standard. It tells software teams which development activities, documents, and traceability steps are required from planning through release and maintenance, and it scales those requirements to match the risk your software poses to patients, so lower-risk products carry lighter documentation burdens.

This guide covers IEC 62304’s safety classification system, the software development lifecycle it defines, key supporting processes for maintenance and risk management, and the changes coming in Edition 2.

What Is IEC 62304?

IEC 62304 is the international standard for medical device software lifecycle processes. The US Food and Drug Administration (FDA) recognizes it as a consensus standard, and the EU accepts it as EN 62304 under the Medical Device Regulation. That dual recognition makes it the go-to lifecycle standard for teams building medical device software that needs to ship in both markets.

IEC 62304 is a process standard, not a product standard. It does not specify what your software must do. Instead, it specifies which lifecycle activities and documentation are required without prescribing a specific methodology. Teams that follow it consistently produce higher-quality software, catch safety issues earlier in development, and move through regulatory submissions faster because the documentation and traceability are already in place.

What Software Does IEC 62304 Cover?

The standard applies to software that is itself a medical device or that is embedded in one. Three categories help you figure out where your product fits:

• Software as a medical device (SaMD): Standalone software that performs a medical purpose without being part of a hardware device. Clinical decision support tools and diagnostic imaging analysis software are common examples.
• Software in a medical device (SiMD): Software embedded in or integral to a hardware medical device, like the firmware controlling an insulin pump or the monitoring logic inside a patient ventilator.
• Production and manufacturing software: Software used to manufacture or maintain medical devices. IEC 62304 does not cover this category directly, though separate regulatory requirements may apply.

Your software’s category determines whether IEC 62304 applies and which clauses are relevant. You can use IEC 62304 conformity to support FDA premarket submissions, and in the EU it gives you a presumption of conformity under the Medical Device Regulation.

Related Standards

IEC 62304 does not work in isolation. Most teams implement it alongside a small set of companion standards that cover risk, quality, and cybersecurity:

• ISO 14971 (risk management): Covers how you identify and control the risks your device creates. IEC 62304 references it directly, and the two are always used together.
• ISO 13485 (quality management): Provides the quality system that IEC 62304 sits inside. It also covers device-level validation and final release, which IEC 62304 does not handle on its own.
• IEC 81001-5-1 (cybersecurity): Addresses cybersecurity for health software using a lifecycle structure similar to IEC 62304. Regulators increasingly expect cybersecurity evidence alongside safety documentation.

Most teams treat these as one integrated compliance effort rather than three separate documentation exercises.

Key Concepts and Terminology

Three following concepts run through every compliance decision you will make under IEC 62304.

Software Items and the Three-Level Hierarchy

IEC 62304 breaks software into three levels. A software system is the complete collection of items that meet user needs. A software item is any identifiable part of that system, like a module or subsystem. A software unit is the lowest testable element, not broken down any further. This hierarchy lets teams focus their development and testing effort on the components most likely to affect patient safety.

Safety Requirements and Hazard Classification

Safety requirements in IEC 62304 come from ISO 14971 risk analysis outputs. The standard classifies software based on whether it can contribute to a hazardous situation and, if so, the severity of potential harm after applying risk controls outside the software. That severity drives which safety class applies (these are covered in detail below).

Software of Unknown Provenance (SOUP)

Software of Unknown Provenance (SOUP) is any software item that was not developed specifically for your medical device, or for which adequate development records are not available. Operating systems, open-source libraries, third-party networking stacks, and cloud service APIs all count. IEC 62304 requires you to document and assess every piece of SOUP as part of the software lifecycle. Requirements traceability helps teams manage SOUP documentation alongside other lifecycle artifacts.

The IEC 62304 Software Development Lifecycle

IEC 62304 Clause 5 defines eight activity areas, starting with planning and ending with release. The specific activities required in each phase scale with the assigned software safety class.

Planning and Requirements Analysis

Clause 5.1 (software development planning) sets the foundation. It documents which lifecycle model you are using, your safety class assignments, and how risk management integrates with development. Clause 5.2 (software requirements analysis) then turns system-level requirements and risk outputs into specific, verifiable software requirements. For Class C software, the plan must also include a traceability methodology linking software requirements back to system requirements.

Architectural and Detailed Design

Clause 5.3 (architectural design) breaks the software system into defined items with specified interfaces, and it is required for Class B and C software. Clause 5.4 (detailed design) goes deeper, specifying algorithms, data structures, error handling, and timing constraints at the unit level. Only Class C software requires this step. If detailed design surfaces new risks, you need to update the risk management file before moving to implementation.

Implementation, Verification, and Testing

Clause 5.5 (unit implementation and verification) covers coding and unit-level testing. Class C requires full verification with documented results.

Clause 5.6 (integration testing) combines individually verified units and tests their interactions against the architectural design. Clause 5.7 (system testing) tests the complete software system against the Software Requirements Specification and is required for all safety classes.

Finally, Clause 5.8 (software release) confirms that all planned activities are complete, all items are at the correct version, and all known anomalies have been evaluated for release acceptability.

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

IEC 62304 assigns one of three safety classes to each software item based on the severity of potential harm. The assigned class determines the rigor of documentation, design, and verification activities required.

How Safety Classes Are Determined

Classification answers two questions. First, can the software contribute to a hazardous situation? If not, the software is Class A. If it can, the next question is how severe the harm could be after applying risk controls outside the software. Non-serious injury maps to Class B. Serious injury or death maps to Class C. When classification is not clearly justified, teams typically default to the more rigorous class.

One thing worth knowing is that software safety classes are separate from regional device classifications. An EU MDR Class I device can still contain Class C software.

What Each Class Requires

The table below shows exactly which lifecycle activities are required for each safety class. Class A carries the lightest burden, while Class C requires the full set of development, design, and verification activities.

Notice that risk management, configuration management, and problem resolution apply to every class. These are not optional processes you can skip for lower-risk software.

Risk Management, Configuration, and Maintenance Under IEC 62304

Unlike the development activities in Clause 5, which follow a general sequence from planning through release, these four processes run in the background the entire time. They need to be active from day one and stay active through every phase, including after the product ships:

• Risk management (Clause 7): Builds on your ISO 14971 risk analysis by adding software-specific requirements for how your code can contribute to system-level hazards. You’ll update this throughout development as new risks surface.
• Configuration management (Clause 8): Requires version control and change tracking for everything you produce: requirements, design documents, source code, test scripts, and build files.
• Software maintenance (Clause 6): Covers what happens after release. You need a maintenance plan that documents how your team handles problem reports, re-verification, and re-release.
• Problem resolution (Clause 9): Defines how you track anomalies from discovery through verified resolution. This maps closely to the Corrective and Preventive Action (CAPA) process that most QA teams already run under ISO 13485.

All four of these apply to every safety class, including Class A.

What’s Changing in IEC 62304 Edition 2

IEC 62304 is undergoing a major revision for Edition 2, with publication currently targeted for mid-to-late 2026. Two proposed changes are particularly relevant for teams planning ahead.

From Three Safety Classes to Two Process Rigor Levels

A proposed change replaces the three safety classes with two process rigor levels. Level I replaces Class A, and Level II replaces both Class B and Class C. Software that implements a risk control measure would be assigned Level II regardless of external controls, which addresses concerns about teams inappropriately downgrading their classification. Edition 2 also expands its scope from “medical device software” to “health software.”

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

Edition 2 introduces AI planning requirements that apply to both rigor levels, though the clause covers planning activities only. Technical verification and validation (V&V) requirements for AI and ML in medical devices are expected to come through additional guidance beyond Edition 2 itself.

Common IEC 62304 Compliance Challenges

Most teams run into the same friction points when implementing IEC 62304. These are the ones that come up most often:

• Agile vs. documentation: The standard doesn’t require waterfall, but you can’t substitute sprint artifacts for the documentation it asks for. AAMI TIR45 is the best reference for making agile work within IEC 62304.
• Keeping traceability current: Lifecycle traceability across requirements, design, tests, and risk items is required. Teams that treat it as a separate documentation task usually fall behind and end up scrambling before audits.
• Managing SOUP: As your product grows, so does the list of third-party libraries and open-source components you need to track. Each one needs version info, known issues, and a record of what it does in your system.
• Classification disagreements: Deciding whether software is Class A, B, or C involves judgment calls that engineering and regulatory teams may see differently. A documented rationale tied to your risk analysis avoids stalls later.

Addressing these challenges early in the project, ideally during development planning, prevents them from compounding as the product matures. Jama Connect® is a requirements management and traceability platform that helps teams manage several of these by keeping trace links, SOUP documentation, and risk items connected in a single record, so traceability doesn’t become a separate cleanup effort before each audit.

Key Compliance Deliverables

Teams preparing for an audit or regulatory submission should expect to produce and maintain these core documents throughout the lifecycle:

• Software Development Plan: Defines the lifecycle model, safety class assignments, tools, methods, and how risk management integrates with development activities.
• Software Requirements Specification: Captures all functional, performance, and safety requirements derived from system-level inputs and risk analysis outputs.
• Architecture Design Document: Describes how the software system is decomposed into items and units, including interfaces, data flows, and SOUP dependencies.
• Test Plans and Reports: Covers unit verification, integration testing, and system testing, with documented results and pass/fail criteria tied back to requirements.
• Risk Management File: Contains the complete risk analysis, evaluation, and control record required by ISO 14971, linked to specific software items and safety classes.
• SOUP List: Documents every piece of software of unknown provenance, including version, manufacturer, known anomalies, and functional requirements the SOUP fulfills.
• Software Release Documentation: Confirms that all planned lifecycle activities are complete, all items are at the correct version, and all known anomalies have been evaluated for release acceptability.

The exact depth of each document scales with your safety class, but auditors expect to see all seven regardless of classification.

Turning IEC 62304 Compliance Into a Daily Workflow

IEC 62304 compliance tends to break down when traceability from user needs through software requirements, architecture, implementation, and verification lives in spreadsheets and disconnected tools. Gaps appear quietly and surface at the worst time: during an FDA submission or notified body audit.

Jama Connect links software requirements to risk items, SOUP documentation, design artifacts, and verification evidence in a single traceable record. When a requirement changes, downstream items are flagged so your team can evaluate the impact before it reaches testing. If you are preparing for a medical device software submission and traceability gaps are still a manual effort, start a free 30-day trial.

Frequently Asked Questions About IEC 62304

Is IEC 62304 certification mandatory?

There is no official “IEC 62304 certificate” issued by the FDA, the European Medicines Agency (EMA), or the UK Medicines and Healthcare products Regulatory Agency (MHRA). Third-party organizations like TUV SUD may certify certain software tools or validations against IEC 62304. Most medical device software teams implement IEC 62304 because it provides a single standard accepted across major markets.

What is the difference between IEC 62304 and ISO 14971?

IEC 62304 tells you how to develop and document the software. ISO 14971 tells you how to identify and control the risks the software creates. You always use both together, but they approach probability differently: IEC 62304 classifies based on harm severity alone, while ISO 14971 factors in both probability and severity.

Does IEC 62304 support agile development methodologies?

Yes. Nothing in the standard requires waterfall or any specific sequence. The requirement is that you produce and maintain all the lifecycle outputs the standard calls for, regardless of how you organize your sprints. AAMI TIR45 is the go-to reference for mapping agile ceremonies and artifacts to IEC 62304 expectations.

How does IEC 62304 apply to SaMD?

IEC 62304 applies fully to SaMD, whether it runs on a smartphone, a browser, or a cloud server. One thing to watch is that standalone software often lacks hardware-based risk controls, which can push the classification toward Class B or C. Mobile health apps, cloud-hosted diagnostics, and any software that performs a medical function all fall under IEC 62304 as long as they qualify as SaMD.