The Medical Device Regulation (EU) 2017/745 (MDR) has applied since 26 May 2021, yet software manufacturers are still working through what it means in practice. Rule 11 moved most diagnostic and therapeutic software out of class I, legacy certificates are approaching the end of their extended transition, the AI Act now sits alongside the MDR, and the Commission has proposed a targeted revision of the MDR itself. This guide sets out what the europe MDR regulation requires of software manufacturers today, and what is still only a proposal.
Background and key dates
The MDR was adopted on 5 April 2017 and entered into force on 25 May 2017. It was due to apply from 26 May 2020, but Regulation (EU) 2020/561 postponed that by one year to 26 May 2021 (European Commission: MDR overview). It replaced Directive 90/385/EEC on active implantable medical devices and Directive 93/42/EEC on medical devices (MDD). As a regulation, it applies directly in every Member State.
Devices certified under the old directives can stay on the market for longer under Regulation (EU) 2023/607, subject to conditions. The transition ends on 31 December 2027 for class III and most class IIb implantable devices, and on 31 December 2028 for other class IIb, class IIa, class I sterile or measuring devices and devices that need a notified body for the first time under the MDR. The manufacturer had to apply to a notified body by 26 May 2024 and sign a written agreement by 26 September 2024, and the device must not have undergone significant changes in design or intended purpose (European Commission factsheet).
For software, one category matters most. Software that was class I under the MDD but needs a notified body under the MDR can benefit from the extension to 31 December 2028, but only if its declaration of conformity was drawn up before 26 May 2021. New software, and legacy software that has changed significantly, must comply with the MDR in full.
Qualification and classification of software
Two questions come first. Is the software a medical device at all, and if so, which class? Both turn on the intended purpose stated by the manufacturer, not on the technology. The MDCG's guidance on qualification and classification of software, MDCG 2019-11, is the main interpretive reference (MDCG guidance documents).
Classification of software is governed by Rule 11 in Annex VIII:
| Software intended to… | Class | Exception |
|---|---|---|
| Provide information used to take decisions with diagnostic or therapeutic purposes | IIa | III if the decisions may cause death or an irreversible deterioration of health; IIb if they may cause a serious deterioration of health or a surgical intervention |
| Monitor physiological processes | IIa | IIb if it monitors vital physiological parameters where variations could result in immediate danger to the patient |
| Anything else | I |
The practical effect is that very little clinical decision-support software stays in class I. A change in the wording of the intended purpose, for example from "displays trends" to "identifies patients at risk", can move a product up a class and bring in a notified body. Our guide to medical device classification across the EU and US covers the other rules in Annex VIII.
Core obligations for manufacturers
Article 10 sets out the general obligations. For a software manufacturer, they translate into the following:
| Obligation | What it requires | MDR reference |
|---|---|---|
| Quality management system | A QMS proportionate to the risk class and type of device | Article 10(9) |
| Risk management | A documented risk management system across the lifecycle | Article 10(2); Annex I |
| General safety and performance requirements | Evidence against each applicable GSPR, including the software requirements in Annex I, Section 17 | Annex I |
| Clinical evaluation | A clinical evaluation, updated with post-market data | Article 61; Annex XIV |
| Technical documentation | A technical file and post-market surveillance documentation | Annexes II and III |
| Person responsible for regulatory compliance | At least one PRRC; micro and small enterprises can have one permanently and continuously at their disposal | Article 15 |
| Declaration of conformity and CE marking | Drawn up after the conformity assessment | Articles 19 and 20 |
| UDI and registration | Basic UDI-DI and UDI-DI assignment and registration | Articles 27 and 29 |
| Post-market surveillance and vigilance | A PMS system, PMS report or PSUR, and incident reporting | Articles 83 to 88 |
Two points are often misread. First, the PRRC requirement applies to all manufacturers, not only those of higher-risk devices. Our article on the role of the PRRC covers what that person is responsible for. Second, the summary of safety and clinical performance (SSCP) applies to implantable and class III devices (Article 32), so most SaMD does not need one.
Annex I, Section 17 contains the software-specific requirements. Software must be designed to ensure repeatability, reliability and performance in line with its intended use. It must be developed and manufactured according to the state of the art, taking into account the principles of the development lifecycle, risk management including information security, verification and validation. Our article on SaMD technical documentation explains how to structure that evidence.
Software versions and UDI
The MDR has explicit rules for software versions in Annex VI, Part C, Section 6.5:
A new UDI-DI is required whenever a modification changes the original performance, the safety or the intended use of the software, or the interpretation of data. The MDR gives examples: new or modified algorithms, database structures, operating platform, architecture, new user interfaces or new channels for interoperability.
Minor software revisions require a new UDI-PI, not a new UDI-DI. These are generally bug fixes, usability enhancements that are not for safety purposes, security patches or operating efficiency improvements.
For AI-enabled software, that means each model update has to be assessed against these criteria before release. A retrained model that changes performance is not a minor revision. The EUDAMED and UDI registration checklist covers how to keep those identifiers aligned with the registration data.
Post-market surveillance
The MDR treats post-market surveillance as part of the technical documentation (Annex III), not as a separate activity. The reporting obligation depends on class:
| Class | Report | Update frequency | MDR reference |
|---|---|---|---|
| I | Post-market surveillance report | Updated when necessary | Article 85 |
| IIa | Periodic safety update report (PSUR) | When necessary and at least every two years | Article 86 |
| IIb and III | PSUR | At least annually | Article 86 |
Serious incidents and field safety corrective actions are reported under Article 87, and statistically significant increases in non-serious incidents or expected side effects under Article 88. Post-market clinical follow-up (PMCF) is set out in Annex XIV, Part B, and the PMS plan must contain either a PMCF plan or a justification for why PMCF is not applicable (Annex III).
For software, the PMS plan should define what performance data will be monitored in the field, which thresholds trigger an investigation, and how findings feed back into the risk management file and clinical evaluation.
The MDR and the AI Act
AI-enabled medical devices are also covered by the AI Act, Regulation (EU) 2024/1689. Medical devices and IVDs are listed in Annex I of the AI Act, and an AI system that is a medical device, or a safety component of one, is high-risk under Article 6(1) where the device has to undergo third-party conformity assessment. For most software, that means any device in class IIa or above.
The timing has changed. Regulation (EU) 2026/1744 amended the AI Act so that the high-risk requirements in Chapter III, Sections 1 to 3, apply from 2 August 2028 to AI systems that are high-risk under Article 6(1) and Annex I, which includes medical devices (Regulation (EU) 2026/1744). For stand-alone high-risk systems under Annex III, the date is 2 December 2027.
In practice, the AI Act requirements on data governance, record-keeping, transparency, human oversight, accuracy and robustness should be built into the same QMS, risk management file and technical documentation as the MDR evidence, not into a second, parallel file. Our overview of the AI Act, MDR and IVDR covers how the two frameworks overlap.
What may change: the 2025 revision proposal
On 16 December 2025, the Commission proposed a targeted revision of the MDR and IVDR, COM(2025) 1023 (European Commission: MDR overview). The proposal must still be adopted by the European Parliament and the Council through the ordinary legislative procedure, and until then the current MDR applies in full.
For SaMD, two elements of the proposal stand out: a revised Rule 11, and a reduced application of the AI Act to devices already regulated under the MDR and IVDR. Leon Doorn analyses both in The EU Commission's proposed implications on SaMD and AI-enabled devices. Manufacturers should plan against the regulation as it stands and track the proposal as it moves through Parliament and Council.
A hypothetical SaMD example
Hypothetical example: a German company develops cloud software that analyses ECG recordings and flags suspected atrial fibrillation for review by a cardiologist.
The output informs a diagnostic decision, so Rule 11 applies. The company concludes the software is class IIa, documenting why a missed or false flag would not be expected to cause a serious deterioration of health, given the cardiologist's review. A notified body is therefore needed. Because the device is class IIa and uses machine learning, it will also be high-risk under the AI Act from 2 August 2028.
The technical documentation covers the Annex I, Section 17 requirements, and the clinical evaluation follows Article 61 and Annex XIV. The company sets out in advance which model changes count as a new UDI-DI and which as a minor revision under Annex VI. Its PMS plan monitors sensitivity and specificity in the field, and its PSUR is updated at least every two years.
Conclusion
The europe MDR regulation asks software manufacturers to connect intended purpose, classification, technical documentation, clinical evaluation and post-market surveillance into one controlled system. For SaMD, Rule 11, Annex I Section 17 and the software UDI rules in Annex VI are the provisions that shape most decisions. The AI Act adds a second layer from August 2028, and the 2025 revision proposal may change parts of the framework, but neither changes what a manufacturer has to demonstrate today.
If you need support with MDR classification or technical documentation for software, our regulatory strategy team can help, or contact MedQAIR.
Frequently asked questions
When did the MDR start to apply?
The MDR has applied since 26 May 2021. It entered into force on 25 May 2017, and Regulation (EU) 2020/561 postponed its original date of application of 26 May 2020 by one year.
How is software classified under the MDR?
Under Rule 11 of Annex VIII. Software that provides information for diagnostic or therapeutic decisions is class IIa, rising to IIb or III depending on the possible impact of those decisions. Software that monitors physiological processes is IIa, or IIb for vital parameters where variations could cause immediate danger. All other software is class I.
Can legacy MDD software stay on the market?
Only under the conditions of Regulation (EU) 2023/607. For software that needs a notified body for the first time under the MDR, the transition runs to 31 December 2028, provided the declaration of conformity was drawn up before 26 May 2021, the manufacturer applied to a notified body by 26 May 2024 and signed an agreement by 26 September 2024, and there are no significant changes in design or intended purpose.
Does every software update need a new UDI-DI?
No. A new UDI-DI is required when a change affects the original performance, safety, intended use or interpretation of data. Minor revisions such as bug fixes, security patches and non-safety usability improvements need a new UDI-PI instead (Annex VI, Part C, Section 6.5).
Does every SaMD manufacturer need a PRRC?
Yes. Article 15 applies to all manufacturers. Micro and small enterprises do not need the PRRC within their organisation, but must have one permanently and continuously at their disposal.
When does the AI Act apply to AI-enabled medical devices?
For AI systems that are high-risk because they are medical devices requiring third-party conformity assessment, the high-risk requirements apply from 2 August 2028, following Regulation (EU) 2026/1744.
