IEC 62304 Edition 2: Changes for Manufacturers

A good 20 years after its initial publication and more than ten years after the release of Amendment 1, the IEC 62304 standard is entering another phase of its most extensive revision to date. The next Committee Draft (CD) of IEC 62304 Edition 2 is expected in August 2026. The current working draft already provides a good indication of the direction the new standard will take.

But be aware: comments will be received on the CD2 (2nd Committee Draft) expected in August, and these will be reviewed and incorporated before the final standard is published. Changes to the content - including key requirements - are therefore possible.

Nevertheless, it’s worth taking a look at the planned changes today.

“Medical device software” becomes “health software”

The most striking change is evident right in the title. “Medical Device Software – Software Life Cycle Processes” is becoming “Health Software – Software Life Cycle Processes.” What does this mean?

In fact, this “scope change” is one of the main amendments (the consequences of which ultimately led to the failure of the first attempt to revise IEC 62304). This change opens up a significantly broader scope of application. While the current IEC 62304 applies exclusively to software that is itself a medical device or becomes part of a medical device, the new edition is intended to apply generally to health software. This also includes health-related software solutions that do not necessarily fall under medical device regulations.

This change has far-reaching consequences: not all “health software” is a medical device (or is used in a medical device). Consequently, the software is not necessarily developed within an ISO 13485-certified quality management system, and furthermore, ISO 14971 (risk management) is not always applicable. For this reason, the upcoming IEC 62304 Edition 2 dispenses with the previous normative link to these standards. Instead, it merely requires quality and risk management at the product level in general terms.

Software safety classes are replaced by process rigour levels

In addition to the “scope expansion,” one of the most significant technical changes concerns the software safety classes.

Until now, IEC 62304 has distinguished between safety classes A, B, and C. Virtually every medical device software developer is familiar with this classification.

In Edition 2, this model disappears entirely. Instead, two software process rigour levels (PRL I and PRL II) are introduced. The objective is to avoid unnecessary complexity, which has repeatedly led to discussions between Manufacturers and Auditors - particularly regarding the question, “Which class does my software fall into?” However, it is important to note that although the transition is intended to lead to a leaner and more consistent model in the long term, its introduction will require significant effort to adapt in the short term.

Since classification can be applied not only at the system level but also to individual software elements (components), it becomes clear just how important a clean software architecture is (though this was already the case before). As before, it must be clearly demonstrated that these components are sufficiently separated from one another.

Familiar processes remain-but become significantly more specific

A major advantage: the familiar requirements for software development remain fundamentally unchanged. What is new is the level of detail.

For example, requirements are supplemented or clarified for:

software development planning,
communication processes,
release and maintenance planning,
software architecture,
architecture verification,
static code analysis,
integration and system testing,
documentation of test results,
traceability of changes and risk control measures.

Many of these topics have already been expected as part of Audits or addressed through other standards and guidelines. Now they are becoming a more integral part of IEC 62304 Edition 2.

Maintenance is described in greater detail

Chapter 6 has also been fundamentally revised. IEC 62304 Edition 2 now makes a clearer distinction between

field feedback,
actual software problems,
change requests, and
software improvements.

This provides a clearer overview of the process from a user’s feedback to the implementation and release of a software change. It also describes in greater detail when the problem resolution process must be applied in addition. Experience has shown that this has repeatedly led to questions in the past. Manufacturers with established post-market processes, in particular, are likely to welcome this clarification.

Cloud software is addressed for the first time

The current IEC 62304 was developed at a time when cloud-based software played virtually no role. As is well known, this has changed fundamentally, and IEC 62304 Edition 2 takes this development into account. For the first time, it includes requirements for the controlled modification and, in particular, the decommissioning of health software, such as cloud-based applications or Software-as-a-Service (SaaS) solutions.

In the future, manufacturers must specify

how software is decommissioned,
how users will be informed,
how the transition will be organized, and
how risks are managed during this phase.

The standard now covers the entire life-cycle of a software product, right up to its end of life.

Cybersecurity requirements remain outside the scope

The focus of IEC 62304 Edition 2 remains on describing general software lifecycle processes. The definition of cybersecurity requirements is left to other standards.

Since there are now established standards in this area (IEC 81001-5-1, for example, was developed specifically to map these requirements in accordance with the design and development life cycle of IEC 62304), IEC 62304 Edition 2 refers in this context to

IEC 81001-5-1 (Security Requirements in the Software Life cycle),
IEC TR 60601-4-5 (Cybersecurity Measures in Medical Electrical Equipment; establishes the link to the IEC 62443 family for IT security in industrial automation and control systems (IACS/ICS),
IEC TS 81001-2-2 (Communication of Cybersecurity Characteristics and Requirements between Manufacturers and Operators).

For manufacturers, this means that safety and security processes must continue to be integrated across multiple standards. While this makes technical sense (as it allows the content of the individual standards to be clearly delineated and further developed), it increases the effort required for planning, documentation, maintenance, and auditing for all parties involved.

Artificial intelligence and agile design and development get their own annexes

New additions include informative annexes on AI and agile design and development.

For the first time, there are separate chapters on

artificial intelligence-enabled health software and
agile software development

Although these annexes do not contain any new mandatory requirements, they provide guidance on which technologies and development models will be considered state-of-the-art in the future.

The AI annex could - alongside the previously discussed transition to the process rigour levels - be the most talked-about section of Edition 2.

And: unfortunately, legacy software has also been moved to the informative annex in this context, see our assfessment below.

Our assessment

The second edition of IEC 62304 has the objective of adapting the standard to modern software development. Cloud applications, agile design and development, and AI play a much greater role today than they did when the first edition was published in 2006. It is all the more surprising, however, that some of the most exciting topics are ultimately addressed only in informative annexes.

AI requirements are non-binding

Particularly striking is the treatment of artificial intelligence. While AI is now being used in an increasing number of medical devices, the draft contains only an informative annex on AI-enabled health software. The same applies to agile design and development.

Manufacturers today face very practical questions: How is a trained model versioned? How is training data management documented? Which changes to a model are relevant for maintenance? Which verification measures are appropriate? Especially with AI, many of these questions differ significantly from those in traditional software development.

Although the informative annex provides helpful guidance, it does not establish uniform, auditable requirements. As a result, key expectations regarding the Implementation and Review of AI systems remain outside the scope of IEC 62304.

Unfortunately, “legacy software” has also been included in the informative annex. In our view, European manufacturers in particular will regret this, as the basis for a well-founded and robust discussion regarding the use of existing software (and software components) is now lacking. It is precisely in this area that continued normative requirements for a risk-based approach to legacy software would have contributed to greater planning certainty.

The new process rigour levels will not be easy to implement

Replacing the familiar software safety classes A, B, and C with process rigour levels I and II is also unlikely to bring only advantages in practice.

While the idea of aligning the scope of development activities more closely with the required process rigour is understandable, for companies that have been working according to IEC 62304 for many years, the transition initially means one thing above all else: additional effort.

Virtually all existing documentation currently refers to the software safety classes. Development plans, verification concepts, traceability matrices, SOPs, training materials, and, not least, numerous software tools are based on the established A/B/C model. All of these documents would need to be reviewed and, if necessary, adapted.

Added to this is a transition phase during which manufacturers must explain to Notified Bodies how the previous safety classes map to the new process rigour levels. Especially for existing products with a long history, this migration is likely to entail a considerable amount of documentation work - without directly improving actual product safety.

Conclusion

Edition 2 addresses many topics that have been established in practice since 2006. This is welcome news, considering that a period of over 20 years represents a significant span of time in an industry like software development!

The fundamental lifecycle processes remain intact. At the same time, the standard responds to developments that have shaped software development in recent years: cloud applications, agile design and development, cybersecurity, AI, and an (even) stronger risk-based approach to design and development processes.

Manufacturers will likely not need to completely rebuild existing design and development processes, but the devil is in the details. That is why it is worth familiarizing yourself with the planned changes today. In particular, the new process rigour levels could have a significant impact on design and development and quality management processes, as a software product could “suddenly” slip into a high rigour level, requiring much more stringent processes and more extensive documentation.

Note: The text available at the time of writing is a working draft and not yet a published standard. Requirements, terminology, and content may still change significantly before final publication. Statements regarding the future IEC 62304 Edition 2 should therefore always be considered subject to this reservation.

The New Draft of IEC 62304 Edition 2: What Does This Mean for You as a Manufacturer of Medical Devices With Software?

Do you have any questions?