ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
IEC 62304 legacy software is the standard’s answer to a question every established manufacturer eventually faces: we have software that has been on the market for years, safely, and we cannot produce the design history a current-edition life cycle would have generated — what now? Before 2015 the honest answer was “reconstruct it or hope the reviewer does not ask”. Amendment 1 added clause 4.4, a defined alternative route that is narrower than a full life cycle and more rigorous than a waiver.
This guide sets out what qualifies as IEC 62304 legacy software, what the clause 4.4 route requires step by step, the one deliverable it never lets you skip, and where manufacturers misuse it.
The standard’s definition has three conditions, and all three have to hold. The software was legally placed on the market. It is still marketed today. And there is insufficient objective evidence that it was developed in compliance with the current edition of the standard. Software that was withdrawn is not legacy software; software with a complete Edition 1.1 file is not either, however old it is.
| Situation | IEC 62304 legacy software? | Route |
|---|---|---|
| Software developed to the 2006 first edition, with records, still sold | Possibly — depends whether the 2006 records are sufficient evidence against Edition 1.1 | Gap analysis decides; often a short clause 4.4 exercise |
| Software developed before 2006 with partial records, still sold | Yes | Clause 4.4 |
| Software developed under a general engineering process, never against IEC 62304, still sold | Yes | Clause 4.4 |
| Software developed last year without a life cycle, not yet on the market | No — never legally placed on the market | Clauses 5–9 in full; the route is not a shortcut for new software |
| Software on the market, complete Edition 1.1 file | No | Nothing to do |
| A SOUP component your product uses | No — SOUP has its own requirements | Clauses 5.3.3, 5.3.4, 7.1.3, 8.1.2 |
The decision to use the route is itself recorded: that the software was legally marketed, that it still is, what evidence exists and against which edition, and why that evidence is insufficient. If the evidence is in fact sufficient, the software is not legacy and the route is not available.
For IEC 62304 legacy software, clause 4.4 offers compliance through 4.4.2 to 4.4.5 as an alternative to applying clauses 5 to 9. Four steps, in order.
The gap analysis is measured against what the software safety class requires, so the class comes first, decided under clause 4.3 exactly as for new software — worst-case harm after external risk controls. Our guide to software safety classification covers the decision. Until a class is recorded, Class C applies, which for legacy software means the widest possible gap analysis.
The manufacturer assesses all feedback on the legacy software — incidents and near-incidents, from inside the organisation and from users — and performs risk management activities on its continued use, considering five aspects: how the legacy software is integrated in the overall device architecture; whether the risk control measures implemented in it are still valid; the hazardous situations associated with continuing to use it; the potential causes by which it could contribute to them; and the risk control measures for each cause.
This step is where IEC 62304 legacy software differs most from new software. Annex B.4.4 points out that a long, clean field record is evidence a new product can never have: where post-production data allows a quantitative estimate of a failure sequence’s probability, it may be used — an option the standard otherwise denies software, whose failure probability is set to one.
Based on the class, the manufacturer compares the IEC 62304 legacy software’s existing deliverables — that is, compares the deliverables that exist against those the standard requires from four places only: software requirements analysis (5.2), software architectural design (5.3), software system testing (5.7) and the software risk management process (clause 7). Detailed design, unit verification, integration testing, planning and release are not in the legacy gap analysis.
Three sub-steps follow. First, assess whether the deliverables that exist are still valid — a specification that no longer describes the shipped software is not a valid deliverable. Second, for each gap, evaluate how much risk would be reduced by generating the missing deliverable and performing its activity. Third, decide which deliverables to create on that basis. The standard’s note adds the practical point: the analysis should make sure that risk control measures implemented in the legacy software appear in its software requirements, because otherwise they have nothing to trace to.
An IEC 62304 legacy software closure plan is established and executed to generate the deliverables selected. It may sit inside the software maintenance plan. Where objective evidence already exists, it may be used to produce a required deliverable without repeating the activity — a test log from 2014 can become a system test record if it carries the content 5.7.5 requires. The plan addresses how problems found in the legacy software or its deliverables are handled through the clause 9 problem resolution process, and any changes to the software are made under the clause 6 maintenance process.
Finally, the manufacturer documents the version of the legacy software together with a rationale for its continued use, built from the outputs of the steps above. That signed rationale is the demonstration of compliance for that version.
Clause 4.4.3 c) sets one deliverable that the risk-reduction evaluation cannot argue away. The minimum deliverable of the IEC 62304 legacy software route is software system test records meeting 5.7.5 — a reference to the test procedure, the result and anomalies, the version tested, the hardware and software configuration, the tools, the date and the tester. If they do not exist, system testing is performed and recorded. Everything else in the gap analysis is a judgement; this is not.
| Obligation | Under the IEC 62304 legacy software route |
|---|---|
| Clauses 5.1, 5.4, 5.5, 5.6, 5.8 for the past development | Not required — the gap analysis is scoped to 5.2, 5.3, 5.7 and clause 7 |
| Clauses 5.2, 5.3, 5.7 and 7 deliverables | Required where the risk evaluation selects them; system test records always |
| Clause 6 maintenance from the day the rationale is signed | Required in full — feedback, problem evaluation, change control, communication, re-release |
| Clause 8 configuration management going forward | Required in full, including SOUP identification |
| Clause 9 problem resolution going forward | Required in full |
| A new version made through maintenance | A modification under clause 6, released under 5.8; it does not reopen the legacy route |
The second half of that table is the part manufacturers forget. Clause 4.4 is an alternative to applying clauses 5 to 9 to the development that already happened. From the signature onward, legacy software is maintained, configuration-managed and its problems resolved like any other software system. Our guide to SOUP under IEC 62304 covers one of those forward obligations that legacy products routinely fail.
The introduction to Amendment 1 is explicit that the legacy provisions were added to assist manufacturers who must show compliance to the standard to meet European Directives — the situation created when a harmonised standard becomes the expected route to conformity for products that predate it. Annex B.4.4 adds the engineering argument: retrospective documentation of a finished development, performed as an isolated exercise, does not by itself reduce risk. The route identifies the subset of activities that does, and it produces objective evidence supporting continued use plus a rationale.
That is also why it is defensible to a notified body or an FDA reviewer. It does not claim the software was developed to the standard. It claims that its continued use is justified on the field record, the risk analysis and the deliverables that matter — and it says so in a document with a version number on it. Our guide to harmonised standards under the MDR covers the conformity mechanics the route was written for.
The IEC 62304 Toolkit carries a legacy software assessment procedure and a gap analysis and rationale record laid out on the four steps above — deliverable inventory against 5.2, 5.3, 5.7 and clause 7 by class, the risk-reduction evaluation per gap, the closure plan with an activity-or-evidence route for each deliverable, and the signed rationale — alongside the maintenance plan the closure plan can sit in. The standard is licensed by the IEC; the requirements here are paraphrased from it.
Yes. The route is available at any class; the class decides how many deliverables the gap analysis is measured against. A Class C legacy system owes the full 5.2, 5.3, 5.7 and clause 7 set where the risk evaluation selects it, and system test records in any case.
Only if system test records meeting 5.7.5 do not already exist. Where valid records exist, they are the deliverable. Where they do not, system testing is performed — it is the minimum output the route requires.
Yes, from the day the rationale for continued use is signed. Clause 6 applies in full; the standard’s own note suggests the gap-closure plan can be carried inside the maintenance plan.
The change is a modification under clause 6: the clause 5 activities it requires are repeated for the affected items, the change is analysed for safety, and the new version is released under 5.8. The legacy route is not reopened.
September 13, 2026
September 13, 2026
September 13, 2026
September 13, 2026
September 13, 2026