MDR Cybersecurity Compliance: Complete EU MDR/IVDR Guide for Medical Devices

Kristina Romanenko
May 28
12 min read

Updated: 2 days ago

EU MDR/IVDR Cybersecurity Compliance Guide feature image

The EU Medical Device Regulation (MDR, EU 2017/745) and the In Vitro Diagnostic Regulation (IVDR, EU 2017/746) are the core legal frameworks for placing medical and diagnostic devices on the European Union market.

They replace the former Directives — MDD (93/42/EEC), IVDD (98/79/EC), and AIMDD (90/385/EEC) — and introduce a modern, risk-based regulatory system focused on the entire lifecycle of a device.

Both regulations:

Emphasize patient safety, device performance, and lifecycle accountability
Introduce stricter clinical and performance evidence requirements
Strengthen traceability, transparency, and post-market surveillance
Explicitly integrate software validation and, for the first time, cybersecurity risk management as regulatory requirements

❗ MDR and IVDR apply to both the device and the manufacturer’s systems and processes. Regulatory focus extends beyond the product to include organizational practices that ensure ongoing compliance, security, and patient safety throughout the lifecycle.

I. Device-Level Obligations:

Devices must comply with the General Safety and Performance Requirements (GSPRs) in Annex I.

These include:

Biological, chemical, and mechanical safety
Electrical and software safety
Clinical benefit and intended performance
Protection against misuse, malfunction, and security failures
Cybersecurity and protection against unauthorized access or data tampering

II. Manufacturer-Level Obligations:

Manufacturers must ensure the quality, safety, and regulatory conformity of their devices through internal systems and documentation.

Key responsibilities include:

Operating a certified Quality Management System (QMS) - typically ISO 13485
Implementing a risk management process - ISO 14971 is the baseline
Maintaining a Post-Market Surveillance (PMS) plan
Establishing a vigilance system for incident detection and reporting
Managing technical documentation, verification, and traceability

🔍 Is Your Product Regulated by MDR or IVDR?

Before applying any compliance strategy, determine if your software, hardware, or system qualifies as a medical device or an in vitro diagnostic device under EU law.

🩺 A medical device is any instrument, software, or system intended for use on humans for a medical purpose, and it doesn’t work through drugs or chemical action.

✅ You are likely under MDR if your product:

Diagnoses or treats a condition (e.g., glucose management system)
Prevents disease or injury (e.g., infection prevention algorithms)
Monitors or predicts medical risks (e.g., stroke risk scoring tools)
Supports recovery (e.g., rehab tracking apps)
Replaces anatomical or physiological function (e.g., pump control software)
Analyzes samples from the body, but without diagnostic intent (e.g., non-IVDR pathology viewers)

❓ Ask Yourself:

Is the product used for a medical reason?
Could it influence clinical decisions or outcomes?

👉 If yes, it's likely regulated under MDR.

🧪 An IVD is a device or software used to analyze human samples (blood, saliva, tissue, etc.) outside the body for diagnostic or therapeutic purposes.

✅ Your product likely falls under IVDR if it:

Detects diseases or infections (e.g., PCR interpretation software)
Analyzes inherited conditions (e.g., genetic screening tools)
Assesses disease risk (e.g., DNA-based cancer risk scoring)
Ensures donor-patient compatibility (e.g., transplant matching tools)
Predicts drug responses (e.g., pharmacogenomics decision tools)
Monitors lab values for therapeutic guidance (e.g., HbA1c tracking app)

❓Ask Yourself:

Does it analyze human specimens in vitro?
Does it support clinical decisions or treatment?

👉 If yes, it likely qualifies as an IVD under IVDR.

Classification and Risk-Based Compliance

Once you confirm that your product qualifies as a medical device under MDR or IVDR, the next critical step is to classify it based on its intended purpose and risk level.

🩺 For medical devices, classification criteria are based on factors such as the duration of contact with the patient, the degree of invasiveness, and the parts of the body affected by the device. Devices are grouped into four classes based on risk:

Class I (low risk)
Class IIa (medium risk)
Class IIb (higher risk)
Class III (highest risk)

🧪 For in vitro diagnostic devices, classification is based on the intended purpose, importance of the information provided, and impact on individual and public health if the device fails.

IVDs are categorized into:

Class A (low risk)
Class B (moderate risk)
Class C (high risk)
Class D (very high risk, critical for patient or public health)

Proper classification is critical because it defines the conformity assessment route, the depth of cybersecurity and risk management documentation required, and the level of Notified Body involvement necessary before affixing the CE mark.

💡 For guidance on qualification and classification of software in MDR and IVDR, please refer to MDCG 2021-24.

Conformity Assessment with a Notified Body

Most device classes - except for MDR Class I (non-sterile, non-measuring) and IVDR Class A (non-sterile) - must undergo a conformity assessment by a Notified Body in order to obtain CE marking.

You are responsible for selecting a Notified Body that is designated to assess devices within your specific regulation (MDR or IVDR) and device type.

It is highly recommended to engage with the Notified Body early to clarify:

The expected scope of the assessment
The required technical documentation
Any specific cybersecurity validation or risk management evidence they prioritize

The list of designated Notified Bodies is maintained by the European Commission in the NANDO (New Approach Notified and Designated Organisations) database.

💡 Choosing the right Notified Body is a strategic decision - one that can significantly influence the speed and success of your CE marking process, and reduce the risk of costly delays caused by missing or misinterpreted evidence.

Ask for the Notified Body’s service delivery timeframes when you first engage. Some offer expedited timelines for pre-booked slots - but most require 6–12 months minimum from initial submission to CE marking.

Once your conformity assessment is successful, the Notified Body will issue a CE Certificate, allowing you to affix the CE mark - and legally place your device on the EU market.

Cybersecurity: A Mandatory Lifecycle Requirement

Cybersecurity applies to any device where a security failure could impact safety or performance - regardless of classification.

This includes devices with:

Embedded software
Wireless or network connectivity
Stored or processed data
Interfaces with other systems or mobile devices

The legal and regulatory foundation for cybersecurity under MDR and IVDR includes:

➡️ EU MDR (2017/745) and EU IVDR (2017/746):

Establish legally binding requirements for device safety, performance, and risk management.
Require manufacturers to implement secure-by-design principles, including protection against unauthorized access, data breaches, and cyber threats.
Apply to all medical and IVD devices, not just network-connected or high-risk products.

➡️ MDCG 2019-16: Guidance on Cybersecurity for Medical Devices:

Outlines practical expectations for embedding cybersecurity across design, manufacturing, validation, and post-market monitoring.
Emphasizes threat modeling, security risk assessment, vulnerability management, and lifecycle security controls.
Supports compliance with MDR/IVDR by clarifying what authorities expect in technical documentation, QMS, and PMS planning.

In short, if your medical device or IVD could be ompromised by cybersecurity threats - whether through software flaws, network vulnerabilities, or unauthorized access - MDR and IVDR expect you to manage those risks across the entire product lifecycle: from initial design to post-market surveillance.

Meeting Cybersecurity Requirements for European Market Entry

To achieve CE marking under EU MDR or IVDR, cybersecurity must be systematically embedded into your device's design, development, technical documentation, quality management system (QMS), and post-market activities.

Authorities and Notified Bodies expect clear, traceable evidence that cybersecurity risks have been identified, evaluated, mitigated, and monitored across the entire lifecycle of the product.

🛡️ Integrate Cybersecurity Into Your QMS

Manufacturers are required to operate a comprehensive Quality Management System (QMS) - and that includes the management of cybersecurity risks throughout the device lifecycle.

To meet this requirement, your QMS must go beyond traditional quality controls and explicitly embed security-specific processes, including:

Cybersecurity Governance: Define roles and responsibilities for cybersecurity across product management, engineering, IT, and regulatory affairs. Ensure there's a clear escalation path for cyber incidents and that responsibilities are documented in SOPs and training records.
Risk Management Integration: Your ISO 14971 process must incorporate cybersecurity hazards - such as unauthorized access, data manipulation, malware injection - and treat them with the same level of control as clinical or electrical risks.
Secure Software Development Lifecycle (SSDLC): Adopt and document secure coding practices, threat modeling, peer reviews, vulnerability scanning, and software verification aligned with IEC 62304 and ISO/IEC 81001-5-1.
Supplier & Third-Party Software Controls: Maintain procedures for evaluating and qualifying third-party libraries, frameworks, or tools used in the device. Ensure security expectations are included in supplier agreements and assess third-party SBOMs if available.
Patch & Update Management: Establish controlled, validated processes for issuing cybersecurity updates. This includes testing patches, version tracking, rollback planning, and validation documentation.
Cryptographic Key & Certificate Management: Implement secure handling procedures for keys, certificates, and secrets - including rotation, expiration, and access control.
Secure Configuration & Decommissioning: Define and document secure default settings (e.g., password policies, firewall settings) and procedures for safely deactivating, retiring, or sanitizing devices after use.

📘 Reference: MDR/IVDR Article 10, MDCG 2019-16 Sections 3.1–3.7

🛠️ Design Devices That Are Secure by Default

To comply with Annex I of MDR and IVDR, medical and diagnostic devices must be designed with built-in cybersecurity protections, not as an afterthought, but as a fundamental requirement of product safety and performance.

Here’s what to implement at the device level:

Access Control & Authentication: Enforce user authentication, session timeouts, and, where appropriate, multi-factor authentication. Prevent hardcoded passwords or unverified user access.
Data Encryption: Encrypt sensitive data both at rest (e.g., device logs, stored patient data) and in transit (e.g., Bluetooth, Wi-Fi, or USB communication). Use current cryptographic standards (e.g., AES-256, TLS 1.2 or higher).
Security Logging & Monitoring: Capture relevant system and security events (logins, updates, data access, errors) in tamper-resistant logs. Ensure these logs are auditable and reviewed periodically.
Secure Software & Firmware Updates: Updates must be digitally signed, authenticated, and validated on the device. Ensure rollback protection is in place.
Interface Hardening: Disable unused ports or communication protocols. Apply rate-limiting and input validation to prevent command injection or abuse.
Fail-Safe Behavior & Recovery: Design devices to default to a safe operational mode in the event of a system fault, unauthorized access, or update failure.
Denial of Service (DoS) Protection: Protect against resource exhaustion attacks (e.g., repeated login attempts, large malformed inputs) that could impair core safety functions.

📘 Reference: MDR Annex I Sections 17.2–17.4; IVDR Sections 16.2–16.4; MDCG 2019-16 Section 3.4

📁 Build Technical Documentation That Stands Up to Scrutiny

Your Technical Documentation is more than a folder of forms - it’s your legal and operational proof that your device meets all essential cybersecurity requirements.

Ensure your documentation includes:

Security Risk Management File: A complete risk traceability matrix that links identified threats to controls, validation results, and residual risk justifications.
SBOM (Software Bill of Materials): A list of all embedded, third-party, and open-source software components. Include version info, known vulnerabilities (CVEs), and patch status.
Verification & Validation Reports: Real-world testing to prove effectiveness of your security controls:
- Penetration test reports
- Static and dynamic code analysis
- Fuzzing or boundary condition testing
Update & Patch Management Procedures: Describe your strategy for releasing updates, including validation testing, rollback steps, and user communication.
Secure Use & Labeling: Document how users should configure and maintain security (e.g., password setup, network segregation, update policies). This also includes IFU (Instructions for Use) and security guidance in user manuals.
Minimum Operating Environment Requirements: Define the technical environment required to operate the device securely (e.g., firewalls, isolation requirements, supported OS/firmware versions).

📘 Reference: MDR/IVDR Annex II & III, MDCG 2019-16 Sections 4.1–4.3

🔄 Operate Continuous Post-Market Cybersecurity Surveillance

Cybersecurity does not end at market launch. Manufacturers are obligated to proactively monitor for emerging threats and respond rapidly to vulnerabilities.

Your Post-Market Surveillance (PMS) plan must:

Continuously Monitor Vulnerabilities: Track threats from CVE feeds, security advisories, open-source software disclosures, and manufacturer notices. Document each finding and evaluate impact.
Manage Coordinated Vulnerability Disclosure (CVDP): Maintain a structured channel (e.g., security.txt, website page, dedicated inbox) to receive vulnerability reports from researchers or customers. Include timelines and responsibilities.
Track & Validate Patches: Maintain a secure development and release process for all security updates. Document testing, deployment methods, and communication with end-users or healthcare providers.
Escalate Serious Incidents: Define criteria and thresholds for what qualifies as a serious cybersecurity incident. Ensure such events are reported to Competent Authorities under MDR/IVDR vigilance timelines (typically 15 days or less).
Update Your Risk & PMS Files: Every confirmed vulnerability or incident must result in a review and update of your risk management file, technical documentation, and PMS records - demonstrating that the device lifecycle is actively managed.

📘 Reference: MDR Articles 83–89; IVDR Articles 78–84; MDCG 2019-16 Sections 5.1–5.2

Key Steps in the Notified Body Conformity Assessment Process

1️⃣ Application Submission

Submit a structured application with details about your company, device classification, QMS scope, and cybersecurity readiness. This includes documentation of your cybersecurity risk management process, secure update mechanisms, SBOM strategy, and post-market surveillance procedures for cyber threats.

2️⃣ QMS Assessment

Most devices require a QMS audit, typically aligned with ISO 13485. Auditors check how cybersecurity is embedded in lifecycle procedures. For software or connected devices, SSDLC, vulnerability handling, and patch deployment must be clearly defined and implemented.

3️⃣ Technical Documentation Review

A Technical Specialist (with relevant product expertise) evaluates your submission for compliance with MDR/IVDR - including Annex I GSPRs and Annex II technical documentation. Additional cybersecurity or software experts may be consulted depending on the complexity and risk class of the device.

4️⃣ Clarifications and Corrective Actions

If gaps or inconsistencies are found, the Notified Body issues formal questions or nonconformities. You must provide responses, updated documents, or additional evidence - often in one or more review rounds. Cybersecurity-related issues (e.g. incomplete SBOM, unverified update strategy, weak traceability) are common causes of delay at this stage.

5️⃣ Certification Decision

Once all technical and QMS elements meet regulatory requirements, a final internal review is conducted. If accepted, the Notified Body issues your CE Certificate, confirming conformity with MDR or IVDR - including all applicable cybersecurity requirements.

6️⃣ Post-Certification Surveillance

After CE marking, your device remains under ongoing NB oversight. Surveillance activities include scheduled audits, technical documentation spot checks, and vigilance system reviews. For cybersecurity, this includes evaluating how you monitor for new threats, issue security patches, and update risk files based on post-market data.

⚠️ Common Causes of CE Marking Delays - and How to Avoid Them

CE marking delays can derail your roadmap, push back launch dates, and cost you key partnerships. And yet, most slowdowns are caused by the same three preventable issues.

Here’s what typically holds companies back - and how you can stay ahead of it.

❗Unclear Product Classification

If your product is software-based, multifunctional, or uses AI, getting the classification wrong is easy - and costly. Misclassification can stall your submission, trigger rework, or lead to a mismatch between your device scope and the documentation you're asked to deliver.

❗Incomplete Cybersecurity Documentation

Today’s Notified Bodies expect more than a general statement about encryption or access control. They want to see a complete SBOM, tested update mechanisms, a risk-based control plan, and real-world validation results. Anything less slows down approval.

❗Insufficient Performance Validation or Traceability

If you can’t clearly connect your design inputs, cybersecurity controls, and testing outcomes - reviewers can’t evaluate your submission. This is especially true for connected or software-heavy devices where safety and security are deeply linked.

❗Skipping Security Testing or Verification

Some companies assume their product meets CE requirements without formal testing - but security testing is essential. Notified Bodies expect real evidence like penetration tests, SBOM verification, and update validation. Without it, your submission is likely to be delayed or rejected.

The good news: these issues are fixable - and preventable. Here’s how leading teams keep their CE process moving:

Engage with a Notified Body early to confirm classification, documentation scope, and cybersecurity expectations.
Assign clear ownership of cybersecurity compliance inside your team. This isn’t just an IT concern - it spans development, QA, and regulatory.
Start documentation early - begin tracking software architecture, risk controls, and cybersecurity decisions from day one. Your submission will require extensive evidence to demonstrate compliance.
Use traceability from day one - link every control to a requirement, and every test to a risk. It makes the review faster, cleaner, and easier to approve.
Bring experienced cybersecurity professionals (internally or externally) for penetration testing, SBOM management, or secure SDLC design. Experts like Sekurno can step in to accelerate readiness.

CE marking is not just about proving you're compliant - it's about showing you're ready. And readiness starts with clarity, ownership, and the right support.

Final Steps: Build a Strong Cybersecurity Foundation for MDR/IVDR Compliance

Achieving cybersecurity compliance under EU MDR and IVDR is about building confidence in your product, protecting patients, and securing your market position.

To lay the foundation for lasting compliance, start with these core practices:

Assign a dedicated cybersecurity lead to oversee design, development, documentation, and post-market response.

Create a self-assessment checklist to benchmark your current state and chart your compliance roadmap.

Perform threat modeling and risk assessment to identify cybersecurity threats that could impact device safety or performance.

Apply secure development practices, such as secure coding standards, peer reviews, and version-controlled pipelines.

Conduct penetration testing to validate protections and uncover real-world vulnerabilities before your device reaches users.

Build and maintain a Software Bill of Materials (SBOM) to track software components and associated risks.

Set up vulnerability monitoring and incident response processes to manage post-market threats and maintain compliance.

These steps form a practical, scalable baseline to ensure cybersecurity is built into your device — and ready to stand up to regulatory scrutiny.

Not Sure Where Your Cybersecurity Posture Stands Under MDR or IVDR?

Take our quick self-assessment to identify areas for improvement and see where you stand.

➡️ Start the MDR/IVDR Cybersecurity Self-Assessment

About The Author & Sekurno

Kristina Romanenko is an Information Security Account Manager at Sekurno and a certified ISO/IEC 27001 Implementer (PECB). With over 6 years of experience in IT and cybersecurity, Kristina helps organizations confidently navigate regulatory frameworks such as GDPR, CCPA, HIPAA, and ISO 27001. She supports clients in meeting compliance requirements, reducing risk exposure, and building long-term trust with customers and partners.

Sekurno is a globally recognised cybersecurity firm specializing in Penetration Testing, Application Security and Cybersecurity Compliance. Our expert team can help you build a cybersecurity program that’s audit-ready from day one.