IEC 62304

IEC 62304 establishes a life-cycle framework for software used in medical devices, including embedded software and software marketed as a medical device. It organizes work from planning and requirements through implementation, verification, release, maintenance, and retirement.¹ The standard is deliberately process-oriented: it does not mandate a single development model, coding language, toolchain, or user-interface design.

Its central concern is software safety in the context of the medical device. Manufacturers therefore determine how software contributes to hazardous situations and use that determination to assign a safety class. IEC 62304 complements, rather than replaces, broader quality-system and risk-management requirements. Regulators commonly consider it alongside ISO 14971, applicable quality-system rules, and jurisdiction-specific submission guidance.

The safety classification determines the rigor of the required software processes. Class A applies when software failure cannot contribute to injury or damage to health; Class B applies when failure can contribute to non-serious injury; and Class C applies when failure can contribute to death or serious injury.¹

All classes require planning, requirements analysis, architectural activity, detailed design and implementation controls appropriate to the assigned risk, as well as verification and release evidence. Higher classes add or strengthen activities such as software-unit verification, integration testing, traceability, and documented control of unresolved anomalies. The classification is based on the consequences of software failure, not simply on the number of lines of code or the novelty of the technology.

IEC 62304 provides the software life-cycle structure, while risk management identifies hazards and evaluates the consequences that drive software safety decisions. A manufacturer typically links software requirements, risk controls, architecture, tests, and residual anomalies through traceability.³

The standard does not by itself demonstrate clinical safety, effectiveness, cybersecurity, usability, or compliance with every regulatory obligation. The U.S. Food and Drug Administration uses software-specific submission guidance to describe documentation expectations, while the European Union Medical Device Regulation sets legal requirements for devices placed on the European market.⁴ Usability engineering is generally addressed through IEC 62366-1, and security concerns may require additional standards and controls.

IEC 62304 is not a certification scheme and does not automatically make a product compliant. Conformity depends on the complete evidence set, the applicable regulatory framework, and how the manufacturer has justified its process and risk decisions.

A notable feature is its treatment of legacy software: a manufacturer may need to establish a documented maintenance and risk-based plan when historical development records are incomplete, rather than simply recreating every artifact from scratch. The standard also separates software maintenance from problem resolution, requiring controlled handling of changes, anomalies, and their effects on released versions.¹ It can be used with agile or iterative development, provided that planning, requirements, verification, configuration control, and traceability remain demonstrable. The framework applies to software changes after release as well as to initial development.

Software safety class

A classification—A, B, or C—based on the potential severity of harm resulting from software failure.

Software life cycle

The controlled set of processes spanning planning, development, release, maintenance, and retirement.

Traceability

The documented linkage among requirements, risks, implementation elements, verification evidence, and released software.

Legacy software

Previously developed software incorporated into a current medical device, often with incomplete historical records.