IEC 62304 Amendment 1 (2015) is the update that turned the original 2006 software lifecycle standard into the version currently harmonised under the MDR — EN 62304:2006+A1:2015. The three changes that matter most for startups are: a new framework for handling legacy software (software that existed before the lifecycle process was in place), refinements to the problem resolution and risk management activities so they better integrate with the updated EN ISO 14971 process, and explicit clarifications around software of unknown provenance (SOUP) and basic security considerations. Amendment 1 did not rewrite the standard. It closed the gaps the 2006 text left open — the gaps every real engineering team was already running into.

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • IEC 62304:2006 was the original software lifecycle standard. Amendment 1 (2015) produced the combined text EN 62304:2006+A1:2015, which is the version referenced as the harmonised standard under MDR Annex I Section 17.2.
  • The biggest A1 addition is the legacy software framework — a structured way for manufacturers to bring pre-existing software under the standard without reconstructing a full lifecycle from scratch.
  • A1 refined the problem resolution process, tightened the link between software risk management and EN ISO 14971, and added explicit handling of software of unknown provenance (SOUP).
  • Security considerations became more visible in A1, though the full cybersecurity lifecycle for health software now sits in EN IEC 81001-5-1:2022 and MDCG 2019-16 Rev.1.
  • For MDR conformity, the only version that matters is EN 62304:2006+A1:2015. The unamended 2006 text on its own does not give presumption of conformity under the current harmonised standards list.
  • Pre-2015 software that a startup is now bringing under MDR should be assessed against the A1 legacy software clause — this is a lighter, honest path than pretending the software was developed under a full 62304 lifecycle from day one.

Why this matters for your startup

Most of the software startups we work with have a code base that predates any regulatory intent. Someone built a prototype, the prototype worked, a hospital got excited, funding came in, and now the question is how to get a CE mark for software that was written long before anyone had heard of Section 17.2. Pretending the code was developed under a documented EN 62304:2006+A1:2015 lifecycle from the first commit is not an option — a Notified Body auditor can tell the difference between a lifecycle run in-flight and a reconstruction performed the week before the audit.

Amendment 1 is the reason the honest path exists. Before 2015, the standard had no good answer for legacy software. Teams either pretended the full lifecycle had been there all along, or they rewrote from scratch. A1 added a framework that says: if you have software that was not developed under this standard, here is a structured way to bring it under the standard through gap analysis, risk assessment, and targeted remediation, rather than reconstruction theatre. That framework is what lets a real startup get a real CE mark on software that was not born in a QMS.

This post walks through what A1 actually added, how it interacts with MDR Annex I Section 17.2, and how a resource-constrained startup can use the legacy software clause without abusing it. The goal is to give you enough of the structure that you can decide which parts of your code base are legacy under the A1 definition and which parts need a full 62304 lifecycle from the next commit forward.

What MDR Section 17.2 actually requires (quick recap)

MDR Annex I Section 17.2 requires that software be 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, verification, and validation. (Regulation (EU) 2017/745, Annex I, Section 17.2.) The MDR itself does not name a standard — the "state of the art" mechanism pulls in whichever harmonised standard is listed in the Official Journal. For the software lifecycle, that standard is EN 62304:2006+A1:2015.

The consequence is direct. Compliance with EN 62304:2006+A1:2015 gives presumption of conformity with the software-lifecycle aspects of Annex I. The unamended IEC 62304:2006 text alone is historical — it is not the version currently harmonised under MDR, and a Notified Body will not accept a technical file that cites only the 2006 text without the A1 amendment. Whenever we reference "the standard" in this post, we mean the combined EN 62304:2006+A1:2015 text.

For the full walkthrough of how Section 17.2 and EN 62304:2006+A1:2015 fit together, see the pillar post MDR Software Lifecycle Requirements.

What Amendment 1 (2015) actually added

Amendment 1 is not a rewrite of the standard. It is a targeted set of changes that address the gaps the 2006 text left open after nearly a decade of use by manufacturers and auditors. The changes cluster into three areas: legacy software, process refinements, and security. We walk through each.

1. The legacy software clause (Clause 4.4 under the A1 text)

The single biggest addition in A1 is the legacy software framework. The original 2006 standard implicitly assumed that a manufacturer would apply the full lifecycle from the first line of code. In practice, that assumption broke immediately. Manufacturers had pre-existing software they needed to bring under the standard — either because the software predated the 2006 publication of 62304, or because it predated the manufacturer's decision to treat it as a medical device. A1 added a dedicated clause (identified in the combined text as Clause 4.4 — ) that describes how to handle this case.

The framework in plain terms: the manufacturer performs a gap analysis of the existing software against the standard's requirements, assesses the risk contribution of the software using the EN ISO 14971 process, and then runs targeted activities to close the most safety-relevant gaps first. The manufacturer does not have to reconstruct a full lifecycle history for the pre-existing code. Instead, the manufacturer documents what is known about the software, what is not known, what the risk implications of the unknowns are, and what remediation activities will bring the software to a state where it can be maintained under the full standard going forward.

This is not a loophole. It is a structured, documented, auditable path. The legacy software clause still requires that risk be understood and controlled, that problem resolution be in place, and that the software be brought under configuration management and maintenance processes from the point of assessment forward. What the clause removes is the expectation that the manufacturer will reconstruct requirements, architecture, and design documentation for code that was written before those activities existed. What it replaces that with is the expectation that the manufacturer will take an honest snapshot of the current state, identify the gaps that matter for safety, and close them.

2. Problem resolution and risk management refinements

The second cluster of A1 changes is a set of refinements to the problem resolution and risk management processes. The 2006 standard had both processes, but the interfaces between them and between 62304 and the then-current ISO 14971:2007 text were not as tight as they needed to be.

A1 refines the problem resolution process to make the path from an anomaly report to a risk re-assessment, to a configuration management action, to a release decision, more explicit. Problem reports have to be investigated, their risk implications have to be evaluated against the risk management file, and the decisions have to be documented and fed back into the configuration management record. A1 tightened the expectation that problem resolution is not just a bug tracker — it is a controlled process with defined inputs, outputs, and traceability to the rest of the lifecycle.

The risk management refinements in A1 align 62304 more cleanly with the ISO 14971 process. The software risk management activities described in 62304 are explicitly positioned as a sub-process within the overall ISO 14971 risk management, not as a parallel track. Outputs of the ISO 14971 process — hazards, hazardous situations, risk controls — drive the software safety class determination under 62304, and software risk controls implemented under 62304 feed back into the overall risk management file. For the MDR startup, this matters because the combination of EN 62304:2006+A1:2015 and EN ISO 14971:2019+A11:2021 has to work as one integrated process, not as two disconnected ones, and A1 is the reason the integration is explicit in the standard text.

3. Software of unknown provenance and security

The third cluster is smaller but important. A1 sharpened the treatment of software of unknown provenance (SOUP) — third-party components, open-source libraries, operating systems, drivers — and clarified what the manufacturer is required to know about them, how they are identified, how they are evaluated for risk, and how they are tracked under configuration management. For any modern software stack with dependencies on npm, PyPI, Maven, or an OS-level runtime, SOUP handling is a significant and recurring piece of the lifecycle, and A1 is the version of the standard that makes the requirements usable.

A1 also introduced more explicit references to security considerations within the software lifecycle. The 2006 text mentioned information security in passing; A1 made the hook for security activities more visible. That said, the full cybersecurity lifecycle for health software is not carried by EN 62304:2006+A1:2015 alone. The current harmonised standard for health software security activities across the product life cycle is EN IEC 81001-5-1:2022, and the definitive guidance is MDCG 2019-16 Rev.1. EN 62304:2006+A1:2015 is the foundation on which the security lifecycle layers, not the complete security standard.

Worked example: applying the legacy software clause to a pre-2015 code base

Take a concrete case. A startup built a web application between 2018 and 2022 that processes anonymised imaging data and surfaces measurements to clinicians. The code base started as a research prototype, pivoted twice, and is now the commercial product. There is no software development plan, no requirements specification that traces to the current code, no architecture document that matches what the team actually built, and no formal risk management file. There are, however, good engineering practices — version control in Git, code reviews on every merge, automated tests at unit and integration level, a bug tracker, and a release process. The founder wants to CE-mark the software as an MDR Class IIa MDSW.

A full reconstruction of a 62304 lifecycle from scratch — writing requirements, architecture, and design documents that retroactively describe the existing code — is the wrong move. It is expensive, it takes six to nine months, and it produces artefacts that do not actually reflect the development history. An auditor who has seen the pattern before can smell it.

The right move under the A1 legacy software clause is a structured gap assessment. The manufacturer documents: what the software does (intended purpose and system requirements, written now, honestly describing the current behaviour); what is known about the architecture (extracted from the code, documented at the software-item level, not reverse-engineered to the unit level); what SOUP components are in use (the full dependency tree, with versions, licences, and risk-relevant metadata); what verification evidence exists (the automated tests and CI logs that the team has been running all along); and what the current problem resolution and configuration management practices look like.

Then the manufacturer runs the EN ISO 14971:2019+A11:2021 risk management process against the system as it exists now, identifies software-relevant hazards, assigns the software safety class under 62304, and identifies the gaps that matter for safety. High-safety-class items get targeted remediation — additional verification, additional design documentation, tightened problem resolution. Low-safety-class items get brought under the standard through lighter activities. The output is a legacy software assessment report that an auditor can read, understand, and accept as the basis for the forward lifecycle.

From the assessment date forward, every new commit is under the full EN 62304:2006+A1:2015 lifecycle. The legacy clause is a one-time exit from the reconstruction trap, not a permanent exemption. MDCG 2020-3 — which sits alongside this guidance on changes to legacy devices under Article 120 of the MDR — is worth reading as context for how the Commission has thought about legacy-status devices more broadly, though its direct scope is the MDD-to-MDR transition rather than the 62304 legacy software clause itself. ()

Ship — a gap analysis playbook for pre-2015 software

If your software was written before the team had a documented 62304 lifecycle in place, here is the playbook we use to run the gap analysis under the A1 legacy software clause.

Step 1 — Freeze the scope. Decide exactly which modules of the code base are in scope as medical device software. Use MDCG 2019-11 Rev.1 to draw the boundary between the regulated module and the non-regulated supporting infrastructure. The smaller the regulated scope, the cheaper every downstream activity is.

Step 2 — Document the current state honestly. Write the system requirements and intended purpose as they exist today. Extract the architecture from the code at the software-item level. List every SOUP dependency with version and licence. Collect the existing verification evidence — test reports, CI logs, code review records.

Step 3 — Run the risk management process. Execute EN ISO 14971:2019+A11:2021 on the current system. Identify hazards, hazardous situations, and software-relevant risk controls. Assign the software safety class — A, B, or C — at the software-item level.

Step 4 — Gap-assess against EN 62304:2006+A1:2015. Compare the current state documentation against the standard's process requirements. Identify what is missing. Categorise the gaps by safety class: gaps in Class C items are priority, Class B second, Class A third.

Step 5 — Plan the remediation. For each gap that matters, decide whether to close it with targeted activities (new verification runs, additional design documentation, tightened problem resolution) or to justify the gap through risk arguments. Document the plan in a legacy software assessment report.

Step 6 — Execute the remediation and transition. Close the gaps, update the risk management file, and declare a transition date from which all new work is under the full lifecycle. From that date forward, every change follows EN 62304:2006+A1:2015 end-to-end.

Step 7 — Brief the Notified Body early. The legacy software path is acceptable under A1, but it is also the kind of topic auditors like to see raised early in the certification project rather than discovered during the assessment. A short technical note to the Notified Body explaining the legacy assessment approach and the remediation plan is time well spent.

Reality Check — Is your pre-2015 code base ready for the A1 legacy clause?

  1. Can you draw a clean line between the code that is in scope as medical device software and the code that is supporting infrastructure outside scope?
  2. Do you have an honest, current-state system requirements document that reflects what the software actually does today?
  3. Can you produce an architecture description at the software-item level that an auditor could verify against the code?
  4. Is every SOUP component in your dependency tree identified, versioned, and risk-assessed?
  5. Have you run EN ISO 14971:2019+A11:2021 on the software as it exists now, not on a hypothetical future version?
  6. Have you assigned a software safety class to each software item, with the reasoning linked to the risk management file?
  7. Do you have a legacy software assessment report that documents what is known, what is not known, what the gaps are, and how they will be closed?
  8. Have you set a transition date after which all new development follows the full EN 62304:2006+A1:2015 lifecycle?
  9. Have you briefed your Notified Body on the legacy assessment approach before the formal submission?

Any question you cannot answer with a clear yes is a gap between your current state and an audit-ready A1 legacy software submission.

Frequently Asked Questions

Is EN 62304:2006+A1:2015 still the current harmonised version? Yes. As of this post's last update, EN 62304:2006+A1:2015 is the version referenced as the harmonised standard for the software lifecycle under MDR Annex I Section 17.2. A newer edition of IEC 62304 has been under development for years, but until it is published, harmonised, and listed in the Official Journal, EN 62304:2006+A1:2015 is the version that delivers presumption of conformity.

Can I cite IEC 62304:2006 without the A1 amendment in my technical file? No. The harmonised text under MDR is the combined EN 62304:2006+A1:2015. Citing only the 2006 text is incomplete and a Notified Body will flag it. Every reference in a technical file should use the full combined reference.

What exactly does the legacy software clause let me skip? It lets you skip the reconstruction of a full lifecycle history for code that was written before the standard was applied. It does not let you skip risk management, does not let you skip problem resolution, and does not let you skip bringing the software under configuration management from the assessment date forward. It is a structured gap assessment path, not an exemption.

Does the A1 legacy software clause apply to any pre-2015 software, or only to software developed before the 2006 publication? The clause applies to software that was not developed under a lifecycle compliant with the standard — regardless of the calendar date. A research prototype built in 2021 by a team with no QMS qualifies as legacy software under the clause just as much as a product built in 2004. What matters is whether the software was developed under the standard, not when.

Does A1 cover cybersecurity fully? No. A1 made security considerations more visible inside the software lifecycle, but the full cybersecurity lifecycle for health software is now covered by EN IEC 81001-5-1:2022, with guidance from MDCG 2019-16 Rev.1. EN 62304:2006+A1:2015 is the foundation; 81001-5-1 and the MDCG guidance layer on top.

How does the legacy software clause interact with MDR Article 120 legacy device rules? They are different things. MDR Article 120 covers transitional provisions for devices that hold valid certificates under the previous Directives and are still being placed on the market during the transition period — the framework was extended by Regulation (EU) 2023/607. The 62304 legacy software clause is about software that was not developed under the 62304 lifecycle, regardless of whether the device itself is under MDD transition or a new MDR application. A device can be a fully new MDR submission and still contain legacy software under the 62304 A1 clause.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Annex I, Section 17.2. Official Journal L 117, 5.5.2017.
  2. EN 62304:2006+A1:2015 — Medical device software — Software life-cycle processes (IEC 62304:2006 + IEC 62304:2006/A1:2015). Harmonised standard referenced for the software lifecycle under MDR Annex I Section 17.2.
  3. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices. Harmonised standard referenced for risk management under MDR Annex I.
  4. EN IEC 81001-5-1:2022 — Health software and health IT systems safety, effectiveness and security — Part 5-1: Security — Activities in the product life cycle. Harmonised standard referenced for cybersecurity activities under MDR Annex I Section 17.
  5. MDCG 2019-11 Rev.1 — Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 — MDR and Regulation (EU) 2017/746 — IVDR. First published October 2019; Revision 1, June 2025.
  6. MDCG 2019-16 Rev.1 — Guidance on Cybersecurity for medical devices. December 2019; Revision 1, July 2020.

This post is a category-9 spoke in the Subtract to Ship: MDR blog, focused on what IEC 62304 Amendment 1 (2015) changed and why those changes matter for MDR conformity. Authored by Felix Lenhard and Tibor Zechmeister. The MDR is the North Star — EN 62304:2006+A1:2015 is the harmonised tool that provides presumption of conformity with the software-lifecycle aspects of MDR Annex I Section 17.2, not an independent authority. For startup-specific regulatory support on legacy software assessments and EN 62304:2006+A1:2015 implementation, Zechmeister Strategic Solutions is where this work is done in practice.