IEC 62304 Edition 2: What Is Changing and What Remains Unchanged

IEC 62304 is currently undergoing a major revision. Despite its scope, the update does not constitute a fundamental redefinition of the standard, but rather an evolution of its existing framework. The upcoming second edition reflects both ambition and restraint. It acknowledges the growing complexity of software ecosystems, but it also reinforces a central idea that remains unchanged: IEC 62304 is, fundamentally, a process standard.

From Medical Device Software to Health Software

One of the most visible changes is the expansion of scope. The draft explicitly moves from “medical device software” toward the broader concept of health software. This is not a trivial wording change. It reflects the increasing relevance of software that may not fit cleanly within traditional device boundaries, particularly in digital health contexts. However, this does not mean IEC 62304 becomes the umbrella for all digital health regulation. The standard remains focused on lifecycle processes. Other standards, such as IEC 82304-1, IEC 81001-5-1, and ISO 14971, continue to cover product-level concerns such as safety, security, and usability.

The separation between process and product is, if anything, reinforced rather than blurred.

From A/B/C to PRL: Simplification Without Oversimplifying

The upcoming edition introduces Process Rigour Levels (PRL) as a replacement for the traditional A/B/C software safety classification.

Under this new scheme, the three existing classes are effectively consolidated into two levels: PRL I, broadly aligned with Class A, and PRL II, encompassing what was previously covered by Classes B and C. This represents a structural simplification rather than a fundamental shift in philosophy.

Mapping of traditional Software Safety Classes to the new Process Rigour Levels (PRL).

The more meaningful change lies in how these levels are determined. PRL assignment is now explicitly linked to the likelihood of software contributing to harm and the severity of that harm, strengthening the connection between software development rigor and overall product risk. At the same time, IEC 62304 continues to delegate full responsibility for risk management to ISO 14971, preserving its role as a process standard rather than a risk framework.

Example of system-level safety architecture and software item classification.

At first glance, this shift may resemble the FDA’s “Basic” and “Enhanced” expectations under the Computer Software Assurance framework. However, the alignment is only superficial. IEC 62304 remains a process standard, not a regulatory submission framework, and PRLs should not be interpreted as direct equivalents to FDA categories.

The intent is not to mirror regulatory structures, but to provide a clearer and more scalable mechanism for defining the level of engineering rigor required, grounded in risk while remaining independent from any specific regulatory model.

Risk: Closer, but Still External

A subtle but important change in IEC 62304 Edition 2 is its alignment with the latest ISO 14971 terminology, particularly through the adoption of the broader concept of “harm.” The updated draft replaces the narrower notion of “harm to patients, operators, or other persons” with a more comprehensive definition that explicitly includes damage to property and the environment. This reflects the evolution introduced in ISO 14971:2019 and ensures that software-related risks are evaluated within the full scope of potential system impact.

In parallel, Edition 2 revises how risk management is positioned within the standard. Rather than embedding risk activities directly within the software lifecycle, the draft reinforces that risk management is a system-level discipline. This reinforces a key principle: risk remains governed by ISO 14971, while IEC 62304 defines how software is developed, verified, and maintained. The standard does not prescribe how risk is analyzed or accepted, but rather ensures that software engineering practices are consistent with the role software plays in the overall safety case.

A similar clarification of scope is reflected in the treatment of Quality Management System requirements. In the current edition, Clause 4 includes general QMS provisions such as document control and internal audits, which largely overlap with ISO 13485. Edition 2 is expected to remove these requirements entirely, narrowing the focus of IEC 62304 to software-specific processes. The rationale is straightforward: broad QMS obligations are already addressed by ISO 13485, and duplicating them within 62304 adds little value. This change further reinforces the separation between system-level quality management and software lifecycle processes.

Interplay between IEC 62304, ISO 13485 and ISO 14971.

SaMD, Cloud, and AI: Still About the Process

There is often an expectation that IEC 62304 Edition 2 will “adapt” itself to SaMD, cloud-native systems, or AI-driven products. The reality is more nuanced. As stated in the draft materials, IEC 62304 does not fundamentally change its position: regardless of whether software is embedded, cloud-based, or standalone, it continues to be treated as medical device software from a lifecycle process perspective.

What changes is the explicit recognition of these technologies within the standard, primarily through:

• the introduction of an AI Development Lifecycle (AIDL) concept
• additional planning and documentation expectations for AI-related risk management, where applicable
• new and expanded annexes addressing topics such as AI, cybersecurity, and cloud computing

These additions do not redefine the core structure of IEC 62304. Instead, they acknowledge the increasing presence of AI and distributed architectures, ensuring that such systems are properly considered within the existing lifecycle framework. The implication is clear: product complexity continues to increase, while the underlying process backbone remains stable.

From a practical standpoint, these changes are likely to have tangible effects on software engineering activities. The use of AI within a medical device introduces new challenges in requirements definition, particularly around probabilistic behavior, data dependencies, and performance boundaries. Verification strategies will need to evolve beyond deterministic testing to include dataset-based validation, robustness analysis, and bias evaluation. Additionally, AI components treated as SOUP might require higher qualification and risk justification, especially when models are pre-trained or externally sourced.

A related consideration is the increasing use of generative AI in the development process itself. Existing expectations around tool validation, traceability, and verification remain applicable. Code generated or assisted by AI must still meet the same standards of review, testing, and documentation. In this sense, AI does not reduce regulatory burden, but rather shifts the focus toward ensuring that its use is controlled, transparent, and compatible with the overall quality system.

Legacy Software Finally Gets Structured Treatment

Another meaningful improvement is the handling of legacy software, which is expected to be addressed through dedicated annexes. Instead of imposing unrealistic retroactive compliance, as mandated by the current Clause 10 in Edition 1, the new approach aims to provide a more structured and pragmatic path. Manufacturers are still expected to identify the highest risk classification that the legacy software would have under current criteria, but they are allowed to apply a more flexible, risk-based judgment when determining which documentation gaps need to be addressed.

Still in Progress

It is important to acknowledge that the standard is not yet finalized. The current work remains at the committee draft stage, and final outcomes may evolve. Some definitions, particularly those related to risk thresholds and terminology, are still under refinement.

Current estimates suggest that the standard may be formally published and harmonized by late 2026 or early 2027. From a regulatory perspective, a transition period of approximately two to three years is expected following publication, allowing organizations time to adapt.

Closing Thoughts: A More Mature Standard

For engineering teams, the message is clear. The fundamentals do not change: clear architecture, strong traceability, disciplined verification, and a deep connection between design decisions and system-level risk.

What changes is the expectation that these elements are not only present, but clearly justified. It reflects a better understanding of how software is actually developed, how systems behave in the real world, and how standards must interact rather than overlap.

IEC 62304 Edition 2 is not a disruption. It is a maturation.

Disclaimer
The information contained in this document is provided for educational and informational purposes only. While every effort has been made to ensure accuracy, we make no representations or warranties, express or implied, regarding the completeness, accuracy, reliability, or suitability of the information presented. Any reliance placed on this material is strictly at your own risk. This document does not constitute professional, regulatory, or legal advice. Readers are encouraged to consult qualified professionals and applicable regulatory authorities before making decisions based on the information provided. No proprietary product designs, confidential information, or client-specific technologies are disclosed or implied in this document. All product names, logos, brands, trademarks, and registered trademarks mentioned are the property of their respective owners. They are used for identification purposes only, and their inclusion does not imply any affiliation with or endorsement by the respective owners.In no event shall Montevideo Medical Devices, its affiliates, or its representatives be liable for any loss or damage, including without limitation indirect or consequential loss, arising from the use of or reliance on the information contained in this document.