MDCG guidance documents are not legally binding. Common specifications under MDR Article 9 are. But every notified body in Europe treats MDCG guidance as the reference interpretation of the regulation, which means in practice you ignore it at your peril.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • The MDR itself is the only hard law. Delegated and implementing acts adopted under it are also binding.
  • Common specifications under Article 9 are legally binding once the Commission adopts them by implementing act.
  • Harmonised standards listed in the Official Journal give a presumption of conformity but are not mandatory.
  • MDCG guidance documents are interpretive and explicitly non-binding but are followed by notified bodies in practice.
  • If you deviate from MDCG guidance, you need a reasoned written justification in your technical documentation.

A common failure mode in MedTech startups: a founder reads an MDCG guidance document, decides one paragraph looks inconvenient, and concludes "it's just guidance, we don't have to do it." Six months later, the notified body opens a major non-conformity on exactly that paragraph, and the founder discovers that "not legally binding" and "ignorable" are completely different statements.

The legal hierarchy in MDR matters because it tells you what you must do, what you should do, and what you can justify not doing. Knowing the difference is a core regulatory literacy skill, and it is one of the things most first-time MedTech founders get wrong.

What MDR actually says: the seven-level hierarchy

Here is the legal hierarchy that applies to every medical device on the EU market. Top is binding and absolute. Bottom is informative.

Level 1 — The MDR itself. Regulation (EU) 2017/745 and its amendments, notably (EU) 2023/607 on extended transitional provisions. This is directly applicable in every Member State. Article 1 fixes the scope. Articles 5-13 fix the core obligations. Annex I fixes the GSPR. These are not negotiable.

Level 2 — Delegated and implementing acts. Article 115 gives the Commission power to adopt delegated acts. Article 114 creates the implementing act procedure. Examples include Commission Implementing Regulation (EU) 2021/2078 on Eudamed rules and the electronic IFU rules under Implementing Regulation (EU) 2021/2226 as amended. These are legally binding as soon as they enter into force.

Level 3 — Common specifications under Article 9. Article 9 lets the Commission adopt common specifications by implementing act where no harmonised standards exist or where existing standards are insufficient. Once adopted, a manufacturer must either comply with the common specifications or demonstrate a solution that ensures an equivalent or higher level of safety and performance. Common specifications are legally binding on the manufacturer unless they go through the equivalence route — and the equivalence route is not cheap.

Level 4 — Harmonised standards listed in the Official Journal. Under Article 8, harmonised standards that have been cited in the OJEU give a presumption of conformity with the GSPR they cover. They are not mandatory. A manufacturer can use a different standard or a bespoke solution. But if the manufacturer chooses not to use the harmonised standard, they must demonstrate that their alternative achieves the same level of safety and performance, and the notified body will scrutinise this.

Level 5 — Other standards and technical specifications. Standards that are not harmonised, standards from other jurisdictions, international standards not yet listed in the OJEU. These can support a state-of-the-art argument under Article 10(1) but they do not carry a presumption of conformity.

Level 6 — MDCG guidance documents. Produced by the Medical Device Coordination Group established under Article 103 MDR. The group brings together competent authority experts, Commission representatives and observers. Its tasks under Article 105 include issuing guidance to ensure consistent application of the regulation. These documents are explicitly non-binding — they say so on the cover page — but they represent the consensus view of Member State authorities and Commission services. Notified bodies use them as the reference interpretation.

Level 7 — Everything else. Industry association papers, consultant opinions, LinkedIn posts from ex-auditors, blog posts (including this one). Useful context, zero legal weight.

A worked example: software classification under Rule 11

Take a common situation. You are building Class IIa software and trying to decide whether your classification justification is adequate.

  • Level 1, the MDR. Annex VIII Rule 11 sets the classification criteria for software. This is binding. You must classify your software according to Rule 11.
  • Level 3, common specifications. There are no common specifications for software classification as of late 2026. Skip.
  • Level 4, harmonised standards. No harmonised standard specifies how to apply Rule 11. Standards like EN 62304 address the lifecycle process once you know the class, not the classification itself.
  • Level 6, MDCG guidance. MDCG 2019-11 Rev.1 (Rev.1 June 2025) on software qualification and classification is the reference document. It includes worked examples, decision trees and the MDCG's view on edge cases.

You are not legally obliged to follow MDCG 2019-11. You are legally obliged to classify correctly under Rule 11. But every notified body in Europe uses MDCG 2019-11 as their benchmark. If your classification rationale tracks MDCG 2019-11 line by line, the notified body review is smooth. If it deviates, you need a written reasoned justification that explains why your interpretation still meets Rule 11.

This is the general pattern. MDCG guidance is the path of least resistance. Deviating is legal, but it has a cost, and the cost is audit time, notified body questions, and sometimes a minor or major non-conformity if your justification is weak.

The Subtract to Ship playbook for working with MDCG guidance

The principle is: follow MDCG guidance by default, deviate only when you have a documented reason, and never treat "not legally binding" as an excuse to ignore it.

Step 1 — Build your MDCG register. Maintain a simple spreadsheet of every MDCG document relevant to your device. Columns: document number, title, version, date of your review, applicable sections, impact on your technical documentation. Update at every management review.

Step 2 — Cross-reference in your documentation. Your classification justification, CEP, PMS plan, CER and risk management file should cite the relevant MDCG document by number and version. This signals to the auditor that you know what you're doing.

Step 3 — When you deviate, document the deviation. The format is simple: "MDCG [number] Section [X] states [summary]. Our approach differs because [reasoned justification based on device-specific facts]. This alternative approach meets GSPR [number] because [evidence]." Keep this in your technical documentation. An auditor who sees this will ask questions, but they will not open a non-conformity just because you chose a different path.

Step 4 — Watch for revisions. MDCG documents are revised regularly. MDCG 2019-11 is at Rev.1. MDCG 2019-16 is at Rev.1. MDCG 2021-5 is at Rev.1. If you based your documentation on the original version and the revision changed material points, you need to assess the impact and update your documentation. This is part of keeping your technical documentation up to date under Annex II.

Step 5 — Distinguish interpretive guidance from procedural guidance. Some MDCG documents interpret GSPR or classification rules (high regulatory impact). Others explain Eudamed procedures or vigilance reporting workflows (high operational impact but not interpretive). Know the difference so you know what to argue and what to follow mechanically.

Reality Check

  1. Can you list the MDCG documents that apply to your specific device class and product category?
  2. Does your classification justification cite the current revision of any relevant MDCG guidance?
  3. If your notified body asked you to explain one deviation from MDCG guidance in writing, could you produce the justification in under an hour?
  4. Do you distinguish in your own thinking between "not legally binding" and "can be ignored"?
  5. Are you monitoring MDCG revisions as part of your regulatory intelligence process?
  6. If a common specification were adopted tomorrow covering your device, would you know where to find it and what it means for your existing conformity?
  7. Does your team understand that harmonised standards are also not mandatory, just a path of least resistance?

Frequently Asked Questions

Is MDCG guidance legally binding? No. MDCG guidance is explicitly non-binding. It represents the consensus interpretation of Member State competent authorities and Commission services but does not have the force of law.

What is the difference between a common specification and MDCG guidance? Common specifications under Article 9 are adopted by the Commission through implementing act and are legally binding on manufacturers unless they demonstrate equivalent safety and performance. MDCG guidance is interpretive and not legally binding.

Can I ignore MDCG guidance if it is inconvenient? Legally, yes. Practically, no. Notified bodies use MDCG guidance as their reference interpretation. Ignoring it without a written reasoned justification is the fastest path to audit findings.

Do harmonised standards have to be followed? No. Harmonised standards give a presumption of conformity but are not mandatory. You can use a different technical solution if you demonstrate it achieves the same level of safety and performance.

How do I know which MDCG documents apply to my device? Start with the Commission's MDCG page and filter by topic. For software, MDCG 2019-11 is essential. For cybersecurity, MDCG 2019-16. For clinical evaluation, MDCG 2020-5 and 2023-7. For PMS, MDCG 2025-10. For classification, MDCG 2021-24.

What happens if a common specification is adopted for my device after I get my CE mark? You have to reassess conformity against the new common specification at the next scheduled review or as part of a significant change. The specific transitional arrangements depend on the implementing act that adopts the common specification.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Articles 8, 9, 103, 105.
  2. MDCG 2019-11 Rev.1 (June 2025) — Software qualification and classification.
  3. MDCG 2021-5 Rev.1 (July 2024) — Standardisation for medical devices.