--- title: Legacy Software Under MDR: How to Bring Existing Software into Compliance description: Legacy software under MDR can be brought into compliance using the Section 8 legacy path. Here is the process for retroactive documentation. authors: Tibor Zechmeister, Felix Lenhard category: Software as a Medical Device primary_keyword: legacy software MDR compliance canonical_url: https://zechmeister-solutions.com/en/blog/legacy-software-mdr-compliance source: zechmeister-solutions.com license: All rights reserved. Content may be cited with attribution and a link to the canonical URL. --- # Legacy Software Under MDR: How to Bring Existing Software into Compliance *By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.* > **Legacy software under MDR is software that was already in clinical use before the manufacturer adopted a compliant lifecycle, and that now has to be brought under the obligations of MDR Annex I Section 17 without being rewritten from scratch. EN 62304:2006+A1:2015 provides an explicit path for this case in Section 8, which allows the manufacturer to treat software developed outside the standard as legacy software and to establish compliance through a gap analysis, a retrospective risk assessment, and targeted remediation rather than through a full retroactive lifecycle. The legal obligation still comes from MDR Annex I Section 17. The Section 8 process is how the harmonised standard lets you discharge that obligation on code you did not write under the standard in the first place.** **By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.** --- ## TL;DR - Legacy software is software that was already placed on the market or already in clinical use before the manufacturer ran a compliant lifecycle under EN 62304:2006+A1:2015. - EN 62304:2006+A1:2015 Section 8 defines the legacy software process: gap analysis, risk assessment of the gaps, remediation plan, and ongoing maintenance under the standard from that point forward. - The legacy path does not exempt the software from MDR Annex I Section 17. It provides a defensible route to discharge the Annex I obligations on code that was not written under the standard from day one. - A retrospective risk assessment under EN ISO 14971:2019+A11:2021 is the core deliverable. It determines which gaps matter, which have to be remediated, and which can be accepted with justification. - The transitional provisions of Regulation (EU) 2023/607 extended the MDR deadlines for legacy devices that meet specific conditions, but they did not suspend Section 17 for software lifecycle obligations. - Reconstruction of documentation is permitted under Section 8 provided the manufacturer is honest about what is reconstructed and what was original. Fabricated lifecycle records are the fastest way to lose a Notified Body's trust. - Common mistakes are treating Section 8 as a one-time cleanup, confusing MDR transitional timing with software lifecycle compliance, and building a reconstructed paper trail that does not match the code. --- ## The legacy software problem Every startup that has been shipping software for a few years before deciding to certify arrives at the same uncomfortable moment. The product works. The users are real. There may even be revenue. But the lifecycle documentation EN 62304:2006+A1:2015 expects. Planning, requirements, architecture, design, verification evidence, configuration management, problem resolution, risk management. Was not produced alongside the code. Some of it exists in the form of tickets, pull requests, and commit history. Some of it exists in the founders' heads. Much of it does not exist in any form at all. The temptation is to pick one of two extremes. Either rewrite the software under a compliant lifecycle from scratch, which wastes the working code and the clinical track record. Or reconstruct a full lifecycle on paper after the fact and pretend the documents were written alongside the code, which does not survive a serious Notified Body audit and puts the whole certification at risk. Neither is the right move. The right move is the legacy software path. EN 62304:2006+A1:2015 recognises that software existed before the standard did, and that the standard had to offer a realistic route for manufacturers to bring pre-existing code under the lifecycle without throwing away the investment. That route is Section 8. It is the part of the standard founders read last and need first. ## EN 62304:2006+A1:2015 Section 8. What it says Section 8 of EN 62304:2006+A1:2015 is titled Software problem resolution process, and Amendment 1:2015 added the legacy software provisions as part of the amendment's expansion of the standard's scope. The legacy software provisions recognise that software developed before the manufacturer adopted the standard. Or before the standard existed. Can be brought under the lifecycle through a defined process rather than through full retroactive application of every clause. The legacy process has four pillars. A gap analysis that compares the existing state of the software and its documentation against the requirements of the standard. A risk assessment of the gaps under EN ISO 14971:2019+A11:2021, asking what the gaps mean for patient safety. A remediation plan that addresses the gaps the risk assessment determines have to be closed. And continuing maintenance under the standard from that point forward, so the legacy state is a single historical event and not a permanent workaround. The standard does not require that every clause of the full development lifecycle be retroactively applied to legacy code. It requires that the manufacturer can demonstrate, through the gap analysis and the retrospective risk assessment, that the current state of the software is safe, defensible, and under control, and that the future state is governed by the standard in full. The legacy designation is the mechanism that makes this possible. The legal obligation remains MDR Annex I Section 17. 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 Section 8 legacy process is the state-of-the-art answer for how to discharge Section 17.2 on code that existed before the lifecycle did. ## The retrospective risk assessment The single most important deliverable in the legacy process is the retrospective risk assessment. Everything else. The gap analysis, the remediation plan, the decision about which evidence to reconstruct and which to accept as missing. Flows from it. Done well, it is the document that convinces a Notified Body that the manufacturer understands their software, knows where the weaknesses are, and has made defensible choices about what to fix. The retrospective risk assessment runs under EN ISO 14971:2019+A11:2021. It identifies the hazards that the software can contribute to, analyses them against the known behaviour of the software in clinical use, and evaluates whether the risk controls inside the software are adequate given what is known about the code. The key difference from a fresh risk assessment is that the legacy assessment has real-world data to work with. Bug reports, field observations, clinical outcomes, support tickets, known limitations. That data is evidence the Notified Body will expect to see incorporated. Ignoring it and running a theoretical risk assessment from the requirements outward is the wrong move for legacy code. The assessment produces a ranking of the identified gaps by risk contribution. Gaps that contribute to hazards where the possible harm is serious get addressed first. Gaps that contribute to low-severity issues or are covered by external controls can be documented and accepted with justification. This ranking is what drives the remediation plan and what lets the manufacturer defend their scope of work to the Notified Body. ## The gap analysis The gap analysis is the systematic comparison of the current state against the requirements of EN 62304:2006+A1:2015 clause by clause. For each clause, the manufacturer records what exists today, what does not exist, and whether what exists is adequate. The analysis is a structured document, not a narrative. Categories of gaps that typically appear in startup legacy code. A software development plan that was never written. Requirements that live in tickets and pull request descriptions but not in a traceable requirements specification. Architecture that exists in the code and in the team's shared understanding but not in an architecture document. Detailed design that exists only as source code comments. Unit test coverage that is partial. Integration test coverage that is ad hoc. System testing that was done but not against a documented specification. Configuration management in Git that is real but not formalised as the configuration management approach. Problem resolution in a ticket system that is real but not linked to release decisions and risk management. Risk management that either does not exist or exists as a one-time document and not as an integrated process. Each gap gets a description, a clause reference to the standard, a status (exists, partial, missing), and a preliminary risk note. The preliminary risk note is what feeds the retrospective risk assessment. The gap analysis and the risk assessment run iteratively. The risk assessment may reveal that a gap initially classified as partial is actually significant, or that a gap initially classified as missing is covered by an external control and does not need full remediation. ## What has to be documented The legacy path does not give the manufacturer permission to ship with missing documentation forever. It gives the manufacturer permission to reach the required documentation state through a different route than full retroactive lifecycle application. By the end of the legacy process, the following must exist. A software development plan that governs the software from the legacy date forward. The plan describes the lifecycle the team runs now, including how maintenance, changes, and problem resolution are handled. A requirements specification that covers the current functional and safety-relevant behaviour of the software, even if the specification is produced by analysing the existing code rather than by forward-engineering from system requirements. An architecture document that describes the software items as they currently exist, with the identification of which items contribute to hazardous situations and which do not. A risk management file that integrates the retrospective risk assessment and ties it to the software safety classification of each item under EN 62304:2006+A1:2015. A verification and validation position that describes how the current software has been tested, what evidence exists from the historical testing, and what additional verification was run as part of the legacy remediation. A configuration management description that matches what the team actually does. A problem resolution process that is running and that links anomalies to risk management and release decisions. The principle is that the documentation describes the software as it currently is and as it will be maintained from now on. It does not have to pretend the documentation was written alongside the original code. Honesty about what is reconstructed is a feature of the legacy process, not a bug. ## What can be grandfathered Not every gap has to be closed. The standard's legacy provisions permit gaps to be accepted when the retrospective risk assessment demonstrates that the gap does not contribute to unacceptable risk. The decision to accept a gap is a risk-management decision with documented justification, not an administrative shortcut. Examples of gaps that can often be accepted with justification. Unit tests that do not exist for legacy modules whose behaviour has been validated through extensive clinical use and for which integration and system test coverage is adequate to the software safety class. Design documentation at the unit level for Class B items where the standard permits design at the item level. Historical problem resolution records that predate the legacy transition, where the current problem resolution process is running from the transition date forward and the historical bugs have been evaluated against the current risk file. Internal development artefacts that never existed, where the current maintenance process covers the same ground going forward. Examples of gaps that cannot be accepted and must be remediated. Any gap in a Class C item where the software can contribute to death or serious injury. Risk management that does not cover the current state of the software. Configuration management that cannot reproduce the current release from source. Verification evidence that the current release meets the current requirements. These are the non-negotiable pieces. The rest of the legacy process is about defending the rest of the file around them. ## The transition timing The transitional provisions of Regulation (EU) 2023/607 extended the MDR deadlines for certain legacy devices that meet specific conditions, giving manufacturers additional time to complete conformity assessment under the MDR for devices that previously held certificates under the old Directives. (Regulation (EU) 2023/607.) That extension is about the certificate-level deadline. It is not a suspension of MDR Annex I Section 17 for the software lifecycle. A legacy device benefiting from the extended deadline still has to satisfy Annex I Section 17 when it is certified under the MDR, and EN 62304:2006+A1:2015 Section 8 is still the path for the software inside that device. The transitional provisions give the manufacturer more calendar time. They do not change the substantive lifecycle requirement the software has to meet when the certification project runs. The two timelines to track separately. The device certification deadline under the transitional provisions. And the software lifecycle remediation timeline the manufacturer sets for themselves to complete the Section 8 legacy process before the Notified Body audit. These are different projects and should be planned as such. ## Common mistakes The legacy process is well-defined but easy to do badly. The mistakes we see repeatedly. Treating Section 8 as a one-time cleanup and then reverting to undocumented development. The legacy provisions apply to the transition from non-compliant to compliant, not to ongoing development. After the legacy remediation, the team runs the full lifecycle. Reconstructing documentation that does not match the code. Writing a requirements specification that describes what the code should do rather than what it does, or an architecture document that reflects the team's preferred design rather than the actual structure. Notified Bodies can tell. They read the code along with the document. Confusing the MDR transitional certificate extension with a suspension of Section 17. The extension changes when the certificate has to be issued under MDR. It does not change what has to be true about the software lifecycle when the certificate is issued. Running the retrospective risk assessment without using the field data. Legacy software has real clinical history. Bug reports, support tickets, known issues, user feedback. Ignoring that data and running the risk assessment from a theoretical starting point wastes the single biggest advantage legacy code has over new code. Assuming grandfathering applies to Class C items where the software contributes to serious harm. It does not. Class C gaps get remediated, not accepted. Building a legacy file in isolation from the team that actually maintains the software. The lifecycle has to be executable by the engineering team on an ongoing basis. A file that only the regulatory lead understands will not survive the first maintenance release. ## The Subtract to Ship angle Legacy software is a subtraction-heavy category. The default is to reconstruct everything the standard mentions, producing a mountain of retrospective documentation that nobody reads and that does not match the code. The Subtract to Ship move is to let the retrospective risk assessment decide what has to exist and to cut everything that the assessment does not force into the file. The subtractions that work. Reconstruct documentation only for the software items that the risk assessment identifies as safety-relevant. Accept gaps with documented justification wherever the standard's legacy provisions allow. Use the existing ticket and commit history as the raw material for the reconstructed file rather than writing parallel documents from scratch. Scope the medical module narrowly so the legacy remediation covers the smallest defensible code base. The same principle that applies to fresh software lifecycles applies even more strongly to legacy ones, because reconstruction is more expensive than original work. Integrate the legacy risk assessment into the existing EN ISO 14971:2019+A11:2021 risk file instead of maintaining a parallel legacy file. Every activity in the legacy remediation traces back to MDR Annex I Section 17 through EN 62304:2006+A1:2015 Section 8. Activities that do not trace come out. For the broader framework applied to MDR, see post 065. ## Reality Check. Is your legacy software remediation defensible? 1. Have you produced a structured gap analysis that compares your current software and documentation state against every applicable clause of EN 62304:2006+A1:2015? 2. Have you run a retrospective risk assessment under EN ISO 14971:2019+A11:2021 that uses the real field data from your clinical history, not a theoretical model? 3. Does your risk assessment rank the gaps by risk contribution, so the remediation plan addresses the highest-risk gaps first? 4. For every gap you have decided to accept, is there a documented risk-based justification in the file? 5. Have you assigned the software safety class. A, B, or C. To each software item, and have you remediated all Class C gaps without relying on acceptance? 6. Does the reconstructed documentation describe the software as it actually is, rather than as you wish it had been built? 7. Is the problem resolution process running from the legacy transition date forward, linked to risk management and release decisions? 8. Is your team running the full lifecycle from the legacy transition date, not reverting to undocumented development after the remediation is finished? 9. Have you separated the MDR transitional certificate timeline from the software lifecycle remediation timeline in your planning? 10. Would the Notified Body reviewing your file be able to match the reconstructed documentation to the actual code base on inspection? Any question you cannot answer with a clear yes is a gap in the legacy remediation itself. The earlier you find it, the cheaper it is to close. ## Frequently Asked Questions **What is legacy software under EN 62304:2006+A1:2015?** Legacy software is software that was developed before the manufacturer adopted a compliant lifecycle under EN 62304:2006+A1:2015, and that now has to be brought under the standard without being rewritten from scratch. Amendment 1:2015 added the legacy software provisions in Section 8 of the standard, which define the gap analysis, retrospective risk assessment, and remediation process for this case. **Does the legacy path exempt software from MDR Annex I Section 17?** No. MDR Annex I Section 17 applies to all software in or as a medical device regardless of when it was written. The legacy path is the route by which EN 62304:2006+A1:2015 lets the manufacturer discharge the Section 17 obligations on pre-existing code, but the obligation itself is not suspended or reduced. **Can I reconstruct documentation for legacy software and present it as original?** No. The legacy process permits reconstruction of documentation, but the reconstruction has to be honest about what was produced retrospectively and what existed originally. Notified Bodies can detect fabricated original documentation, and the loss of trust is far more damaging than the reconstructed status itself. **Does Regulation (EU) 2023/607 suspend the software lifecycle requirements for legacy devices?** No. Regulation (EU) 2023/607 extended the MDR transitional deadlines for certain legacy devices holding certificates under the former Directives, but it did not suspend the substantive lifecycle requirements of MDR Annex I Section 17. When the legacy device is certified under the MDR, Section 17 applies in full, and EN 62304:2006+A1:2015 Section 8 is still the path for the software inside it. **Which gaps can be accepted and which have to be remediated?** Gaps that do not contribute to unacceptable risk under the retrospective risk assessment can be accepted with documented justification. Gaps in Class C software items where the software can contribute to death or serious injury cannot be accepted and must be remediated. Risk management that does not cover the current state of the software, configuration management that cannot reproduce the current release, and verification evidence against the current requirements are all non-negotiable. **How long does legacy software remediation typically take for a startup?** It depends on the size of the code base, the software safety class of the items, and how much of the existing engineering practice already maps to the standard. For a small startup with a focused medical module and an engineering team already running Git with CI and structured tickets, the remediation can be weeks. For a larger code base with no existing discipline, it can be months. The retrospective risk assessment typically takes the longest because it is the hardest to do well. ## Related reading - [MDR Software Lifecycle Requirements: How IEC 62304 Helps You Demonstrate Conformity](/blog/mdr-software-lifecycle-iec-62304) – the foundational post on the lifecycle obligations this legacy path discharges. - [EN 62304 Software Safety Classification A, B, C](/blog/software-safety-classification-iec-62304) – the classification that drives which gaps can be accepted and which must be remediated. - [Software Release Process Under EN 62304](/blog/software-release-process-iec-62304) – the release gate the legacy remediation has to reach before ongoing development resumes. - [Software Maintenance Under EN 62304](/blog/software-maintenance-en-62304) – the process the team runs from the legacy transition date forward. - [Software Change Control Under EN 62304](/blog/software-change-control-en-62304) – how changes are handled once the legacy remediation is complete. - [Software Unit Verification Under EN 62304](/blog/software-unit-verification-en-62304) – verification activities required at the item and unit level. - [SOUP. Software of Unknown Provenance Under EN 62304](/blog/soup-software-unknown-provenance-en-62304) – the related case for third-party components inside the legacy code base. - [How MDR Transitional Provisions Work Under Regulation (EU) 2023/607](/blog/mdr-transitional-provisions-2023-607) – the device-level deadline extension and how it interacts with lifecycle obligations. - [The Graz Over-Documentation Trap](/blog/graz-over-documentation-trap) – the failure mode legacy remediation is most vulnerable to. - [The Subtract to Ship Framework for MDR Compliance](/blog/subtract-to-ship-framework-mdr) – the methodology pillar this post applies to legacy software remediation. ## 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 and Section 17.2. Official Journal L 117, 5.5.2017. 2. Regulation (EU) 2023/607 of the European Parliament and of the Council of 15 March 2023 amending Regulations (EU) 2017/745 and (EU) 2017/746 as regards the transitional provisions for certain medical devices and in vitro diagnostic medical devices. 3. EN 62304:2006+A1:2015. Medical device software. Software life-cycle processes (IEC 62304:2006 + IEC 62304:2006/A1:2015), Section 4.4 and Section 8 (legacy software provisions introduced by Amendment 1:2015). 4. 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. 5. EN ISO 13485:2016+A11:2021. Medical devices. Quality management systems. Requirements for regulatory purposes. --- *This post is a category-9 spoke in the Subtract to Ship: MDR blog, focused on the legacy software path inside the software lifecycle obligations under MDR Annex I Section 17. Authored by Felix Lenhard and Tibor Zechmeister. The MDR is the North Star for every claim in this post. EN 62304:2006+A1:2015 Section 8 is the harmonised tool that provides a defensible route for legacy code, not an independent authority. For startup-specific regulatory support on legacy software remediation, gap analysis, and retrospective risk assessment, Zechmeister Strategic Solutions is where this work is done in practice.* --- *This post is part of the [Software as a Medical Device](https://zechmeister-solutions.com/en/blog/category/samd) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*