IEC 62304 explained: software safety classes A, B and C

Why the MDR points at IEC 62304

The MDR does not name IEC 62304 in its operative text. What it does, in Annex I, is set a general safety and performance requirement for software. GSPR 17.2 requires that software which is a device in itself, or which is incorporated in a device, is developed and manufactured in accordance with the state of the art, taking into account the principles of development life cycle, risk management including information security, and verification and validation.

State of the art is the operative phrase. It is not defined by the regulation, and the practical way manufacturers demonstrate it is by applying harmonised standards. Applying a harmonised standard gives a presumption of conformity with the requirement it covers. For the software development lifecycle, that standard is EN 62304, and the version currently harmonised under the MDR and the IVDR is EN 62304:2006 plus Amendment 1 from 2015.

So the chain is: the MDR requires a state of the art development lifecycle; EN 62304 is the harmonised way to show one; and IEC 62304 is where the actual process requirements live. It applies whether your software is the device or sits inside one, which means it applies to both of the routes to market covered in our piece on software placed on the market in its own right versus as part of a device.

The three software safety classes

IEC 62304 classifies software by the harm that could result if it failed. There are three classes, and the definitions are short.

Two features of this scheme surprise people. The first is that it is driven purely by severity, not by likelihood. The standard takes the position that the probability of a software failure occurring should be assumed to be 1. You cannot argue your way down a class by claiming your code is reliable, because the standard has already assumed it will fail. What you can argue about is what happens next.

The second is that, since Amendment 1 in 2015, you assess the resulting hazardous situation while taking into account risk control measures external to the software. If a hardware interlock, an independent alarm or a mechanical limiter would prevent the harm regardless of what the software does, that measure counts. This is the single most useful lever in the standard, and it is an architecture and system design decision rather than a documentation one.

Your software safety class is not your device class

This is the confusion worth eliminating early, because it wastes real money. MDR classification under Annex VIII, including Rule 11 for software, asks how much risk the device presents to the patient and therefore how much regulatory oversight it needs, including whether a Notified Body must be involved. IEC 62304 classification asks a narrower engineering question: if this software fails, how badly could someone be hurt, given everything else in the system.

The two do not map onto each other. A Class IIa device under Rule 11 can contain software that is Class A under IEC 62304, if an external measure means a software failure cannot cause injury. Equally, software inside a lower class device can be Class C if its failure could kill someone. One is a market access question, the other is a development process question.

The practical consequence: do not let a Notified Body conversation about device class set your software process burden, and do not assume a low device class means a light software lifecycle. Work them out separately, and write down the reasoning for each.

SOUP, and why it is the modern problem

SOUP stands for software of unknown provenance. It covers software items that are already developed and generally available, and were not developed to be incorporated into your device, as well as software you previously developed but for which you no longer hold adequate records of the development process. In other words: nearly every third party library, framework, operating system and open source dependency in your stack.

IEC 62304 does not forbid SOUP. It requires you to know what you are using and to reason about it. You need to identify each SOUP item and its version, state the functional and performance requirements you rely on it for, identify the hardware and software the item needs to run, and evaluate the published anomaly lists for defects that could contribute to a hazardous situation in your device.

For modern software teams this is where the standard bites hardest, because dependency trees are deep and change weekly. It is also where the work overlaps most usefully with cybersecurity obligations: the SOUP inventory you maintain for IEC 62304 is essentially the same artefact as a software bill of materials, and maintaining one list rather than two is the obvious move.

Architecture can lower your burden

Because classification can be applied to software items and not only to the system as a whole, architecture becomes a regulatory instrument. If you can demonstrate genuine segregation between items, you can classify them separately, which means the safety critical portion carries the heavy process and the rest does not.

The word doing the work is demonstrate. Segregation has to be real and justified, and the standard expects you to document the design decisions that make it real, not simply to assert that two modules are independent because they live in different folders. Shared memory, shared runtimes and shared failure modes all undermine the claim.

Teams that think about this at architecture time typically end up with a small Class C or Class B core and a much larger Class A remainder. Teams that do not usually find the highest class propagating across the entire codebase, and the documentation burden with it.

Legacy software

Amendment 1 in 2015 added provisions for legacy software, meaning software that was already legally on the market but was not developed under a compliant IEC 62304 process. This matters because the alternative reading, that you must retrospectively reconstruct a full development history, would be impossible for most products with any history behind them.

The route the standard provides is risk based. You assess the legacy software using its post-market history and known issues, identify the gaps in your evidence, and produce a plan that closes them proportionately rather than rebuilding the record from scratch. It is a pragmatic provision, and it is under-used by companies that assume they have to start again.

Where Edition 2 actually stands

A second edition of IEC 62304 has been in development for years, and a considerable amount of published commentary claims it will be published in 2026 and that it replaces the A, B and C classes with a smaller number of process rigour levels. Treat those claims carefully, because the committee record does not support the timing.

The revision is a joint project between IEC SC 62A and ISO TC 215. A first committee draft circulated in 2025 and attracted close to 1,500 comments, and the working group has been preparing a second committee draft. A final draft international standard is not expected until around 2028, which puts realistic publication in the 2028 to 2029 range. IEC's own forecast publication date has sat at October 2028. An earlier attempt at the committee draft for vote stage was approved on the IEC side but not carried in ISO and CENELEC, which is part of why this has taken so long.

The direction of travel is real: broader scope towards health software generally, explicit security and usability requirements, and a rethink of how process rigour is determined. But the detail is still moving, and a draft is not a standard. The sensible position is to build against EN 62304:2006 plus Amendment 1, which is what is harmonised today and what a Notified Body will assess you against, and to watch the revision rather than plan around it.

There is one thing worth doing now regardless. The changes under discussion push in the direction of tighter integration between the software lifecycle, risk management and security. Teams whose SOUP inventory, risk file and security threat analysis are already one connected system rather than three separate documents will have far less to do whenever the new edition does land.

Practical steps

The most common failure pattern is treating IEC 62304 as a documentation exercise performed near the end, which produces a large volume of paper that does not match how the software was actually built. The standard is a lifecycle standard, and the evidence it asks for is a by-product of a disciplined process rather than something you can reconstruct afterwards.

Retrofitting is possible, and the legacy provisions help, but it is materially more expensive than doing it as you go. If you are early, the highest leverage decisions are architectural, because they determine how much of your codebase carries the heavy classification for the rest of the product's life.

• Classify the software system first, then look for defensible segregation of items
• Assess the class with external risk control measures in mind; that is where the leverage is
• Keep your safety class and your MDR device class as separate, separately justified decisions
• Maintain a real SOUP inventory with versions and anomaly list reviews, and reuse it as your SBOM
• Use the legacy software route rather than reconstructing a development history you do not have
• Build against EN 62304:2006+A1:2015, the currently harmonised version, and treat Edition 2 as a watching brief