A lab may produce the right result, yet still face a serious problem if the system carrying that result cannot be trusted. Today, diagnostic information often moves through connected instruments, software, cloud services, and APIs before it reaches the people who use it. A weakness anywhere along that route can expose patient data or disrupt access to critical results.
The January 2026 cyberattack on Belgium’s AZ Monica hospital showed how quickly digital disruption can affect healthcare operations. Systems went offline, and the hospital was still working with reduced capacity days later.
For IVD manufacturers, security therefore affects more than privacy. It can influence whether diagnostic information stays accurate, available, and dependable.
That makes CE IVD vs IVDR an important compliance question for anyone developing or marketing connected IVD products in Europe. The first step is understanding what CE IVD actually means under IVDR.
What Is CE IVD Under the New IVDR Framework?
A CE-marked IVD is an in vitro diagnostic device that has completed the applicable EU conformity route and meets the requirements needed for placing it on the European market. IVDR is the law behind those requirements. Regulation (EU) 2017/746 governs IVDs across the EU.
So CE IVD vs. IVDR do not describe two competing certifications. CE refers to conformity with applicable EU requirements, IVD identifies the type of device, and IVDR provides the regulatory framework.
There is also no separate official EU approval called “CE IVD certification.” Depending on the device, the CE marking process typically requires you to:
- Confirm that the product qualifies as an IVD.
- Determine its class under Annex VIII.
- Meet the relevant IVDR requirements.
- Complete the applicable conformity assessment.
- Prepare the EU Declaration of Conformity.
- Affix the CE marking.
If a Notified Body must assess the device, its identification number appears with the CE mark where required. A Notified Body certificate records the assessment performed by that body. The Declaration of Conformity comes from the manufacturer, while CE marking indicates that the applicable conformity requirements have been addressed.
How IVDR Changed the Rules From IVDD
IVDR entered into force in 2017 and became applicable on 26 May 2022. One major change was the move to Classes A, B, C, and D, which increased Notified Body involvement for many IVDs.
| IVDR Class | General Risk Position | Typical Notified Body Involvement |
| Class A non-sterile | Lowest risk | Generally not required |
| Class A sterile | Low risk | Required for aspects related to sterile conditions |
| Class B | Moderate risk | Required |
| Class C | Higher individual or public health risk | Required |
| Class D | Highest individual and public health risk | Required, with additional controls in certain cases |
The class must come from the device’s intended purpose and the rules in Annex VIII, not from the classification of a similar product. MDCG 2020 16 Rev.4, published in March 2025, provides current guidance and examples for applying those rules.
What Changed for IVD Software?
Software can qualify as an IVD in its own right when its intended medical purpose falls within the IVDR definition. Simply being used in a laboratory is not enough. Software limited to storing, transferring, archiving, or displaying data may fall outside medical device software if it does not perform a medical purpose itself. MDCG 2019 11 Rev.1, updated in June 2025, gives further guidance on making that distinction.
For software that does qualify, CE compliance covers more than accurate output. Annex I Section 16 also addresses software lifecycle processes, information security risks, verification and validation, the intended IT environment, and protection against unauthorized access.
The IVD CE Marking Process for Digital Solutions
CE marking for IVD software is a process, not a single audit or certificate. You first define the product and its medical purpose. That decision then guides classification, documentation, conformity assessment, and ultimately the CE mark.
Step 1: Define the Intended Purpose and Confirm IVD Qualification
Start by documenting exactly what the software is meant to do. Depending on the product, this may include:
- The information it produces
- The analyte or marker involved
- The specimen type
- The target patient group
- The intended user and setting
- The medical purpose, such as diagnosis, prognosis, prediction, or monitoring
Qualification comes before classification.
For example, software that only displays an existing laboratory result may not qualify as IVD software. A program that analyses specimen-derived data and produces a medically relevant interpretation may qualify, depending on its intended purpose.
Step 2: Determine the IVDR Risk Class
The assigned IVDR class affects how demanding the regulatory route will be. It influences the conformity assessment you need, the performance evidence expected, the depth of technical documentation, and whether a Notified Body must review the product. IVDR uses Classes A, B, C, and D based on intended purpose and risk.
For standalone IVD software, classification may need to be assessed separately based on what the software itself does. MDCG 2019 11 Rev.1 provides specific guidance for applying the IVDR classification rules to software.
Step 3: Build the Quality Management and Regulatory Structure
Before conformity assessment, put the management structure around the product in place. Under IVDR, your QMS should cover areas such as risk management, software development controls, configuration and change management, suppliers, corrective actions, postmarket activities, and processes for handling vulnerabilities and other product issues.
You may also need to appoint a Person Responsible for Regulatory Compliance under Article 15. Manufacturers based outside the EU generally need an EU Authorised Representative as required by Article 11.
Step 4: Map the Product Against the Annex I GSPRs
Now map the software against the General Safety and Performance Requirements that actually apply to it. For digital IVDs, the evidence commonly covers:
- Reliable and consistent performance
- Software lifecycle controls
- Information security risk management
- Verification and validation
- Requirements for connected hardware and IT networks
- Protection against unauthorized access
Annex I Section 16 specifically addresses these software-related requirements.
Your technical file should also show how the cybersecurity evidence supports each relevant requirement. A standalone vulnerability scan is not enough to demonstrate CE certification for medical devices.
The documentation should connect the identified risk with the control used to reduce it and the test evidence showing that the control works.
Step 5: Generate Performance Evidence
IVDR requires evidence that the IVD performs as intended. Your performance evaluation should address three areas:
- Scientific validity: Whether the analyte or marker is linked to the clinical or physiological condition being assessed.
- Analytical performance: How reliably the device detects or measures what it claims.
- Clinical performance: Whether the results meaningfully relate to the intended clinical condition or state.
You need a Performance Evaluation Plan and supporting documentation that brings this evidence together. Performance evaluation also continues after market entry as new data becomes available.
Step 6: Conduct Security Verification and Validation
Security verification should match the product’s architecture, interfaces, and identified risks. Depending on the IVD software, relevant testing may include:
- Secure architecture review
- Source code or component review
- Vulnerability assessment
- Penetration testing
- API and cloud security testing
- Authentication and authorization checks
- Encryption and data handling tests
- Abuse case and attack path testing
MDCG 2019 16 Rev.1 specifically discusses methods such as security feature testing, vulnerability scanning, fuzz testing, and penetration testing as possible verification activities. IVDR Annex II also requires software verification and validation evidence in the technical documentation.
Any security weaknesses found should be recorded, corrected, and tested again. Changes may also require regression testing to confirm that the fix has not introduced another issue.
Step 7: Complete the Applicable Conformity Assessment
Once the device class is confirmed, follow the conformity assessment route that applies under IVDR. For most devices above the lowest risk category, this involves review by a designated Notified Body. Non-sterile Class A products can generally rely on manufacturer declaration, while sterile Class A devices require Notified Body involvement for the sterility-related aspects.
Class D devices may face an additional layer of review. Where an EU Reference Laboratory has been designated for that type of IVD, it can take part in performance verification and, where relevant, batch testing.
Step 8: Declaration, CE Marking, UDI and EUDAMED
After conformity assessment, complete the EU Declaration of Conformity, apply the CE mark, and add the Notified Body identification number where required.
You must also meet the applicable UDI and registration requirements. Since 28 May 2026, the UDI and Device Registration module in EUDAMED has been mandatory to use.
IVDR obligations continue after market entry, so device information and ongoing conformity must remain current.
Addressing Cybersecurity Vulnerabilities in IVD Systems
For an IVD, cybersecurity testing should check whether an attacker could alter, block, falsify, or misuse diagnostic information, not only steal it.
Protect Diagnostic Data Integrity
Security controls should protect the information that can influence a diagnostic result, including:
- Patient and result association
- Specimen identifiers
- Reported values
- Thresholds and reference ranges
- Calibration and configuration data
- Algorithm inputs and outputs
- Result transmission
- Audit records
Harden APIs and System Integrations
Connected IVDs often exchange data with laboratory systems, instruments, cloud platforms, and clinical applications. Test those APIs for:
- Broken object and function-level authorization
- Weak authentication
- Excessive data exposure
- Manipulated inputs and injection flaws
- Forgotten or undocumented endpoints
- Weak rate controls
- Insecure tokens
- Exposed API keys or secrets
- Poor server-side validation
Pay particular attention to authorization. Changing an object identifier or calling a restricted endpoint should never give one user access to another patient’s data or a function outside their assigned role.
Test Cloud Connected Components
If the IVD relies on cloud infrastructure, review the configuration as carefully as the application itself. Check for:
- Publicly exposed storage
- Weak IAM settings
- Excessive permissions
- Exposed secrets
- Poor network segmentation
- Insecure administrator consoles
- Missing or incomplete logs
- Weak encryption
- Tenant isolation failures in shared SaaS environments
- Insecure backup and recovery settings
Multi-tenant diagnostic platforms need particular attention. One customer should never be able to access another tenant’s data, configuration, or functions because of an authorization or isolation flaw.
Assess Firmware, Devices and Communication Channels
A connected analyser or diagnostic instrument can introduce risks that application testing will not catch. Review the hardware and firmware for:
- Unsafe firmware update mechanisms
- Updates that are not properly signed or verified
- Exposed debugging or maintenance interfaces
- Insecure communication protocols
- Hard-coded credentials or secrets
- Weak device authentication
- Unprotected local ports and physical interfaces
- Poorly designed trust between the device and cloud services
Pay close attention to update mechanisms and device communication. Compromising either could allow unauthorized software, configuration changes, or altered data to reach the IVD environment.
Validate Third Party and Software Supply Chain Risks
IVD software often depends on third-party components. These may include open source packages, operating systems, SDKs, containers, APIs, and cloud services.
Keep a record of what is included in each release. If a new vulnerability is found, check whether it can actually affect your product. Then document what action you took, such as patching the component, applying another control, or accepting the remaining risk with justification.
Plan for Cybersecurity After Release
The work does not end once you CE mark medical device software. New vulnerabilities can appear later, so manufacturers need ongoing monitoring, security updates, incident response, CAPA, and postmarket surveillance. Significant software changes may also need a fresh risk assessment and additional testing.
IVDR software UDI rules also recognize that products change over time. A change that affects performance, safety, intended use, or data interpretation can require a new UDI DI. Minor revisions, including certain security patches, are treated differently.
Building an IVDR Compliant Technical File
The technical file should let a reviewer follow the product from its intended function through to the risks, controls, and evidence supporting conformity.
Core IVDR Technical Documentation
For a digital IVD, bring the relevant product description, classification rationale, architecture, risk records, GSPR evidence, performance data, verification results, labeling, and applicable UDI information into one controlled file.
Postmarket surveillance documentation also forms part of the overall technical documentation and must remain current as new information becomes available.
Cybersecurity Risk Documentation
Cybersecurity documentation should make the connection between the risk, the control, and the evidence easy to follow. Depending on the product, the file may include:
- Threat models and attack surface records
- Data flow diagrams and trust boundaries
- Security architecture
- Access control and encryption design
- Third-party dependency records
- Vulnerability management procedures
- Patch and update plans
- Incident response procedures
These records should sit within the wider risk management and verification evidence rather than exist as separate, unrelated reports.
Document Software Supply Chain Risks
Your technical documentation should identify the third-party software included in each release. Record the component, its version, known vulnerabilities, and any updates made during the product lifecycle.
For externally supplied components, also define who is responsible for security fixes and vulnerability information. This helps you trace inherited risks back to the correct component or supplier without repeating the full security assessment elsewhere in the file.
Document Active Security Validation
Keep the security test record detailed enough to show how the assessment was performed and what happened afterward. Include the scope, test environment, findings, technical proof, severity, and whether each issue could affect device safety or performance.
For every confirmed weakness, record the fix, remaining risk, retest result, and final status. This gives the technical file a clear history of the issue from discovery through closure.
Connect Cybersecurity Findings to the Risk Management File
Keep the link between a security finding and the product risk file easy to follow. MDCG 2019 16 Rev.1 supports connecting cybersecurity risk management with verification and post-market activities.
Threat or vulnerability
↓
Exploit scenario
↓
Affected asset or function
↓
Safety or performance impact
↓
Security control
↓
Verification evidence
↓
Residual risk
↓
Post-market monitoring
Qualysec’s Specialist Auditing for Diagnostic Platforms
A connected IVD is rarely just one application. It may rely on APIs, cloud services, firmware, mobile apps, hardware interfaces, and third-party integrations. Qualysec can test these parts as part of the security validation work that supports a manufacturer’s wider IVDR program.
Its testing combines automated checks with manual attack-based assessment. That helps uncover issues such as broken authorization, business logic flaws, insecure APIs, and attack paths that cross several components.
Manufacturers can use the findings as supporting security evidence. Reports may include confirmed vulnerabilities, technical proof, severity ratings, reproduction steps, remediation guidance, and retesting results.
Qualysec does not issue CE marking or replace a Notified Body. Its role is cybersecurity testing, ideally early enough for your team to fix weaknesses before regulatory review.
Conclusion
IVDR has made the route to market more demanding for IVD manufacturers, especially when software and connected systems are involved. The European Commission also makes clear that manufacturers carry primary responsibility for getting their IVDs CE marked for the European market.
For your team, the important part is making sure the regulatory evidence matches the product you are actually building. Security testing, risk decisions, performance evidence, and later product changes all need to remain consistent with that product.
Once you understand CE IVD vs IVDR, the terminology becomes much less confusing. What matters next is keeping the product and its evidence strong enough to support the route you have chosen.
If your diagnostic platform has several connected parts, Qualysec can help you define a testing scope that matches the way the product actually works.
FAQs
1. What is the core difference when looking at CE IVD vs IVDR for software?
CE IVD vs IVDR refers to two different things. CE IVD describes an IVD carrying CE marking, while IVDR sets the regulatory requirements. Software may qualify as an IVD based on its intended purpose and must then follow the applicable compliance route.
2. What are the security testing rules for the CE marking process under IVDR?
IVDR does not prescribe one fixed security test for every product. Annex I Section 16 requires appropriate information security, verification, validation, and protection against unauthorized access. Testing includes penetration testing, API assessment, cloud review, or source code analysis where relevant.
3. Does cloud software that displays lab results require a CE mark medical device certification?
Not automatically. Qualification depends on what the software actually does and its stated medical purpose. Simple storage, transfer, or display functions may not qualify, while software that analyses specimen data or produces diagnostic information may fall under IVDR.
4. Is penetration testing mandatory for IVDR compliance?
IVDR requires manufacturers to verify software security, but it does not name penetration testing as mandatory for every IVD. For connected or externally accessible products, penetration testing can provide useful evidence when the chosen method matches the product’s risks and architecture.
