A CE-marked connected medical device is not the end of the security question; it is the start of an operational relationship. For hospitals, cyber resilience is determined not only in the product comparison but also by patch capability, vulnerability communication, secure integration and the treatment of technology that can no longer be updated. Those subjects therefore belong in procurement, acceptance and operations, coordinated between medical engineering, IT, procurement, clinical teams and suppliers.
The legal foundation is lifecycle security
The Medical Devices Regulation (MDR) has applied since 26 May 2021 and the In Vitro Diagnostic Medical Devices Regulation (IVDR) since 26 May 2022. As EU Regulations, their requirements—especially MDR Annex I, section 17, and IVDR Annex I, section 16—form the product-law foundation for safety and cybersecurity. The assessment does not end when a device is placed on the market: risk management, technical documentation, post-market surveillance and, where necessary, corrective action must also address new or changing cyber risks.
Place MDCG and ENISA correctly: useful guidance, not a new hospital duty
MDCG 2019-16 Rev.1, issued in July 2020, explains the practical application of MDR/IVDR cybersecurity requirements. It is expressly non-binding and does not represent an official position of the European Commission. ENISA’s July 2026 procurement guidance for hospitals and healthcare providers is likewise an informative report, not a new regulatory obligation. Both documents are nevertheless useful: they translate lifecycle security into testable procurement and operational questions. They do not, by themselves, impose statutory duties on hospitals.
Define roles clearly instead of moving responsibility around
Product-law responsibility under the MDR/IVDR rests with the manufacturer. It must include cybersecurity in post-market surveillance, consider experience including third-party components and implement required corrective action. Medical-device vigilance routes apply to serious incidents and field safety corrective actions. Operators and integrators should, by contrast, make their respective tasks explicit for the particular installation and contract:
- Manufacturer: provide security information, assess vulnerabilities, provide authorised remediation and updates, and manage any necessary vigilance or field action.
- Hospital as operator: maintain the intended operating environment, follow manufacturer security instructions, apply authorised patches in a controlled manner, enable infrastructure and staff, and report suspected security events without undue delay.
- Integrator: configure the solution securely, document interfaces and configuration, provide instruction, and support collaboration in patch and incident processes.
Patching is an operational service, not an incidental product feature
Vulnerabilities change in operation; controls adopted before placing on the market may therefore later cease to be sufficient to maintain an acceptable benefit-risk balance. Procurement documents should consequently go further than a general promise of “updates”. They need a defined support period, a tested manufacturer-authorised patch process, agreed maintenance windows, fallback options and clear alignment with clinical availability requirements. Components, interfaces and accompanying software also need a traceable allocation.
Vulnerability coordination needs a clinical and technical handover point
A cyber event is not automatically an MDR/IVDR serious incident. A dependable handover point is therefore needed: the hospital identifies, contains and records a suspicion; the manufacturer assesses the impact on the medical device and decides on remediation and, where relevant, vigilance or field action; the hospital implements agreed mitigations. MDCG highlights the exchange of information on vulnerabilities and threats, remediation and incident response. ENISA recommends requiring a reachable reporting channel, a process to receive reports, timely disclosure and remediation, and monitoring of manufacturer advisories in the contract.
Manage legacy and unpatchable systems in a controlled way
The MDR and IVDR do not create a blanket requirement to retrofit or replace every older device immediately. A vulnerable legacy interface can nevertheless become relevant to patient safety. Where a patch is unavailable or unsuitable, compensating controls should be documented, selected on a risk basis and aligned with clinical needs:
- maintain a current inventory showing versions, dependencies, support and end-of-support status;
- segment or isolate networks and interfaces according to risk;
- time-limit, multi-factor protect and log remote access;
- retain clinical fallback procedures and escalation contacts for an outage;
- plan a replacement, migration or exit option contractually and economically.
The procurement checklist: security as a demonstrable delivery
An award for a connected medical device or IVD should not depend only on performance, price and CE marking. The hospital should obtain a verifiable commitment for the following points across the product, integration and lifecycle:
- a security profile and a named, reachable security contact;
- a process to receive, assess, disclose and remediate reported vulnerabilities;
- tested, authorised patches with maintenance windows, responsibilities and a fallback route;
- a binding support, end-of-support and replacement or exit arrangement;
- integration information for interfaces, ports, protocols, segmentation and logging;
- time-limited, multi-factor protected and logged remote maintenance;
- an incident escalation path that distinguishes cyber events from MDR/IVDR vigilance and field safety corrective actions.
NIS2 and the CRA remain a different regulatory context
NIS2 may create additional sectoral requirements for healthcare entities, while the Cyber Resilience Act establishes a horizontal product-regulatory framework. That context neither replaces the MDR/IVDR product perspective nor merges the reporting routes. The distinction between a cyber incident and a medical-device serious incident remains particularly important. For a particular hospital, contracts, national law and the actual operational role also require assessment.
Conclusion: buy a secure operational relationship, not only equipment
The practical procurement decision is therefore this: do not procure a connected medical device without verifiable commitments on vulnerability communication, patch capability, secure integration, remote maintenance and a route for technology that can no longer be patched. This does not turn ENISA or MDCG guidance into a new hospital obligation. It does create a stronger basis for manufacturer duties, operator processes and integration services to work together when security is at stake.
Primary sources and scope of validity
- MDCG 2019-16 Rev.1: Guidance on Cybersecurity for medical devices, MDCG guidance issued in July 2020; non-binding.
- Regulation (EU) 2017/745 (MDR), official EU legal act; applicable since 26 May 2021.
- Regulation (EU) 2017/746 (IVDR), official EU legal act; applicable since 26 May 2022.
- ENISA: Procurement guidelines for the cybersecurity of hospitals and healthcare providers, informative report issued in July 2026.
- European Commission: MDCG guidance index, context for MDCG-endorsed guidance.