5 min read

MDD to MDR transition: what it means for medical software manufacturers

From MDD to MDR – why the transition matters

The European regulatory landscape for medical devices has undergone its biggest change in decades. The Medical Device Directive (MDD 93/42/EEC) has been replaced by the Medical Device Regulation (MDR 2017/745) – a transformation designed to strengthen patient safety, traceability, and clinical evidence requirements. For an official summary of these changes, see the European Commission’s MDR overview.

For medical software manufacturers, this shift is more than just paperwork. It redefines how standalone software (used independently) or software as part of a medical device are classified, documented, and placed on the market.

What are the new MDR deadlines?

The MDR entered into full application on 26 May 2021, marking the end of the original transition period from MDD. However, after some time, the European Commission recognised that the medical device certification process was facing growing delays, partly due to an insufficient number of notified bodies.

As of early 2025, there are 44 notified bodies designated under the MDR across the EU, compared to more than 80 under the previous MDD framework (Source: European Commission NANDO Database).

To address this, Regulation (EU) 2023/607, by primarily introducing changes to Article 120 of the MDR, extended the validity of certain MDD certificates if manufacturers met strict conditions:

  • By 26 May 2024 – manufacturers had to submit an application for MDR certification to a notified body and ensure that their quality management system had been updated in line with Article 10(9) MDR.

  • By 26 September 2024 – a contract with the notified body had to be signed.

If both conditions were met, manufacturers are permitted to continue placing devices on the market under MDD certificates until:

Class I devices that do not require notified body involvement (self-certified under MDD) had to comply with MDR from 26 May 2021.

Not all of these deadlines apply to devices that may include software components. Therefore, the focus below is limited to device classes where software can be part of the solution.

What are key conditions for the extension of MDD to MDR transition?

As outlined above, Regulation (EU) 2023/607 introduced extended transition timelines for certain devices, provided manufacturers meet specific conditions such as timely QMS in accordance with MDR application and a signed agreement with a notified body.

Manufacturers can only benefit from the extended transition if:

  • The devices continue to comply with Directive 93/42/EEC,

  • No significant changes were made to the device design or its intended purpose.

  • The devices do not present an unacceptable risk to health or safety.

In practice, this means that even with a valid MDD certificate, you cannot modify your software architecture, algorithms, clinical performance or intended use without triggering MDR compliance.

How does MDR affect medical software classification?

Under MDD, standalone medical software was treated as Class I – low-risk devices self-certified by the manufacturer. MDR’s Rule 11 changed that dramatically.

Industry estimates suggest that approximately 70% of standalone medical software previously self-certified as Class I under MDD now falls into Class IIa or higher under MDR Rule 11 (Source: Team-NB Position Paper – Implementation of MDR Rule 11 for Software, 2023)

This means:

  • More rigorous clinical evaluation and post-market surveillance activities.

  • Greater involvement of notified bodies even for updates and modular releases.

For developers of AI-driven or cloud-based applications, MDR and other regulations such as the AI Act introduce stricter obligations but also new opportunities to prove clinical value and reliability.

Checklist: steps to migration from MDD to MDR

To ensure continuity and compliance, medical software manufacturers should:

  1. Review device classification under MDR Rule 11 most software will move up at least one class.

  2. Engage with a notified body early, especially if you plan to update existing MDD-certified software.

  3. Update the existing quality management system (QMS) to ensure compliance with ISO 13485:2016 and alignment with the requirements of Article 10(9) of the MDR.

  4. Perform a gap analysis between your MDD and MDR documentation, focusing on usability, cybersecurity, and clinical evaluation.

  5. Update your technical documentation to meet MDR standards.

Learn More

Lessons learnt from the MDD to MDR transition

The shift from MDD to MDR has shown that regulatory change is not a single milestone but an ongoing process that deeply affects how medical software is designed and maintained. Many manufacturers initially underestimated the extent of these changes, realising too late that compliance now involves not only technical documentation but also architecture, validation, and post-market responsibilities.

According to MedTech Europe’s 2024 industry survey, only around 52% of MDD certificates had been transitioned or submitted under MDR by mid-2024, highlighting the ongoing backlog across the sector (Source: MedTech Europe – MDR & IVDR Transition Survey Report 2024).

The most successful teams learned that early regulatory planning, close collaboration between R&D and quality departments, and continuous documentation updates are essential to stay ahead.

The transition did not introduce a new rule - it once again proved and reinforced that compliance cannot be retrofitted at the end of development, as this is fundamentally incompatible with a proper lifecycle approach.

How compliance becomes a competitive advantage

While MDR compliance demands time and resources, it has also become a mark of credibility in the medical technology market. A 2024 Deloitte analysis found that MDR implementation costs increased by 30–50% for small and medium-sized manufacturers, mainly due to expanded clinical evaluation and documentation requirements (Source: Deloitte – European MedTech Industry Outlook 2024).

Software that meets MDR standards signals transparency, clinical reliability, and patient safety, values that resonate with healthcare providers, investors, and regulators alike.

By embedding compliance into product strategy, companies not only reduce regulatory risk but also gain long-term scalability, enabling smoother entry into EU markets or others governed by FDA, UKCA, or future AI-specific frameworks.

In this way, compliance evolves from a regulatory obligation into a genuine competitive differentiator that supports sustainable innovation and trust.

Summary for medical software manufacturers

The MDD to MDR transition is not simply an administrative update. MDR redefines how medical software is regulated and perceived. With the extended deadlines (to 2026, 2027 and 2028), manufacturers have more time, but not less responsibility.

Quick recap:

  • MDR fully applies since 26 May 2021.

  • Extended deadlines to Dec 2027 or Dec 2028 apply only if the relevant requirements were met in 2024.

  • Software is now mostly Class IIa or higher.

Compliance requires necessary updates of ISO 13485 QMS, technical documentation, and clinical evaluation.

Key takeaway

Start early, document everything, and treat compliance as part of your product strategy, not a separate checkbox.

FAQ - MDD to MDR transition

What is the main difference between MDD and MDR?

MDR introduces stricter rules for clinical evaluation, post-market surveillance, and software classification, aimed at improving patient safety and device traceability.

When did MDR officially come into effect?

The Medical Device Regulation (EU) 2017/745 became fully applicable on 26 May 2021, replacing the previous MDD framework.

The Medical Device Regulation (EU) 2017/745 became fully applicable on 26 May 2021, replacing the previous MDD framework.

Certificates can remain valid until 31 December 2027 or 31 December 2028, but only if the manufacturer applied for MDR certification by 26 May 2024, updated the QMS in line with MDR requirements, and signed a contract with a notified body by 26 September 2024.

How does MDR Rule 11 change the way medical software is classified?

Under Rule 11, most software used for diagnosis and therapeutic purposes or monitoring now falls under Class IIa or higher, increasing regulatory oversight and the need for notified body involvement.

Can I keep selling my existing software under an MDD certificate?

Yes, but only if no significant design or intended-purpose changes have been made, and the device does not pose an unacceptable risk to patient safety.

What kind of documentation do I need for MDR compliance?

Manufacturers must update their technical documentation (Annex II and III) including clinical evaluation, risk management, cybersecurity, and lifecycle performance data.

When should I contact a notified body for MDR certification?

Engage as early as possible. Delays in scheduling or document review are common due to high demand and limited notified body capacity across the EU.

How will the upcoming EU AI Act affect MDR-certified software?

AI-driven medical software will soon face additional transparency and performance requirements. Aligning MDR documentation with AI Act provisions will help future-proof compliance.

Category:

Tags:

You may also like