EU MDR software requirements

Does the MDR catch your software, and in which class?

Annex VIII Rule 11 decides it, and the answer is usually class IIa or higher. The rule sits at Section 6.3 of Chapter III of Annex VIII, it carries no amendment marker in the consolidated text, and it reads in full:

Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa, except if such decisions have an impact that may cause:

• death or an irreversible deterioration of a person's state of health, in which case it is in class III; or
• a serious deterioration of a person's state of health or a surgical intervention, in which case it is classified as class IIb.

Software intended to monitor physiological processes is classified as class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient, in which case it is classified as class IIb.

All other software is classified as class I.

The last sentence is a residual, reached only once the decision limb and the monitoring limb have both failed to apply. Article 2(4) says software "shall also be deemed to be an active device", which is what puts device software in front of the active device rules in the first place.

Article 51(1) fixes the four classes as I, IIa, IIb and III. Article 52 then turns the class into a cost:

EU MDR software classes I to III by intended purpose, with who assesses conformity under Article 52 for each class.

What the software is intended to do	Class	Who assesses conformity
Provide information used to take a diagnostic or therapeutic decision	IIa	Notified body, Annex IX Chapters I and III, Article 52(6)
The same, where the decision may cause serious deterioration of health or a surgical intervention	IIb	Notified body, Annex IX Chapters I and III, Article 52(4)
The same, where the decision may cause death or irreversible deterioration of health	III	Notified body, Annex IX, or Annex X with Annex XI, Article 52(3)
Monitor physiological processes	IIa	Notified body, Article 52(6)
Monitor vital physiological parameters where variation could bring immediate danger	IIb	Notified body, Article 52(4)
Anything else	I	The manufacturer's own declaration, Article 52(7)

Class I under Article 52(7) means you draw up the technical documentation of Annexes II and III and issue the EU declaration of conformity yourself, with no notified body unless the device is sterile, has a measuring function or is a reusable surgical instrument. Everything from class IIa upward brings an outside assessor into your development records, which is where the timeline and the budget change.

Two implementing rules move a class that Rule 11 appeared to settle. Rule 3.3: "Software, which drives a device or influences the use of a device, shall fall within the same class as the device. If the software is independent of any other device, it shall be classified in its own right." Rule 3.5 says that where several rules or sub-rules apply, "the strictest rule and sub-rule resulting in the higher classification shall apply."

Software qualification and classification under both this Regulation and Regulation (EU) 2017/746 is the subject of MDCG 2019-11 Rev.1, guidance endorsed by the Medical Device Coordination Group, which says of itself that its views are not legally binding and that only the Court of Justice can give binding interpretations of Union law. The parallel page for the other Regulation is IVDR software validation. Where the product is new to the European market, EU MDR software market entry testing sets out the sequence and the timing.

How long does an old Directive certificate keep the product on the market?

Article 120(3a) gives two dates. Devices covered by a valid certificate issued under Directive 90/385/EEC or 93/42/EEC may be placed on the market or put into service until 31 December 2027 for class III devices and for class IIb implantable devices outside a listed set of exceptions, and until 31 December 2028 for other class IIb devices, class IIa devices, and class I devices placed on the market in sterile condition or having a measuring function.

Article 120(3b) covers the case that catches software written under the old Directive: a product self-certified as class I under Directive 93/42/EEC, whose declaration of conformity was drawn up before 26 May 2021, and which now requires notified body involvement. That one runs to 31 December 2028.

The extension is conditional, and Article 120(3c) lists five conditions, (a) to (e). Two of them carry deadlines that have already passed: a quality management system in accordance with Article 10(9) by 26 May 2024, and a formal application lodged with a notified body under Annex VII Section 4.3 by 26 May 2024 with the written agreement signed by 26 September 2024. One of them constrains every release you ship in the meantime, because condition (b) requires that "there are no significant changes in the design and intended purpose". Article 120(3d) adds that the MDR's own post-market surveillance, market surveillance, vigilance and registration requirements already apply to these devices in place of the Directives' equivalents.

Which requirements bind the software itself?

Annex I Section 17, which covers electronic programmable systems and software that are devices in themselves, holds four numbered requirements, 17.1 to 17.4. They are short, and each one is testable.

section 17.1 asks that devices incorporating software, and software that is a device in itself, "be designed to ensure repeatability, reliability and performance in line with their intended use", and that in the event of a single fault condition appropriate means be adopted to eliminate or reduce the consequent risks or impairment of performance.

section 17.2 is the whole of the Regulation's explicit software process obligation, in one sentence: "the software shall 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." It names five things and prescribes a method for none of them.

section 17.3 is narrower than it is usually quoted as being. The Regulation addresses software "intended to be used in combination with mobile computing platforms", and asks that it be designed taking into account the specific features of the mobile platform, giving screen size and contrast ratio as its examples, and the external factors related to their use, giving level of light and noise. The phrase "general computing platform" appears nowhere in Section 17. If your product runs on a desktop browser, 17.3 does not reach it, and 17.1 and 17.2 still do.

section 17.4 requires manufacturers to "set out minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended". The same words come back as an information duty at Annex I 23.4(ab), so whatever you state has to appear in the instructions for use and has to be true of the product you tested.

Section 17 does not stand alone. Annex I Section 3 requires a risk management system running as "a continuous iterative process throughout the entire lifecycle of a device", with six obligations from (a) to (f), and Annex I Section 4 fixes the order in which risks may be controlled: safe design and manufacture first, protective measures second, information for safety third. A warning added to the instructions for use therefore has to be argued against a design change that was available and not taken. How that process is built, and what testing feeds back into it, is covered in ISO 14971 risk management and software testing.

Two more sections reach a user interface directly. Section 5 requires the manufacturer to reduce risks related to use error, taking account of the ergonomic features and of "the technical knowledge, experience, education, training and use environment" of the intended users. Section 22 applies where the user is a lay person, and 22.2 asks for design that reduces as far as possible "the risk of error by the intended user in the handling of the device and, if applicable, in the interpretation of the results".

Does IEC 62304 give you a presumption of conformity here?

It does not, and a good deal of secondary commentary says otherwise.

Article 8(1) is the mechanism: devices in conformity with harmonised standards "the references of which have been published in the Official Journal of the European Union, shall be presumed to be in conformity with the requirements of this Regulation covered by those standards or parts thereof". The second subparagraph extends that presumption to process requirements, including quality management systems, risk management, post-market surveillance and clinical evaluation. The third subparagraph closes the loop: a reference in the Regulation to a harmonised standard means one whose reference has been published in the Official Journal.

The list is Commission Implementing Decision (EU) 2021/1182 of 16 July 2021, and its Annex holds no software standard. The Annex was read entry by entry in the consolidated version as at 7 April 2026, and a search of the full Decision for 62304, 82304, 62366 and the word "software" returned nothing. The finding was re-checked on 2 September 2026 against the European Commission's own harmonised standards page, which names Commission Implementing Decision (EU) 2026/1231 of 11 June 2026 as the most recent amendment. Its subject matter is biological evaluation, symbols, medical electrical equipment, transfusion equipment, ophthalmic optics, non-active surgical implants, washer-disinfectors, prosthetics and sharps injury protection, and it adds no software standard either.

The process standards a software submission leans on are all listed. EN ISO 13485:2016, EN ISO 14971:2019 and EN ISO 14155:2020 appear in that Annex with their amendments. The software life cycle standard does not.

None of this reduces what the Regulation asks of software. It removes one shortcut through Article 8(1) and leaves the obligations in Annex I, Annex II and Article 61 where they were.

What does the MDR ask you to test?

Annex II Section 6.1(b) is the only place in the Regulation that says what software test evidence has to look like. Its fourth indent, in full:

software verification and validation (describing the software design and development process and evidence of the validation of the software, as used in the finished device. This information shall typically include the summary results of all verification, validation and testing performed both in-house and in a simulated or actual user environment prior to final release. It shall also address all of the different hardware configurations and, where applicable, operating systems identified in the information supplied by the manufacturer)

Three obligations sit inside that sentence, and each one is a separate piece of work. The process description is required alongside the results, so a folder of test reports with no account of how the software was developed answers half the indent. Testing in a simulated or actual user environment is named beside in-house testing, which makes a rig standing in for the clinical setting part of the evidence the section expects. Coverage has to span every hardware configuration and operating system named in the information supplied with the device, which turns the platform list in your instructions for use into a test matrix you have to fill.

section 6.1(b) lists six subject areas in total: biocompatibility; physical, chemical and microbiological characterisation; electrical safety and electromagnetic compatibility; software verification and validation; stability including shelf life; and performance and safety. For standalone software several of those are inapplicable, and the section closes with the sentence that decides what to do about it: "Where no new testing has been undertaken, the documentation shall incorporate a rationale for that decision." Leaving a subject area empty draws a finding, and the written rationale is what closes it.

Where the software works with other devices, Section 6.2(g) requires a description of the combination or configuration "including proof that it conforms to the general safety and performance requirements when connected to any such device(s)". For a device shipped onto a network its manufacturer does not control, that proof has to be produced for configurations the customer assembles. Article 2(26) defines interoperability in three limbs, one of which is exchanging information "for the correct execution of a specified function without changing the content of the data". That is a property an interface test demonstrates rather than assumes.

Clinical evidence is a separate obligation and it does not disappear for software. Article 5(3): "Demonstration of conformity with the general safety and performance requirements shall include a clinical evaluation in accordance with Article 61." Annex XIV Part A Section 2 sets the standard of effort, requiring depth and extent "proportionate and appropriate to the nature, classification, intended purpose and risks of the device". Its Section 3 lists the equivalence criteria and names "software algorithms" inside the technical limb, so equivalence to another product is argued at the level of the algorithm rather than the feature list.

Which artefacts will the notified body ask for?

The technical documentation of Annex II, which the Annex requires to be presented "in a clear, organised, readily searchable and unambiguous manner". The items a software product has to fill:

EU MDR Annex II technical documentation items a software product has to fill, with what each item holds for software.

Annex II item	What it holds for software
Section 1.1(f)	The risk class and the justification of the Annex VIII rule applied, where the Rule 11 argument is written down
Section 1.1(j)	The key functional elements, including software components
Section 4	The GSPR table: which requirements apply, why the others do not, the method used for each, the solutions applied, and where the evidence sits
Section 5	The benefit-risk analysis and the results of the risk management under Annex I Section 3
Section 6.1(b)	Software verification and validation, covering process, results, user environment and every claimed platform
Section 6.1(c)	The clinical evaluation plan and the clinical evaluation report
Section 6.1(d)	The post-market clinical follow-up (PMCF) plan and the PMCF evaluation report, or a justification why PMCF does not apply
Section 6.2(g)	Proof of conformity in each configuration the device is connected in

Article 84 puts one more document into the same file: the post-market surveillance plan, whose requirements are set out in Section 1 of Annex III, "shall be part of the technical documentation specified in Annex II". Article 83(3) lists eight uses the surveillance data has to be put to and closes with the sentence that fixes the maintenance duty: "The technical documentation shall be updated accordingly."

Article 86 sets the reporting rhythm by class. Class IIb and class III manufacturers update the periodic safety update report at least annually, class IIa manufacturers when necessary and at least every two years. Article 87 sets the vigilance clock at 15 days for a serious incident, 10 days where there has been a death or an unanticipated serious deterioration in health, and 2 days for a serious public health threat. Building those windows into a triage process costs less before the first incident than after it. What each of these documents has to contain is covered in validation documentation.

Where do MDR software files fail?

• The classification rationale required by Section 1.1(f) states a class and gives no reasoning against the first paragraph of Rule 11, so the assessor reconstructs the argument and often disagrees with it.
• The instructions for use claim a list of operating systems, and the test evidence covers the one build the team develops on, which is the coverage Section 6.1(b) names explicitly.
• Nothing under Section 6.1(b) runs in a simulated or actual user environment, because in-house testing is read as the whole of the indent.
• The GSPR table names IEC 62304 under Section 4 item (c) as a harmonised standard, which it is not, and item (d) carries no evidence locations to fall back on.
• The minimum hardware, network and IT security requirements are written into the instructions for use under 23.4(ab) and never verified against the product, so GSPR 17.4 rests on a claim rather than on a record.
• Subject areas in Section 6.1(b) are left blank in place of the written rationale the section asks for.
• Post-market data is collected and reaches no document, so the clinical evaluation and the technical documentation still read as they did at certification, against Article 61(11) and Article 83(3).

What do we run against the MDR?

We start from the intended purpose, because Article 2(12) makes it the input to classification and Rule 11 makes classification the input to everything else. From there the work is the Annex II file: a GSPR table with a method against every applicable requirement, a test suite that covers each claimed platform and each connected configuration, execution in a simulated user environment as well as in-house, and the written rationale wherever a subject area is not applicable.

What the testing produces is the artefact list above, indexed the way Section 4 item (d) asks for, so an assessor moves from a requirement to the record without being walked through it. The testing itself is described in medical device software testing. Teams preparing for both markets at once usually start from EU MDR compared with FDA software requirements, because the two files share evidence and disagree about structure.

Article, annex and rule numbers on this page were read in the official consolidated text of Regulation (EU) 2017/745 as at 1 January 2026, served by the EU Publications Office at publications.europa.eu. The harmonised standards finding was read in Commission Implementing Decision (EU) 2021/1182 as consolidated at 7 April 2026 and re-checked on 2 September 2026.