--- title: 7 Classification Mistakes Startups Make Under MDR (And How to Avoid Them) description: The seven most common MDR classification mistakes that cost startups months of rework — each with the Annex VIII rule it violates and how to avoid it. authors: Tibor Zechmeister, Felix Lenhard category: Device Classification & Conformity primary_keyword: MDR classification mistakes startups canonical_url: https://zechmeister-solutions.com/en/blog/7-classification-mistakes-startups-make-under-mdr source: zechmeister-solutions.com license: All rights reserved. Content may be cited with attribution and a link to the canonical URL. --- # 7 Classification Mistakes Startups Make Under MDR (And How to Avoid Them) *By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.* > **The seven classification mistakes in this post are the ones Tibor sees repeated across almost every first meeting: assuming Class I without reading Rule 11, classifying by technology instead of intended purpose, splitting bundled accessories wrong, missing the measurement function trigger, confusing the old MDD class with the new MDR class, treating classification as a one-time decision, and failing to defend a lower class with evidence when one was defensible. Each mistake is tied to a specific rule in MDR Annex VIII and Article 51, and each is fixable — if you catch it early.** **By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.** --- ## TL;DR - Classification under MDR is governed by Article 51 and the 22 rules in Annex VIII. Those rules are the only authority. Not a consultant's gut feeling, not a competitor's label, not what the MDD used to say. - Intended purpose — Zweckbestimmung — is the single input that drives classification. Get it wrong and every downstream decision is wrong with it. - Software is almost never Class I under MDR. Rule 11 in Annex VIII pushes most medical device software to Class IIa or higher. - A defensible lower class is not a risk — it is a legitimate strategic decision, but only when the evidence is documented before the Notified Body asks for it. - Classification is not a one-time event. Any change to intended purpose, indications, or device architecture re-opens the classification question. --- ## Why classification mistakes are the most expensive mistakes Of all the regulatory decisions a startup makes in its first six months, classification is the one with the worst cost asymmetry. A correct classification costs nothing extra. A wrong classification — discovered six or twelve months in — can mean rewriting the entire technical file, re-running clinical evaluation, re-selecting a Notified Body (because not every NB is designated for every class), and watching a year of runway evaporate. Tibor has seen this pattern often enough to name it: the founder decides the class in a founders' meeting, usually on intuition, sometimes after reading a blog post, and then builds the entire regulatory strategy on top of that decision. Eighteen months later, at the Notified Body's first review, the classification collapses. Everything on top of it collapses with it. The seven mistakes below are ordered by frequency. Each entry is the mistake, why it happens, the specific Annex VIII rule or MDR article it violates, and the fix. --- ## Mistake 1: Assuming Class I without reading Rule 11 for software **What happens.** A software-first founder sees "Class I" as the light path — minimal Notified Body involvement, self-certification under MDR Article 52(7), shorter timelines — and assumes their app qualifies. The assumption is rarely checked against Annex VIII Rule 11. **Why it happens.** The MDD era treated most software as Class I. Founders who did their research three or four years ago carry that memory forward. Startup forums reinforce it. Nobody volunteers the rule text. **The rule it violates.** MDR Annex VIII Rule 11 states that software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as Class IIa — except where such decisions have an impact that may cause death or an irreversible deterioration of a person's state of health (Class III), or a serious deterioration (Class IIb). Software intended to monitor physiological processes is Class IIa — or IIb when it monitors vital physiological parameters where variations could result in immediate danger. All other software is Class I. In practice, "all other software" is a narrow category under MDR. Most medical device software qualifies as Class IIa or above. **The fix.** Before you classify, read Rule 11 in full. Then read MDCG 2019-11 Rev.1 (June 2025), which is the definitive guidance on qualification and classification of software under MDR. If your intended purpose includes any decision support for diagnosis or therapy, start from Class IIa and work backwards only with explicit justification. Assume up, not down. --- ## Mistake 2: Classifying by technology instead of intended purpose **What happens.** The founder describes the device by what it is — "a sensor," "a bracelet," "a camera-based system," "an algorithm" — and reaches for a class based on the technology. The class comes out wrong because classification under MDR does not care what the device is. It cares what the device is *for*. **Why it happens.** Engineers describe products by architecture. Marketing describes products by features. Neither of those is the intended purpose. Felix calls this the most common regulatory killer he sees — founders who write a brilliant product description and a sloppy Zweckbestimmung and then wonder why the classification does not match their expectation. **The rule it violates.** MDR Article 2(1) defines a medical device exclusively by its intended medical purpose. MDR Article 2(12) defines "intended purpose" as the use for which a device is intended according to the data supplied by the manufacturer on the label, in the instructions for use, or in promotional or sales materials or statements, and as specified by the manufacturer in the clinical evaluation. Article 51 then requires classification to be performed on the basis of that intended purpose against the rules in Annex VIII. **The fix.** Write the intended purpose first, in one paragraph, before you write anything else in the technical file. State what the device does, for which patient population, in which clinical context, and for which medical decision. Then — and only then — walk Annex VIII from Rule 1 to Rule 22 with that paragraph in hand. The Graz wellness pivot Tibor guided a few years ago is the clean example: the original intended purpose implied medical device qualification; the founders rewrote the Zweckbestimmung to exclude diagnosis and therapy, and the product legitimately moved out of scope. That is a strategic choice made with the Regulation, not around it. --- ## Mistake 3: Splitting bundled accessories wrong **What happens.** A device ships with accessories — a dedicated cable, a proprietary electrode, a cleaning kit, a companion app. The founder classifies the main device and ignores the accessories, or gives each accessory a guessed class independent of the system. **Why it happens.** Annex VIII's treatment of accessories is one of the most misread sections. Founders treat accessories as "components" and assume they inherit the main device's class automatically. They do not — and they do not necessarily get a free pass either. **The rule it violates.** MDR Article 2(2) defines an "accessory for a medical device" as an article which, whilst not being itself a medical device, is intended by its manufacturer to be used together with one or several particular medical devices to specifically enable the medical device to be used in accordance with its intended purpose, or to specifically and directly assist the medical functionality of the medical device. Annex VIII Rule 2.2 states that accessories for a medical device shall be classified in their own right, separately from the device with which they are used. MDCG 2021-24 (October 2021) provides worked examples of how accessory classification is done in practice, and the European Commission's Manual on borderline and classification for medical devices within the regulatory framework of Regulations (EU) 2017/745 and 2017/746 (version 4) contains additional cases. **The fix.** List every item that ships with or is specifically intended for use with your device. For each one, ask: is this itself a medical device under Article 2(1), or is it an accessory under Article 2(2), or is it neither? Then classify each accessory in its own right through Annex VIII. A single submission can legitimately contain multiple classifications across the system — and leaving accessories un-classified is a finding waiting to happen. --- ## Mistake 4: Missing the measurement function trigger for Class Is/Im **What happens.** A founder classifies a device as Class I, submits the declaration of conformity under Article 52(7), and ships. Months later, a customer or auditor points out that the device has a measuring function — which means it is Class Im, not Class I, and requires Notified Body involvement for the metrological aspects. **Why it happens.** The distinction between Class I, Class Is (sterile), Class Im (measuring function), and Class Ir (reusable surgical instruments) is often collapsed in early-stage thinking. Founders see "Class I" and assume the self-certification path applies uniformly. It does not. **The rule it violates.** MDR Article 52(7) requires that for Class Is, Class Im, and Class Ir devices, the manufacturer must follow the conformity assessment procedure as specified in Chapters I and III of Annex IX, or Part A of Annex XI — which involves a Notified Body for the aspects related to sterility, metrological aspects, or reusability, respectively. A device that displays a number the user relies on for a medical decision, and where accuracy matters clinically, almost always has a measuring function. MDCG 2021-24 section on measuring function gives the interpretation. **The fix.** Before you conclude "Class I" and walk away, answer two questions honestly. First: does the device display a measured value that a clinician or patient uses to make a medical decision, where the accuracy of that value matters? If yes, it is Class Im and you need a Notified Body for the metrological aspects. Second: does the device have a sterile component at the point of use? If yes, it is Class Is and you need a Notified Body for the sterility aspects. The word "self-certification" does not apply cleanly to Is, Im, or Ir. Plan for NB involvement. --- ## Mistake 5: Confusing MDD class with MDR class (upclassification) **What happens.** A founder — or a consultant — looks at a legacy device that was Class I or Class IIa under the old MDD and assumes the MDR class is the same. It often is not. The MDR upclassified several categories, most famously standalone software, but also substance-based devices, reusable surgical instruments, and certain active devices. **Why it happens.** The transition from MDD to MDR has been long and messy. Founders encounter old certificates, old technical files, old guidance, and assume the class is stable. It is not. MDR Annex VIII introduced new rules and changed the thresholds of existing ones. **The rule it violates.** MDR Article 51 requires classification under the current rules in Annex VIII, regardless of any class assigned under the prior directive. A Class I device under MDD 93/42/EEC is not automatically Class I under MDR 2017/745. Rule 11 alone moved large categories of software up. Rule 21 introduced a new treatment for substance-based devices. Reusable surgical instruments moved from Class I to Class Ir. **The fix.** Treat every device as if it had no prior class. Walk Annex VIII from Rule 1 to Rule 22 with the current intended purpose. If the MDR result matches the MDD result, good. If it does not, believe the MDR result — it is the one the Notified Body will apply. For legacy devices under the transitional provisions extended by Regulation (EU) 2023/607, the new class applies from the moment the MDR certificate is issued. Do not carry the old class forward by inertia. --- ## Mistake 6: Treating classification as a one-time decision **What happens.** The founder classifies the device at project kickoff, writes it into the technical file, and never revisits it. Eighteen months later, the indications have expanded, the intended patient population has shifted, a new feature has been added, and the classification is now wrong — but nobody has noticed because nobody has re-opened the question. **Why it happens.** Classification feels like a foundational decision, and foundations are supposed to be stable. Founders do not want to re-open a decision that touched every downstream document. So they do not. **The rule it violates.** MDR Article 51 requires that classification be performed on the basis of the current intended purpose and the current device. Any change to intended purpose — a new indication, a new patient group, a new clinical context — re-opens classification. Any change to the device architecture that could affect its risk profile does the same. MDCG 2021-24 explicitly notes that classification is a dynamic attribute tied to the current state of the device and its intended use. **The fix.** Build a classification review checkpoint into your design control process. Every time the intended purpose changes, re-walk Annex VIII. Every time a significant new feature is added, re-walk Annex VIII. Every time indications expand, re-walk Annex VIII. The re-walk is cheap. The discovery of a missed reclassification during the NB audit is not. --- ## Mistake 7: Not defending a lower class with evidence when one is defensible **What happens.** The founder knows the device could legitimately be classified lower — the intended purpose is narrower than a competitor's, the decision support is non-critical, the monitoring is not of vital parameters. But the founder accepts the higher class without challenge because "better to be safe." Twelve months and hundreds of thousands of euros of extra conformity assessment later, the founder discovers a competitor is shipping the same category of device at the lower class, legitimately. **Why it happens.** "Classify up to be safe" feels conservative. It is not conservative — it is expensive. A defensible lower class, documented with evidence, is a legitimate strategic decision under MDR. Founders who do not know the defence is available do not attempt it. **The rule it violates.** Nothing in MDR Article 51 or Annex VIII prevents a manufacturer from classifying at the lowest class consistent with the rules and the intended purpose. What the Regulation requires is that the classification be documented, justified, and traceable. MDCG 2021-24 explicitly contemplates classification discussions and provides interpretive guidance. The European Commission's Manual on borderline and classification (version 4) contains specific case-by-case analyses that can support a defensible lower classification. **The fix.** When the rules in Annex VIII permit more than one reading, document both readings and defend the lower one with evidence: the exact wording of the intended purpose, the clinical context, the nature of the decision support, the severity of possible harm, the reversibility of the decision. Tibor has defended hardware-software classification disputes in front of Notified Bodies successfully when the evidence was prepared before the audit, not during it. "Better safe" is not a classification strategy. Documented reasoning is. --- ## The Subtract to Ship angle on classification The Subtract to Ship method, applied to classification, is simple: subtract every belief about the class that is not grounded in Annex VIII. Subtract the MDD memory. Subtract the "sensor is Class I" assumption. Subtract the competitor's label. Subtract the consultant's gut call that was not tied to a specific rule. What remains is the intended purpose and the twenty-two rules. That is the only classification engine the Regulation recognises. When founders work this way, classification takes an afternoon, not a week — and it is defensible when the Notified Body asks. See [the Subtract to Ship framework applied to MDR](/blog/subtract-to-ship-framework-mdr) for the broader method, and [MDR device classification explained](/blog/mdr-device-classification-explained) for a worked walk-through of Annex VIII. --- ## Reality Check — Where does your classification stand? 1. Do you have a one-paragraph intended purpose written down, approved by the founding team, and referenced by the technical file? 2. Have you walked all 22 rules of Annex VIII against that intended purpose, or did you stop at the first rule that seemed to fit? 3. If your device contains software, have you read Rule 11 in full and checked MDCG 2019-11 Rev.1? 4. Have you classified every accessory in its own right, per Annex VIII Rule 2.2? 5. Does your device have a measuring function, and if yes, have you planned for Notified Body involvement under Annex IX or XI? 6. Is your current MDR classification based on a fresh Annex VIII walk, or inherited from an MDD decision? 7. When was the last time the intended purpose changed, and did you re-open classification when it did? 8. If the class is higher than it could legitimately be, do you have documented evidence for a lower class, or did you classify up "to be safe"? If you winced at three or more of those, classification is the first thing to fix. Everything downstream rests on it. --- ## Frequently Asked Questions **Is there an official MDR classification tool from the European Commission?** There is no binding automated classifier. The authoritative sources are MDR Article 51, Annex VIII (the 22 rules), MDCG 2021-24 (the interpretive guidance), MDCG 2019-11 Rev.1 (for software), and the Manual on borderline and classification for medical devices within the regulatory framework of Regulations (EU) 2017/745 and 2017/746 (version 4). Online classifiers from consultants or Notified Bodies can be useful as a cross-check but are not binding. **Can a Notified Body overrule my classification?** Yes. A Notified Body can disagree with your classification during conformity assessment and require you to submit under a higher class. This is why defensible documentation matters — the discussion with the NB is much shorter when your reasoning is written down with evidence. **What if my device is borderline between two classes?** Document both readings. Present the evidence for the lower one if it is legitimately defensible. If the case is genuinely borderline, the Manual on borderline and classification contains comparable cases — and your Competent Authority can be asked for a formal classification opinion under MDR Article 51(2) in cases of dispute between manufacturer and Notified Body. **Does upclassification always mean more clinical evidence?** Usually yes. Higher classes require more substantial clinical evaluation under MDR Article 61 and Annex XIV, and Class III devices have the heaviest requirements. This is one reason a defensible lower class — when the rules allow it — has real strategic value. **How often should I re-check classification during development?** Whenever the intended purpose changes, whenever a significant new feature is added, whenever indications expand, and as a standing item at every design review. The re-walk is cheap; the cost of missing a change is not. --- ## Related reading - [MDR Device Classification Explained: Class I, IIa, IIb, III](/blog/mdr-device-classification-explained) — the full walk-through of Annex VIII. - [Rule 11: How MDR Classifies Medical Device Software](/blog/rule-11-mdr-software-classification) — the rule that catches most software-first startups. - [Intended Purpose Under MDR: Why Zweckbestimmung Decides Everything](/blog/intended-purpose-mdr-zweckbestimmung) — how to write the one paragraph that drives classification. - [Accessories Under MDR: Classification and Conformity Assessment](/blog/accessories-under-mdr-classification) — the rule most founders miss. - [Measuring Function Under MDR: When Class I Becomes Class Im](/blog/measuring-function-mdr-class-im) — the trigger that surprises founders. - [Upclassification From MDD to MDR: What Changed and Why](/blog/upclassification-mdd-to-mdr) — the categories that moved up. - [Borderline Products: Medical Device or Not?](/blog/borderline-products-medical-device-or-not) — the qualification question that precedes classification. - [Defending a Lower Class With Evidence: A Practical Playbook](/blog/defending-lower-class-evidence-playbook) — how to build the documentation. - [How to Write a Defensible Intended Purpose](/blog/how-to-write-defensible-intended-purpose) — the first page of the technical file. - [The Subtract to Ship Framework Applied to MDR](/blog/subtract-to-ship-framework-mdr) — the broader method. --- ## Sources 1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 2(1) (definition of medical device), Article 2(12) (intended purpose), Article 51 (classification), Annex VIII (classification rules, Rules 1 to 22, including Rule 2.2 on accessories and Rule 11 on software). Official Journal L 117, 5.5.2017. 2. Regulation (EU) 2023/607 amending Regulations (EU) 2017/745 and (EU) 2017/746 as regards the transitional provisions for certain medical devices and in vitro diagnostic medical devices. 3. MDCG 2021-24 — Guidance on classification of medical devices, October 2021. 4. MDCG 2019-11 Rev.1 (June 2025) — Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 — MDR and Regulation (EU) 2017/746 — IVDR. 5. European Commission — Manual on borderline and classification for medical devices within the regulatory framework of Regulations (EU) 2017/745 and 2017/746, version 4. --- *This post is part of the MDR Fundamentals & Regulatory Strategy series in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. Every mistake in this list was collected from real classification reviews across more than fifty certification projects.* --- *This post is part of the [Device Classification & Conformity](https://zechmeister-solutions.com/en/blog/category/classification) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*