The MDR (Regulation (EU) 2017/745 of 5 April 2017) requires risks to be acceptable "taking into account the generally acknowledged state of the art" (Annex I Section 1). It does not define the term. MDCG 2021-5 Rev.1 (July 2024) states that "state of the art" is not a legally defined concept. The latest references of harmonised standards under the MDR were published by Commission Implementing Decision (EU) 2026/1231 of 11 June 2026.
The benchmark keeps moving after certification. This article explains where the MDR uses the term, how MDCG guidance describes it, how harmonised standards relate to it, and what it means in practice for software manufacturers.
Where the MDR uses "state of the art"
| Provision | Wording or summary | Source |
|---|---|---|
| Annex I Section 1 | "taking into account the generally acknowledged state of the art" | MDCG 2019-16 section 2.2; MDCG 2020-6 section 6.5(c) |
| Annex I Section 4 | Risk control measures must follow the same safety principles, taking the state of the art into account (paraphrased) | MDCG 2019-16 |
| Annex I Section 17.2 | 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" | MDCG 2019-16 section 2.1 |
| Annex XIV Part A Section 1(a) | Clinical evaluation planning "based on the state of the art in medicine" | MDCG 2020-6, footnote 49 |
| Article 1(2), Annex XVI products | "taking into account the state of the art, and in particular existing harmonised standards for analogous devices with a medical purpose, based on similar technology" | MDR Article 1(2) |
Sources: MDR; MDCG 2019-16 Rev.1; MDCG 2020-6.
For IVDs, MDCG 2019-16 Table 1 shows the equivalent provisions in the IVDR.
How guidance describes it
MDCG 2020-1 (section 3.3) and MDCG 2020-6 (section 1.2) both cite the IMDRF definition from IMDRF/GRRP WG/N47:
"Developed stage of current technical capability and/or accepted clinical practice in regard to products, processes and patient management, based on the relevant consolidated findings of science, technology and experience."
The accompanying note explains that the state of the art embodies what is currently and generally accepted as good practice in technology and medicine, and "does not necessarily imply the most technologically advanced solution".
So state of the art is about generally accepted good practice at a given time, not about having the newest technology.
Not a legal definition
MDCG 2021-5 Rev.1 (section 3.5) makes two useful points:
"taking into account" the state of the art is not the same as "compliance" with it;
definitions can be found in several sources, including IMDRF N47, MDCG 2020-6 and EN ISO 14971:2019.
In practice, the manufacturer must show that its choices reflect current, generally accepted practice for its device, and record why.
Harmonised standards
Under Article 8(1), devices that conform to harmonised standards whose references have been published in the Official Journal are presumed to conform to the requirements those standards cover. The Commission's harmonised standards page notes that using them is voluntary.
MDCG 2021-5 Rev.1 adds three points:
the most recent versions of standards are commonly considered to reflect the state of the art;
complying with a recent standard that is not cited in the Official Journal does not automatically mean complying with the Regulation;
no standard can be imposed on the basis of "state of the art", although notified bodies take standards into consideration (Annex VII Section 4.5.1, as quoted in the guidance).
In our view, standards are evidence, not the definition. The technical documentation should record why the standards and editions used reflect current practice for the device.
How to show it for software
MDCG 2019-16 says manufacturers "should demonstrate state-of-the-art within their decisions (based on applicable standards, guidance, their own proprietary knowledge and publicly available scientific / technical information)".
For security, the guidance is specific:
section 3.7 lists security feature testing, fuzz testing, vulnerability scanning and penetration testing;
section 3.6 expects the operating environment to be kept up to date in terms of security.
In our view, security is where the state of the art moves fastest. Secure development, vulnerability handling and security testing are how Annex I Section 17.2 shows in practice. For software, the state of the art should be reassessed at significant releases and through post-market surveillance, not only at certification.
ISO 14971:2019, confirmed in 2025, covers risks including those related to data and systems security. Our article on ISO 27001 requirements covers information security management, and our overview of AI/ML standards for medical devices shows how fast the standards landscape is changing for AI.
The clinical side
MDCG 2020-1 section 4.1 says the benefit-risk determination is considered in light of the state of the art in medicine, and asks whether a data set is "appropriate and actual (state of the art)". MDCG 2020-6 section 6.5(c) covers alternative treatment options and fast-moving technology. A software device's clinical claims can therefore become outdated even if the software has not changed.
A hypothetical example
Hypothetical example: a Dutch SaMD manufacturer documented its development process, security testing and the standards it used at certification. Later, new harmonised standard references are published, and a vulnerability is found in a third-party component.
Post-market surveillance and risk management: the manufacturer reviews the vulnerability and its effect on the risk management file.
Gap analysis: it compares the standards and guidance it relied on with the current published references and MDCG guidance.
Security testing: it repeats the relevant testing described in MDCG 2019-16, to the extent the vulnerability and device risk require.
Documentation: it updates the technical documentation and revisits the clinical evaluation in line with MDCG 2020-1, including whether its data is still appropriate and current.
Our article on SaMD technical documentation explains where this evidence belongs in the file.
Conclusion
The MDR uses "state of the art" in several places but never defines it. Guidance describes it as generally accepted good practice, not the newest technology, and harmonised standards are one way to show it. For software, it keeps moving after certification, especially for security.
In our view, the practical test is whether the technical file shows which practice was applied, when it was last reviewed, and why it is still acceptable.
If you need help assessing your software against the current state of the art, our software lifecycle management team can help, or contact MedQAIR.
Frequently asked questions
Is "state of the art" defined in the MDR?
No. MDCG 2021-5 Rev.1 states that it is not a legally defined concept. MDCG guidance cites the IMDRF N47 definition instead.
Does state of the art mean the newest technology?
No. According to the IMDRF definition cited by the MDCG, it reflects generally accepted good practice and does not necessarily imply the most technologically advanced solution.
Is a standard not cited in the Official Journal state of the art?
It can be evidence of the state of the art, but according to MDCG 2021-5 Rev.1, complying with it does not automatically mean complying with the MDR. Only harmonised standards cited in the Official Journal give a presumption of conformity.
Must I use the latest edition of every standard?
No standard can be imposed on the basis of "state of the art", according to MDCG 2021-5 Rev.1. However, recent editions are commonly considered to reflect it, so the technical file should explain the editions you rely on.
How often should we reassess the state of the art?
The MDR sets no fixed interval. In our view, software manufacturers should reassess it at significant releases and when post-market surveillance, new standards or new vulnerabilities give a reason to.
