In-Vitro Diagnostic Software Device CE Certification
An in-vitro diagnostic software device needs CE certification under Regulation (EU) 2017/746 before it can be placed on the EU market. This guide explains when software qualifies as an IVD, how to classify it, what evidence a notified body expects and how to plan the route to the CE mark.
What is an In-Vitro Diagnostic Software Device?
An in-vitro diagnostic software device is software intended by its manufacturer to provide medical information from the in vitro examination of specimens taken from the human body. The IVDR definition in Article 2(2) explicitly lists software, so an algorithm, app or cloud service can be an IVD in its own right, even when it has no physical component.
An IVD software device can be standalone, such as a tool that interprets genetic variants, or it can drive or influence another device, such as the software that controls an analyser or calculates its result. That distinction decides how the software is classified and how it moves through IVD CE marking.
Software is held to the same regulation as any other IVD. It needs technical documentation, a performance evaluation, a quality management system and post-market surveillance, plus additional requirements for the software lifecycle and IT security.

Does Your Software Qualify as an IVD Software Device?
Qualification comes first, and it depends on the intended purpose you state in your labelling, instructions for use and promotional material. MDCG 2019-11 Rev.1, published in June 2025, is the main EU guidance on qualifying and classifying software under the MDR and IVDR.
- Interprets or calculates a diagnostic result from specimen data
- Combines assay results to give a risk score, prognosis or prediction
- Drives or influences the use of an IVD, such as analyser control or result calculation
- Gives information used to select a therapy from biomarker results
- Only stores, archives, communicates or carries out a simple search of data
- Handles only administrative tasks, such as billing or sample logistics
- Serves general lifestyle or wellbeing purposes with no medical purpose
- Analyses only images or physiological signals, not specimen data, which points to the MDR
IVD Software Device Classification Under Annex VIII
Implementing rule 1.4 of Annex VIII sets two paths. Software that drives or influences the use of a device falls within the same class as that device. Software that is independent of any other device is classified in its own right using Rules 1 to 7. If several rules or intended purposes apply, the highest class applies. Our IVDR classification guide explains each rule in full.
| Software example | Path or rule | Indicative class |
|---|---|---|
| Software that interprets donor screening results for a transmissible agent such as HIV | Standalone, Rule 1 | Class D |
| Software that determines ABO compatibility for transfusion | Standalone, Rule 2 | Class D |
| Algorithm that interprets genetic variants or BRCA1/2 results | Standalone, Rule 3 | Class C |
| Software that uses biomarker results to stage cancer or select a therapy | Standalone, Rule 3 | Class C |
| App that reads and interprets a home self-test, other than the Rule 4 exceptions | Rule 4 | Class C |
| App that reads a pregnancy or fertility self-test | Rule 4 exception | Class B |
| Calculator that derives a value from routine clinical chemistry, such as eGFR from creatinine | Standalone, Rule 6 | Class B |
| Software that controls a general IVD analyser and does not influence a specific assay result | Drives device, Rule 5 | Class A |
| Software that calculates the result of a specific assay | Influences device | Same class as the assay |
These examples are indicative. The final class always depends on your exact intended purpose, so record the rationale in your technical documentation. Read the class guides for Class A, Class B, Class C and Class D.
CE Certification Route by IVD Software Class
The class decides whether a notified body reviews your software and how deeply. Most IVD software with a diagnostic function needs a notified body.
| Class | Route to CE certification | Notified body |
|---|---|---|
| Class A | Manufacturer self-declaration, with Annex II and III technical documentation and an Annex IV declaration of conformity | No |
| Class B | Annex IX QMS audit with technical documentation assessment of at least one representative device per category | Yes |
| Class C | Annex IX QMS audit with technical documentation assessment of at least one device per generic device group, or Annex X type examination with Annex XI production quality assurance | Yes |
| Class D | Annex IX with full technical documentation assessment, EU reference laboratory verification where one is designated, and expert panel consultation for novel devices where applicable | Yes |
Review the IVD CE marking process, then budget with our IVDR CE certification cost and notified body fees pages.
Technical Requirements for an IVD Software Device
Annex I Section 16 of the IVDR sets the specific requirements for software and electronic programmable systems. A notified body will expect to trace each one to evidence in your file, using your GSPR checklist.
Software lifecycle
Develop and maintain the software to the state of the art. IEC 62304 is the usual reference for lifecycle processes and safety classes, with IEC 82304-1 relevant to health software products. See our IEC 62304 consultants page.
Risk management and usability
Apply ISO 14971 across the lifecycle, covering incorrect, delayed or misinterpreted results. Use IEC 62366-1 to validate that intended users can operate the software safely.
Cybersecurity and IT security
Set minimum hardware, network and IT security requirements, and protect against unauthorised access. MDCG 2019-16 is the key EU guidance, and IEC 81001-5-1 supports secure development.
Performance evaluation
Show scientific validity, analytical performance and clinical performance under Article 56 and Annex XIII. MDCG 2020-1 explains how to apply this to software in a performance evaluation report.
Quality management system
Run an IVDR-compliant QMS that covers design control, configuration management, supplier control of cloud and third-party components, and change control. ISO 13485 is the usual framework.
Post-market surveillance and UDI
Keep a PMS plan, performance follow-up and the reports required for your class. Assign UDI under Annex VI, and assess each software change for its effect on UDI, certification and class.
Steps to CE Certification for IVD Software
The same sequence works for a single algorithm or a full software platform. Fixing the intended purpose early reduces rework later.
- Define the intended purposeState the medical purpose, the input data, the users, the population and the clinical decision the output supports.
- Confirm qualification and classDocument why the software is an IVD, which modules are in scope and which Annex VIII rule sets the class.
- Close the QMS and lifecycle gapsAlign design control, IEC 62304 processes, risk management and cybersecurity with IVDR expectations.
- Build the technical documentationCompile Annex II and III files, including architecture, verification and validation, and labelling.
- Complete the performance evaluationGenerate and report scientific validity, analytical performance and clinical performance evidence.
- Apply to a notified bodyUnless the software is Class A, contract a notified body, complete the audit and answer its questions.
- Declare conformity and affix the CE markSign the EU declaration of conformity, complete registrations, and show the CE mark in the labelling or user interface.
- Maintain the certificateRun PMS, assess every update through change control and notify the notified body of significant changes.
Transition Deadlines and the AI Act for IVD Software
IVDR transition deadlines
Regulation (EU) 2024/1860 extended the transition for eligible legacy devices, subject to conditions including an IVDR-compliant QMS and timely notified body application. The end dates are 31 December 2027 for Class D, 31 December 2028 for Class C, and 31 December 2029 for Class B and Class A sterile devices. New software does not benefit, so it must meet the IVDR before it is placed on the market. See the IVDR transition timeline.
AI-enabled IVD software
AI-enabled IVDs that need a notified body are high-risk under the EU AI Act, Regulation (EU) 2024/1689. Regulation (EU) 2026/1744 moved the application date for these products to 2 August 2028. Plan data governance, transparency and human oversight alongside your IVDR file.
The European Commission also proposed further MDR and IVDR changes in December 2025, including for software, so confirm the current legal text before you finalise your plan. The IVDR is available on EUR-Lex.
Get Your IVD Software Device CE Certified
Our IVDR consultants qualify and classify your software, close the QMS and lifecycle gaps, and build the evidence your notified body expects.
- Written qualification and classification rationale
- IEC 62304, ISO 14971 and cybersecurity gap assessment
- Technical documentation and PER
- Notified body submission and query support
Plan your software route
Share your software details and get a tailored proposal. See typical IVDR certification costs.
IVD Software Device: Frequently Asked Questions
What is an in-vitro diagnostic software device?
It is software intended to provide medical information from the in vitro examination of specimens taken from the human body. It can be standalone or it can drive or influence another IVD, and it falls under Regulation (EU) 2017/746.
Does every IVD software device need a notified body?
No. Class A software is self-declared by the manufacturer. Class B, C and D software needs a notified body, and most software with a diagnostic function falls in one of those classes.
How is IVD software classified?
Software that drives or influences a device takes the class of that device. Independent software is classified in its own right using Annex VIII Rules 1 to 7. Where several rules apply, the highest class applies.
Is laboratory information system software an IVD?
Not usually, when it only stores, archives, communicates or searches data or handles administrative tasks. A module that interprets results or calculates a diagnostic value can qualify, so assess each module against its intended purpose.
Is IEC 62304 mandatory for IVD software?
The IVDR requires development to the state of the art rather than naming a standard. IEC 62304 is the usual way to show lifecycle compliance, and a notified body will expect a justified equivalent if you do not use it.
What performance evidence does IVD software need?
You need scientific validity, analytical performance and clinical performance evidence, reported in a performance evaluation under Annex XIII. MDCG 2020-1 explains how this applies to software.
Do software updates need a new CE certificate?
Not always. Assess every update through change control. Changes to the intended purpose, the algorithm or the performance may need notified body review, and some changes require a new UDI-DI.
Is IVD software with AI covered by the AI Act?
Yes, when it needs a notified body assessment under the IVDR. It is treated as high-risk, with the requirements applying from 2 August 2028 under Regulation (EU) 2026/1744, in parallel with the IVDR.
Updated | Author: Sobha Augustine, Founder, I3CGLOBAL | Reviewed by: Swathi Tummala, Senior Regulatory Consultant, I3CGLOBAL