IEC 62304 is the international standard that defines the software lifecycle processes for medical device software. It sets requirements for planning, development, maintenance, risk management, configuration management, and problem resolution, and assigns each software item a safety class (A, B, or C) that scales the required rigor to potential patient harm.
What is IEC 62304?
IEC 62304, titled “Medical device software, software life cycle processes,” is a process standard published jointly by the IEC and ISO. It applies whether the software is itself a medical device (Software as a Medical Device, or SaMD) or is embedded in a larger device (software in a medical device). The standard does not prescribe a specific development model, so waterfall, iterative, and Agile approaches all fit as long as the required processes, activities, and tasks are met.
The current in-force version is the consolidated edition 1.1, IEC 62304:2006/AMD1:2015, adopted in Europe as EN 62304:2006+A1:2015. A second edition is in development and expected to be published around 2026, but it is not yet an International Standard, and formal regulatory recognition usually lags publication by two to three years.
Why IEC 62304 matters in medical device development
Software failures in a regulated device can injure or kill patients, so regulators treat the development process itself as evidence of safety. IEC 62304 is a recognized consensus standard at the FDA and a harmonized standard under EU MDR and IVDR. Applying it gives a presumption of conformity for the software portions of your technical documentation. Skip it, and you carry the burden of justifying an alternative to a Notified Body or FDA reviewer, which is rarely worth the effort.
The practical stakes are audit exposure and time to market. Reviewers routinely check for the specific records the standard requires: a software development plan, requirements, architecture, unit and integration testing, and a maintained problem log. Missing or inconsistent records are among the most common causes of submission delays and audit findings for software-containing devices.
How IEC 62304 works
The standard organizes work around a software safety classification and a set of lifecycle processes. Classification comes first because it determines how much you must document and test.
- 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.
You assign the class based on the hazard a software failure could contribute to, after considering external risk controls. Higher classes trigger more required activities.
The lifecycle processes then apply according to class:
- Software development planning: define activities, deliverables, and traceability up front.
- Requirements analysis: capture functional, performance, and interface requirements, including those derived from risk controls.
- Architectural and detailed design: required for Class B and C; segregate items so a lower-class component cannot compromise a higher-class one.
- Implementation and verification: code, then verify against requirements with documented testing.
- Integration and system testing: confirm items work together.
- Release: document the configuration, known anomalies, and residual risk.
Two supporting processes run continuously: software configuration management (Clause 8) and software problem resolution (Clause 9). Risk management is not optional. IEC 62304 makes a normative reference to ISO 14971, so software risk analysis feeds directly from your device risk file. The standard also introduces SOUP (software of unknown provenance), meaning off-the-shelf or legacy code you did not develop under 62304. You must specify SOUP functional and performance requirements and evaluate its known anomalies.
Common challenges and best practices
The most frequent mistake is over-classifying or under-classifying software, then either drowning in documentation or failing to justify a low class during audit. Write a clear classification rationale that references your hazard analysis, and revisit it whenever the design changes.
SOUP handling trips up teams that build on open-source libraries or an operating system. Track each SOUP item, its version, and its anomaly list, and re-evaluate on updates. Traceability is the other recurring gap. Reviewers expect to follow a requirement for its design, its test, and any linked risk control. Build that traceability as you go instead of reconstructing it before a submission.
Cybersecurity sits outside the 2015 text but is now expected. Pair IEC 62304 with IEC 81001-5-1 for security activities and with IEC 62366-1 for usability, since regulators increasingly look for all three together.
How SJML helps with IEC 62304
SJML supports the full IEC 62304 software lifecycle as part of its Compliance-as-a-Service and engineering work. Teams cover software planning, requirements, architecture, verification, and maintenance for both SaMD and embedded device software, with software risk management aligned to ISO 14971 and usability engineering to IEC 62366-1. SJML also handles cybersecurity risk assessment under IEC 81001-5-1 and prepares the software documentation that supports FDA and EU MDR/IVDR submissions. This lets OEMs, from startups to established manufacturers, close software compliance gaps without building the capability in-house.
Frequently asked questions
The classes rank software by the worst harm a failure could cause. Class A means no injury is possible, Class B means non-serious injury is possible, and Class C means death or serious injury is possible. Higher classes require more design, testing, and documentation. You assign the class after accounting for external risk controls that reduce the potential harm.
Yes. IEC 62304 applies whether software is a standalone medical device (SaMD), such as a diagnostic mobile app, or is embedded in a physical device. If the software meets the definition of a medical device or drives one, the lifecycle processes apply. Regulators in the US and EU expect conformity for software-containing submissions regardless of the delivery format.
Neither the FDA nor the EU MDR names IEC 62304 as legally mandatory, but both effectively require its outcomes. The FDA lists it as a recognized consensus standard, and the EU publishes EN 62304 as a harmonized standard giving presumption of conformity. Demonstrating equivalent software controls without it is possible, but far more work.
SOUP stands for software of unknown provenance: code you did not develop under IEC 62304, such as an operating system, third-party library, or legacy component. The standard requires you to specify its functional and performance requirements, identify its published anomalies, and assess whether any could affect safety. You then manage SOUP versions under configuration control.
Related terms
- ISO 14971
- IEC 62366-1
- Software as a Medical Device (SaMD)
- IEC 81001-5-1
- Design Verification and Validation
