TL;DR: The IVDR treats cybersecurity as a patient-safety issue: Annex I section 16.2 requires software built to the state of the art including information security, and 16.4 requires you to specify minimum IT security requirements. Notified bodies use MDCG 2019-16 rev.1 as their reference. Class D legacy devices have until 31 December 2027; Class C until 31 December 2028.
Cybersecurity sounds like an IT problem until you picture a lab result that somebody changed on its way to the patient record. Then it’s a patient safety problem, and that’s how the EU IVDR regulation, Regulation (EU) 2017/746, treats it. The rules are scattered across Annex I, and plenty of manufacturers only notice when a notified body asks for security evidence they haven’t produced.
Time matters here. The Class C deadlines have passed (26 May 2026 for the application, 26 September 2026 for the written agreement). Class D devices have until 31 December 2027. The Commission has also proposed changes, which are still working through Parliament and Council. We will cover where security sits in the regulation, what IVDR compliance reviewers ask for and what UK manufacturers need to watch.
Not sure your software even counts as an IVD, or what class it is? Talk to Qualysec’s team before you lock in a certification plan.
What Is the EU IVDR Regulation and Who Does It Cover?
If your product looks at a specimen from the human body and reports something about it, assume the EU IVDR regulation covers you. Reagents, analysers and instruments are in. Software is in too, and that part matters most here. The text names software or a system outright, so a standalone algorithm can be an IVD without any hardware. The EU IVDR regulation replaced the old In Vitro Diagnostic Devices Directive (98/79/EC) on 26 May 2022.
The IVDR applies across EU member states and in Northern Ireland. Great Britain does its own thing, and the UK section below covers it.
Where Do the IVDR Requirements Cover Cybersecurity?
The IVDR requirements live inside the general safety and performance requirements in Annex I, and reviewers read those sections side by side, not one at a time. The Medical Device Coordination Group (MDCG) mapped how they fit together in MDCG 2019-16 rev. 1. The table below follows that map.
| Annex I Section | What It Asks | Evidence a Reviewer Expects |
|---|---|---|
| 1 to 4, 8 | Safe performance, risk reduction, a risk management system, control measures | Risk file that treats security threats as hazards to patient safety |
| 13.1, 13.2(d), 13.5 | Safe connection to other devices, interaction with software and the IT environment, interoperability | Interface specifications, network architecture, compatibility testing |
| 16.1 | Repeatability, reliability and performance, with means to handle a single fault | Fault analysis that includes a compromised component |
| 16.2 | Software developed to the state of the art, including life cycle, risk management, information security, verification and validation | Secure development records and test reports |
| 16.4 | Minimum hardware, IT network and IT security requirements | Documented minimum security environment for the customer |
| 20.1(g), 20.2(m), 20.4.1(ah) | Residual risk and IT requirements passed on to users | Labelling and instructions for use that state your security assumptions |
Section 16.2 carries the most weight. “State of the art” lets a reviewer ask what the industry normally does today. “We followed our usual process” won’t survive that question if your usual process skips threat modelling.
Section 16.4 in Practice: Analyser-to-LIS Connection Configuration
To meet Section 16.4 requirements, manufacturers must specify precise minimum IT and network security baselines rather than relying on default local network settings.
Weak Configuration (Unacceptable)
An analyser sends unencrypted HL7/ASTM diagnostic results over standard TCP/IP to a Laboratory Information System (LIS) assuming the internal hospital network is completely secure.
Stronger Configuration (Section 16.4 Compliant)
The analyser enforces TLS 1.3 encryption for all LIS interfaces, requires mutual certificate authentication (mTLS) between the analyser and LIS, and explicitly outlines these network isolation and cipher requirements in the Instructions for Use (IFU).
MDR and IVDR Regulations: What Is the Same and What Differs?
If you already hold MDR certificates, you’ll be tempted to copy the cybersecurity file across. Much of it will carry over, since MDCG 2019-16 covers both regulations in one document. But the section numbers change, and a couple of provisions don’t line up at all.
| Topic | MDR | IVDR |
|---|---|---|
| Software state-of-the-art requirement | Annex I 17.2 | Annex I 16.2 |
| Minimum IT requirements | Annex I 17.4 | Annex I 16.4 |
| Connection of devices | Annex I 14.1 | Annex I 13.1 |
| Unauthorised access provision | Annex I 18.8 | No equivalent in MDCG’s mapping |
| Classification | Classes I, IIa, IIb, III | Classes A, B, C, D |
| Software classification | Rule 11 | Software takes the class of the device it drives, or is classified on its own under Annex VIII. |
Watch the last row. IVDR classification follows the specimen and the analyte, so you can’t lift the clinical-impact reasoning behind MDR Rule 11 and expect it to fit.
Which EU IVDR Guidelines Apply to Cybersecurity?
Start with MDCG 2019-16 rev. 1, published in July 2020. EU IVDR guidelines cover the MDR and the IVDR, and they deal with the premarket and postmarket sides. One useful idea in it is the “product security context”. That just means describing where your device will live: how physically secure the room is, and what firewall sits in front of its interfaces.
The guidance lists the software bill of materials (SBOM) among the security information manufacturers often share. It also splits responsibility between manufacturers, integrators and operators, although MDCG prefers the phrase “joint responsibility”. Notified bodies use this document as their reference, so copying its structure into your own file saves time.
Read MDCG’s guidance on qualifying and classifying software too, before you decide whether your product is an IVD at all.
What Does IVDR Compliance Look Like for Software and Devices?
An IVDR compliance reviewer wants to follow one trail from threat to control to test to post-release monitoring. If it breaks anywhere, expect questions.
Threat Model and Risk File
Model the whole system for EU IVDR regulation. That means the analyser, the link to the lab information system, any cloud service and the update channel. Then tie every security threat to a patient-safety hazard in your ISO 14971 file. If you skip that step, the reviewer gets two documents and has to connect them alone.
Secure Development Evidence
Section 16.2 asks for development to the state of the art, and IEC 62304 is the usual answer for the software life cycle. It says very little about security. Some teams close that gap with IEC 81001-5-1. Whatever you pick, keep the records: design review minutes, static analysis reports, dependency scans, and pen test results.
Third-Party Components and the SBOM
Your product probably runs on code you didn’t write. There’s an operating system, a handful of open-source libraries and a driver from a hardware vendor. Keep an SBOM for each release and check it against known vulnerabilities regularly. Reviewers want proof that you know what’s shipping.
Vulnerability Handling and Post-Market Surveillance
A post-market plan that says “we’ll monitor” isn’t a plan. Yours needs real names and real steps. How do you judge them against patient safety? How do patches reach devices that are already installed? Log every case, even the ones you close as not exploitable, because those entries show your reasoning.
Gaps That Slow a Review
Four documentation gaps keep turning up in security files for diagnostic products when it comes to EU IVDR regulation.
| Gap | Why It Slows a Review | Fix |
|---|---|---|
| Threat model sits in a separate document | The risk file never cites it, so the reviewer can’t trace threats to hazards | Reference each threat in the ISO 14971 file |
| Instructions for use omit minimum IT requirements | Section 16.4 asks the manufacturer to state them | Add the hardware, network and security baseline to the labelling |
| Component inventory dates from version one | Nobody can show what the current release contains | Regenerate the SBOM with every release |
| Post-market plan says only “monitor vulnerabilities” | No owner, frequency or patch trigger | Name the owner, the review cycle and the decision criteria |
Each one takes an afternoon to fix before submission and weeks to untangle during a review.
A Real Example: Testing a Medical AI Platform Before Submission
A 17-person medical AI company wanted an independent team to perform penetration testing on its product prior to regulatory submission. The assessment covered the web application, desktop client, and API ahead of its 510(k) and EU IVDR review. The desktop application revealed a critical DLL hijacking vulnerability, along with two additional high-severity findings.
By identifying and remediating these vulnerabilities early, the client generated a robust, independent cybersecurity testing report that simultaneously satisfies the documentation and evidence requirements for both FDA and EU IVDR compliance.
Want the same check on your own interfaces before you submit? Qualysec can go through them with you well before the notified body does!
When Do the IVDR Transition Deadlines Fall?
Devices certified under the old directive got extra time. Regulation (EU) 2024/1860 stretched the timeline, and it has applied since 9 July 2024. The exact dates are all in the HPRA’s summary.
| Class | Application to Notified Body | Written Agreement Signed | Legacy Device Deadline |
|---|---|---|---|
| D | 26 May 2025 | 26 September 2025 | 31 December 2027 |
| C | 26 May 2026 | 26 September 2026 | 31 December 2028 |
| B and A sterile | 26 May 2027 | 26 September 2027 | 31 December 2029 |
Dates alone don’t qualify you. The device must keep complying with the old directive with no significant design change. Your quality management system under Article 10(8) also had to be running by 26 May 2025. If you missed an interim date, talk to your notified body now, not next quarter.
What Does the UK Market Require for EU IVDR regulation?
Two markets, one flag, different rules. UK government guidance sets out the position.
- Great Britain: The rules here are a bit looser. A CE-marked IVD that complies with the old directive can stay on the market until its certificate expires or 30 June 2030, whichever comes first. Devices that already meet the IVDR get the same cut-off, 30 June 2030. One thing changed on 26 May 2022, though.
- Northern Ireland: The IVDR regulation has applied here since 26 May 2022, so CE marking is a must.
- UKCA: Don’t count on it outside Great Britain. The EU, the EEA and Northern Ireland don’t recognise it, and UK approved bodies can’t assess conformity for CE marking either.
UK post-market surveillance rules also came into force on 16 June 2025. If you sell in both markets, you need an EU notified body for the CE route. You also need a surveillance process that satisfies both rulebooks.
What Might Change Under the EU IVDR Revision?
The rules are moving, though slowly. On 16 December 2025, the Commission proposed simplifying the MDR and IVDR regulations. According to Simmons & Simmons, the proposal includes:
- clearer cybersecurity requirements and mandatory incident notification
- alignment with the Cyber Resilience Act
- certificates that can last longer than five years
- a lower default class for software, unless it informs or drives clinical management in serious situations
It would amend the EU IVDR regulation without replacing it.
Treat it as a proposal for now. Parliament’s rapporteur presented a draft report on 14 July 2026, and the committee vote is scheduled for 3 December 2026, according to Deutsche Sozialversicherung Europavertretung. The Council wants a general approach by the end of 2026. None of this changes what you owe today.
Quick note on scope: the Cyber Resilience Act doesn’t cover products that fall under the IVDR. Your cybersecurity duties as an IVD manufacturer come from the IVDR alone. The Commission’s alignment plans are meant to keep the two rulebooks (MDR and IVDR regulations) consistent for companies that make both kinds of product.
How Qualysec Supports Your EU IVDR Regulation Readiness
Qualysec isn’t a notified body, and it can’t certify a device. Its job is to produce the security evidence a notified body will accept. Here’s what that looks like in practice.
Medical Device Credentials
Qualysec is CREST-accredited and ISO 27001 certified. Qualysec reports 3,700+ assessments, 520+ clients and 43+ countries served. It has also launched Medysec, a subsidiary that works only on MedTech security.
Threat Modelling and Interface Testing
Qualysec models threats against your analyser, its software and every service it talks to. Then it tests what the model points at: firmware, communication protocols, hardware interfaces and cloud links. You choose the depth. Black box tests what an outsider sees. White box gives the testers your firmware, APIs and source code. Grey box sits in between. Every result maps back onto your risk file.
SBOM and Vulnerability Management Review
Qualysec checks your component inventory against known vulnerabilities. It also tests whether your process catches new ones after release. That gives you something concrete to show for section 16.2.
Retest and Technical File Evidence
Findings arrive with technical proof, business impact and fix guidance, so developers can act on them straight away. Once your team has fixed them, Qualysec retests and records the results with dates. Those reports drop into the technical file without rework.
Conclusion about EU IVDR Regulation
Cybersecurity under the IVDR comes down to one documented argument. Begin with the Annex I table above. Then check your class and transition date for each product, and list the markets you sell in. The December 2025 proposal could shuffle some details. The expectation of secure, documented software will almost certainly stay.
Want to test your evidence first? Book a readiness review with Qualysec, and you’ll get a gap list mapped to Annex I.
Frequently Asked Questions (FAQs)
1. What are the IVDR requirements for cybersecurity?
Most of what the IVDR requirements ask for on cybersecurity sits in Annex I. Section 16.2 is the big one: your software has to be built to the state of the art, and that includes information security. Section 16.4 goes a step further by requiring specific measures for software, IT environments, and data security to prevent unauthorized access.
2. Which EU IVDR guidelines apply to cybersecurity?
MDCG 2019-16 rev. 1. It covers both the MDR and the IVDR, and notified bodies treat it as their go-to reference.
3. How do the MDR and IVDR differ on cybersecurity?
Barely, and mostly in the numbering. What the MDR calls 17.2 and 17.4, the IVDR calls 16.2 and 16.4. The MDR also has an unauthorised access provision in 18.8, which MDCG’s mapping doesn’t pair with an IVDR section.
4. Does the IVDR apply to UK manufacturers?
The IVDR applies if you place devices on the EU or Northern Ireland markets. For Great Britain, CE-marked IVDR-compliant devices are currently accepted until 30 June 2030, and UK-specific rules apply as well.
5. When must IVDs comply with the IVDR?
It depends on class: 31 December 2027 for D, 2028 for C and 2029 for B and A sterile. The conditions in Regulation (EU) 2024/1860 apply as well.
6. Does the Cyber Resilience Act cover IVDs?
No. Products covered by the IVDR sit outside it. The Commission’s December 2025 proposal aims to align the two regimes.
