Medical Device Classification Under EU MDR (I–III)

Every decision that follows from here, your evidence requirements, your timeline, your budget, your route to market, is downstream of one determination: which class your device falls into. This guide walks through how that determination is made under MDR, and the medical device classification guide for the EU and US covers both jurisdictions side by side.

In short: EU MDR classifies devices into four risk classes, I, IIa, IIb, and III, using 22 rules in Annex VIII based on intended purpose, invasiveness, and duration of use. Class I can be self-certified; Class IIa and above require a Notified Body. For software, Rule 11 typically means Class IIa or higher.

In this guide:

• Why class is the first question that matters
• The four classes at a glance
• The four classes and what each means in money and months
• How the Annex VIII rules work, with founder-relevant examples
• Software special case: why Rule 11 changed everything
• Common misclassification traps
• From class to conformity route
• Frequently asked questions

Why class is the first question that matters

It's tempting to treat classification as an administrative step, something to confirm once the product is otherwise built. This is the single most consequential misordering in medical device development, because class isn't a label applied after the fact. It's the variable that determines the shape of everything else.

Your class determines whether a Notified Body reviews your file before you can place the device on the market, or whether you can self-certify. It determines the depth of clinical evidence required, from a literature-based equivalence argument at the low end to a full clinical investigation at the high end. It determines which quality management system elements actually get audited, and how often. And because all of the above drives cost and time, your class effectively sets your runway requirement before you've written a line of technical documentation. Founders who leave classification as an open question until late in development routinely discover the answer has quietly obsoleted their fundraising timeline.

The four classes at a glance

The table below is a starting orientation, not a substitute for working through Annex VIII against your specific device. Cost and timeline figures are a commonly cited industry range, not a Venitara quote — verify them against your own vendor and Notified Body quotes — and vary with how mature your technical file and quality system already are when you start.

The prose sections below walk through what drives a device into each class and where the recurring judgment calls sit.

The four classes and what each means in money and months

Class I covers the lowest-risk devices, things like non-invasive examination gloves, simple bandages, or reading glasses. Standard Class I devices can be self-certified: the manufacturer compiles a technical file, signs a declaration of conformity, and places the CE mark without third-party review. A subset of Class I devices, those with a measuring function, those supplied sterile, or reusable surgical instruments, require limited Notified Body involvement for that specific aspect even while remaining Class I overall.

Class IIa covers medium-low risk devices: many diagnostic software tools, most short-term invasive devices, and a large share of digital health products once they clear the medical-purpose threshold. Notified Body review is required. Industry-cited figures commonly put Class IIa–III software CE marking at roughly 12 to 18 months and an initial investment in the EUR 120,000 to 300,000 range — a range to verify against your own quotes rather than plan around — and this varies significantly with how mature your technical file and quality system already are.

Class IIb covers medium-high risk devices: longer-term invasive devices, most active therapeutic devices, and higher-stakes diagnostic and monitoring software where an incorrect output could lead to serious health deterioration or require surgical intervention. Notified Body review is more extensive than Class IIa, typically including deeper sampling of design and manufacturing documentation.

Class III covers the highest-risk devices: those in direct contact with the central nervous or cardiovascular system, devices incorporating medicinal substances, and software whose output could lead to death or irreversible deterioration of health. Class III requires the most extensive Notified Body review, generally including a full design examination, and correspondingly the longest timeline and highest cost.

How the Annex VIII rules work, with founder-relevant examples

MDR Annex VIII sets out twenty-two classification rules, organised into four groups: non-invasive devices (Rules 1–4), invasive devices (Rules 5–8), active devices (Rules 9–13), and special rules (Rules 14–22). You classify by working through the rules in order and applying the highest classification that any applicable rule assigns. A device can be caught by more than one rule, and the highest result governs.

The non-invasive group (Rules 1–4) covers devices that don't enter the body. Rule 1 handles general non-invasive devices, typically Class I. Rule 2 covers devices for channelling or storing substances for eventual introduction into the body, such as blood bags, scaling to IIa or IIb by the specifics of handling. Rule 3 covers devices that modify blood or other body fluids, generally IIb. Rule 4 covers devices in contact with injured skin, scaling by wound severity and duration of contact.

The invasive group (Rules 5–8) scales primarily by how long a device stays in the body and which body system it accesses: short-term use in natural orifices tends toward Class I or IIa; longer-term or surgically invasive devices scale up to IIb and III depending on whether they contact the central nervous or cardiovascular system.

The active devices group (Rules 9–13) covers devices with a power source. Rule 9 covers therapeutic devices administering or exchanging energy, commonly IIa or IIb depending on hazard potential. Rule 10 covers active diagnostic devices, scaling by what they measure. Rule 11, the rule most relevant to most Venitara clients, covers software specifically, and is discussed in detail below and in MDR Rule 11: Why Software Lands in Class IIa. Rule 12 covers active devices intended to administer or remove medicines and other substances to or from the body, commonly IIa, or IIb where the substance involved is hazardous. Rule 13 is the catch-all for all other active devices, which default to Class I. Devices incorporating an ancillary medicinal substance are not caught here at all — they fall under Rule 14, the first of the special rules, and are Class III.

The special rules group (Rules 14–22) covers categories that don't fit neatly into the non-invasive, invasive, or active groupings: devices incorporating, as an integral part, a substance that would be a medicinal product if used separately (Rule 14, Class III), devices incorporating substances absorbed by the body, devices made from tissues of animal or human origin, devices used for contraception or prevention of sexually transmitted disease, devices specifically for disinfecting other devices, devices for recording diagnostic images, devices manufactured from nanomaterials, devices used with an orifice or applied to skin to administer medicines by inhalation, and active therapeutic devices with an integrated diagnostic function that significantly determines patient management — closed-loop systems — which Rule 22 places in Class III. These rules tend to be narrower in scope but carry disproportionately high classifications for the specific categories they cover, since many involve substances entering the body or high-stakes diagnostic imaging.

A few worked examples illustrate how the logic actually runs. A non-invasive device intended for channelling or storing blood for eventual infusion is classified under Rule 2, and depending on the specific handling involved lands in Class IIa or IIb. A short-term invasive device intended for use in the ear, nose, or throat cavities is classified under Rule 5 or 6 depending on duration, commonly landing in Class IIa. An active therapeutic device intended to administer or exchange energy is classified under Rule 9, commonly Class IIa or IIb depending on whether the energy exchange could pose a hazard. A wound-care dressing intended for chronic, deep wounds is classified under Rule 4, and can reach Class IIb where infection or wound-healing complexity increases risk beyond simple superficial coverage.

The practical lesson from working through these rules is that classification is rarely a single, obvious lookup. It requires a genuine understanding of your device's intended purpose, described precisely, matched against rules that were written to cover an enormous range of physical and software devices with necessarily general language. This is exactly the kind of judgment call where a confident but wrong self-assessment costs far more than the time it takes to get a second opinion early.

Software special case: why Rule 11 changed everything

Before MDR, software classification under the previous Medical Devices Directive was comparatively permissive, and a large share of clinical software defaulted to Class I self-certification. MDR introduced Rule 11 specifically to close that gap. Under Rule 11, software providing information used to take decisions with diagnostic or therapeutic purposes is classified by the significance of that information and the state of the patient: Class III where a wrong decision could cause death or irreversible deterioration, Class IIb where it could cause serious deterioration or require surgical intervention, and Class IIa for essentially everything else that provides diagnostic or therapeutic decision-support information. Software that monitors physiological processes is Class IIa, or Class IIb if it monitors vital parameters where variation could pose immediate danger.

The consequence, worth repeating because it surprises founders who built their financial model around Class I timelines: most software with a genuine clinical decision-support function is now Class IIa at minimum. Self-certification is the exception for this category, not the default. MDR Rule 11: Why Software Lands in Class IIa covers the classification logic and the borderline cases in depth.

One caveat on where this rule is heading. In December 2025 the European Commission published a proposal to simplify the MDR and IVDR (COM(2025) 1023, procedure 2025/0404(COD)). Among other things it would move much stand-alone software toward Class I self-declaration and make external PRRC arrangements explicitly available to SMEs. It is a proposal, not law — adoption is realistically ~2027 at the earliest — so plan against the current rules, including the Class IIa default described here, while factoring the possible change into longer-term strategy.

And one boundary note: everything in this guide is MDR classification. If your software has an in vitro diagnostic purpose — analysing specimens such as blood, saliva, or genomic data — it falls under the IVDR (Regulation (EU) 2017/746) instead, which classifies devices under its own Annex VIII (Rules 1–7, Classes A–D) rather than the Class I–III scheme here, and requires a performance evaluation rather than an MDR clinical evaluation report.

Common misclassification traps

A few patterns recur often enough to name directly.

Under-classifying by focusing on the technology rather than the intended purpose is the most common. A founder reasons "it's just a dashboard" and misses that the dashboard's interpretive layer crosses into diagnostic decision support. A close cousin is under-classifying by ignoring marketing claims: the technical file describes a conservative intended purpose, but the website and sales deck make claims that describe a higher-risk use, and MDR looks at the totality of what you communicate, not just the formal documentation.

Over-classifying out of caution sounds safer but isn't free. It commits budget and timeline to evidence requirements you may not actually need, and it can also signal to a Notified Body that your understanding of your own intended purpose is unclear, which invites more scrutiny rather than less.

Treating classification as fixed once decided is another recurring gap. As your product evolves, particularly as you add features or expand claims, your classification can change, and a technical file that hasn't been revisited against an evolved intended purpose is a genuine compliance gap.

The trap worth sharpening above the others, because it's the one that consumes the most founder time and budget for no regulatory benefit, is classifying against an idealized future version of the product rather than the version you're actually launching. Founders sometimes classify conservatively for a roadmap feature that's eighteen months away, building evidence requirements for a device they haven't yet built, while the version actually going to market this year is over-specified for its real risk profile. This feels responsible, planning ahead, thinking about where the product is going, but it's a misapplication of the rule. Annex VIII classifies the device as it is intended to be placed on the market now, not the device you hope to build. Classify against what you're actually launching, budget and build evidence for that, and revisit formally as the product evolves, feature by feature, rather than trying to classify once for the whole roadmap. A device that gains a genuinely higher-risk feature later deserves a fresh classification exercise at that point, not a classification borrowed in advance from a plan that may itself change before it ships.

From class to conformity route

Once you know your class, the conformity route follows a defined pattern under MDR. Class I devices follow the manufacturer's own declaration of conformity, based on a technical file compiled internally. Class IIa, IIb, and III devices require a Notified Body to review your technical documentation and quality management system, with the depth of review scaling by class: sampling-based review for Class IIa, more extensive documentation and manufacturing review for Class IIb, and full design examination for Class III. CE Marking Cost and Timeline for Medical Software breaks down what each of these routes actually costs and how long they realistically take.

Classification also interacts with market strategy, particularly around the differences between EU, UK, and US frameworks. Where to Launch First: EU, UK, or US? is worth reading once you know your EU class, since the same product can sometimes sit at a different risk tier under a different jurisdiction's rules, which changes the order in which it makes sense to pursue each market.

Getting classification right, and getting it confirmed by someone who has taken products through Notified Body review rather than working from the rule text alone, is the highest-leverage regulatory decision you'll make early.

Frequently asked questions

Who decides my device's classification, me or the Notified Body? You classify your own device as the manufacturer, documented in your technical file with your reasoning against Annex VIII. The Notified Body reviews and challenges that classification as part of conformity assessment; it doesn't assign the class for you from scratch, but it can and does reject a self-assessed classification it disagrees with.

Can I appeal or contest a Notified Body's classification decision? Yes, there are formal routes to raise a disagreement, including escalation to the relevant Competent Authority, but in practice this is slow and adversarial. It's far more efficient to align on classification logic before formal submission, which is one of the reasons an early second opinion is worth having.

Does adding an AI or machine learning component change my MDR class? Not directly. MDR classification runs on the Annex VIII rules regardless of whether the underlying technology is AI-based or conventional software. What an AI component does add is separate EU AI Act obligations once your MDR class requires Notified Body assessment. One Notified Body for MDR and the AI Act covers the relationship.

How long does classification itself take? Classification as an analytical exercise, working through Annex VIII against your intended purpose, can often be done in days once your intended purpose is clearly and specifically written down. What takes longer is usually writing that intended purpose statement precisely enough to classify against, and gathering internal agreement across product and regulatory on what the device is actually claiming to do.

Is UK or US classification the same as EU MDR classification? No. The UK's post-Brexit framework and the US FDA system use different classification logic, even though the underlying risk concepts overlap. A device's EU MDR class isn't a direct lookup for its UK or US risk tier. Where to Launch First: EU, UK, or US? covers how the three systems compare.

Does the QMSR changes in the US affect my EU MDR classification? No, they're separate systems entirely. The US Quality Management System Regulation, which harmonises FDA's quality system requirements with ISO 13485 and has been in force since 2 February 2026, governs how US manufacturers run their quality systems. It has no bearing on how a device is classified under EU MDR Annex VIII, though many manufacturers building toward both markets use a single ISO 13485-aligned QMS to satisfy both frameworks' underlying requirements.

the free MedTech Compass can give you an AI-generated first read against Annex VIII in minutes. Treat it as a starting point, not a determination, and bring the result to an expert conversation before you commit your development roadmap to it.

---

Where next: MDR Rule 11: Why Software Lands in Class IIa · CE Marking Cost and Timeline for Medical Software · PRRC Under MDR Article 15: What to Know · Where to Launch First: EU, UK, or US?

Find out in minutes which class your device likely falls into. Start the MedTech Compass →