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. The usual way to demonstrate it is a harmonised standard, which gives a presumption of conformity with the requirement it covers, but that route is not available here: EN 62304 is not on the list of standards harmonised under the MDR or the IVDR (Commission Implementing Decisions (EU) 2021/1182 and 2021/1195, as consolidated on 17 June 2026). IEC 62304:2006 with Amendment 1 of 2015 is nonetheless the recognised state of the art for the software lifecycle, and it is the reference point Notified Bodies work from and the FDA recognises as a consensus standard.
So the chain is: the MDR requires a state of the art development lifecycle; IEC 62304 is the recognised way to show one, although without a formal presumption of conformity; 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.
| Class | If the software fails | What the process looks like |
|---|---|---|
| A | A failure cannot lead to harm | Lightest. Planning, requirements analysis, release and maintenance |
| B | A failure could lead to harm, short of serious injury | Adds architectural design, integration and integration testing, and system testing |
| C | A failure could lead to serious injury or death | Heaviest. Adds detailed design and the fullest verification expectations |
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. In plain terms it is software you did not develop under your own lifecycle for this device, or whose development records you no longer have: 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 run by maintenance team MT 49 of IEC SC 62A. A first committee draft circulated in January 2025 and a second on 7 August 2026, and the project is still at committee draft stage. IEC's own project plan puts the approval stage in June 2028 and publication on 26 October 2028, and projects of this size tend to slip rather than accelerate. This is also the second attempt: an earlier revision reached committee draft for vote, was approved at that stage in 2019, was rejected at the next vote in 2021, and was cancelled in 2023 before the current project restarted it.
The direction of travel is real. The published design specification widens the scope to health software generally, rethinks how process rigour is set in place of the current safety classes, and points out to cybersecurity standards rather than writing security requirements into IEC 62304 itself. But the detail is still moving, and a draft is not a standard. The sensible position is to build against IEC 62304:2006 with Amendment 1, the edition in force and the one Notified Bodies and the FDA work from, 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 IEC 62304:2006+A1:2015, the edition in force, and treat Edition 2 as a watching brief