A connected medical device cannot carry the CE mark in the EU unless its manufacturer can show that information security was designed in, verified and maintained, yet the Medical Device Regulation never uses the word "cybersecurity" in a dedicated article. The obligations sit in a handful of general safety and performance requirements in Annex I of Regulation (EU) 2017/745 (MDR) and the matching sections of the In Vitro Diagnostic Regulation (EU) 2017/746 (IVDR), and the Medical Device Coordination Group explains how to meet them in guidance document MDCG 2019-16. This guide sets out who is covered, the exact Annex I provisions, what MDCG 2019-16 expects before and after the device is placed on the market, current transitional dates, how non-compliance is enforced, and the steps a manufacturer should take. It is written for device manufacturers, notified body reviewers' counterparts in regulatory affairs, and hospital security teams who receive these devices. For the United States equivalent see the FDA Medical Device Cybersecurity Guide; for hospital-side controls see the Medical Device Security Guide.
Status line: checked 27 October 2026. The MDR has applied since 26 May 2021; transitional dates are as amended by Regulation (EU) 2023/607. The MDCG 2019-16 version reviewed is Rev.1 (July 2020), endorsed by the MDCG and explicitly not legally binding. Check the Commission's MDCG guidance page for later revisions before relying on section numbers.
Key takeaways
- Four Annex I sections carry the legal duty. MDR Annex I sections 17.2, 17.4 and 18.8, plus the instructions for use requirement in 23.4(ab), are the cybersecurity requirements a notified body assesses (IVDR 16.2, 16.4 and 20.4.1(ah) for diagnostics).
- MDCG 2019-16 is the playbook, not the law. It interprets those sections, describes secure design, security risk management, verification and documentation, and is what notified bodies use as their reference, but it is not binding.
- Security risk links to safety risk. The guidance keeps a separate security risk management plan, but any security risk with a possible safety impact must enter the safety risk assessment, and over-restrictive security can itself be a safety hazard.
- Responsibility is joint, liability is not. Integrators, operators and hospitals have defined expectations, but the manufacturer alone carries the legal obligations and must state minimum IT requirements and security settings in the instructions for use.
- Post-market work is mandatory. Vulnerabilities feed post-market surveillance, periodic reports, vigilance under MDR Article 87 and field safety corrective actions such as patches.
Scope: who and what is covered
The MDR applies to medical devices and their accessories placed on the EU market, including software that is itself a medical device (software as a medical device) and software that drives or influences a device. The IVDR applies the same approach to in vitro diagnostic devices. Any device that includes electronic programmable systems or software, or that connects to a network, falls within the cybersecurity provisions below.
| Party | Role under MDR and MDCG 2019-16 | Cybersecurity expectation |
|---|---|---|
| Manufacturer | Holds the legal obligations, signs the declaration of conformity | Secure design, security risk management, verification, technical documentation, IFU security information, post-market monitoring and patching |
| Notified body | Conformity assessment for class IIa, IIb, III (and some IVD classes) | Reviews technical documentation and evidence that Annex I 17.2, 17.4 and 18.8 are met |
| Integrator | Combines devices and IT into a system | Follows manufacturer IFU and security information; agreements clarify who does what |
| Operator and healthcare provider | Runs the device in its operating environment | Physical security, access control, network segmentation, patching, malware protection, staff training (MDCG 2019-16 chapter 7) |
| User | Clinician or patient using the device | Follows IFU, reports suspected incidents |
MDCG 2019-16 defines the "operating environment" as any IT or network asset that interacts with the device and is not supplied by the manufacturer. Its design principle is that the device should be as autonomous as possible, keeping reliance on environmental controls to a minimum, with defence in depth.
Key obligations
The Annex I provisions
| MDR Annex I | IVDR Annex I | Subject | What it means in practice |
|---|---|---|---|
| 17.2 | 16.2 | Software developed and manufactured in line with the state of the art, taking into account development life cycle, risk management, including information security, verification and validation | A secure development life cycle with security requirements, threat modelling, code review and testing as recorded evidence |
| 17.4 | 16.4 | Manufacturers set out minimum requirements concerning hardware, IT network characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended | A documented minimum operating environment that hospitals can check before connecting the device |
| 18.8 | n/a (IVDR equivalents in 16.4) | Devices designed to protect, as far as possible, against unauthorised access that could hamper the device from functioning as intended | Authentication, authorisation, secure interfaces and protected maintenance access |
| 23.4(ab) | 20.4.1(ah) | Instructions for use state minimum requirements on hardware, IT networks and IT security measures | IFU and security documentation for the customer |
What MDCG 2019-16 adds
- Secure by design: section 3.1 describes eight secure-by-design practices running from security management through to security guidelines for users, aligned with the device life cycle.
- Security capabilities: Table 3 gives an indicative list including authorisation, audit controls, node authentication, person authentication and transmission confidentiality. A manufacturer should justify which apply and how each is implemented.
- Security risk management: the same elements as safety risk management (ISO 14971 style), documented in a separate security risk management plan, with security risks that may affect safety carried into the safety risk assessment (chapter 3.2 and Annex IV).
- Verification and validation: technical documentation (MDR Annexes II and III) must justify, validate and verify the security solutions adopted, for example through security testing.
- Customer information: IFU should cover security configuration, secure default settings, validated update procedures, minimum IT requirements, recommended controls and backup and restore. Chapter 4.3 lists further material for healthcare providers, such as network port lists, network diagrams and log descriptions. The guidance names the Manufacturer Disclosure Statement for Medical Device Security (MDS2) as an accepted form for this information.
- Post-market: maintaining risk management, modifying risk controls and issuing patches, updating verification and benefit-risk analysis, and updating technical documentation after release.
Post-market surveillance and vigilance
| MDR article | Obligation | Cybersecurity application |
|---|---|---|
| Articles 83 and 84 | Post-market surveillance system and plan | Vulnerability intake, threat intelligence, coordinated disclosure handling, component (SBOM) monitoring |
| Articles 85 and 86 | Post-market surveillance report and periodic safety update report (PSUR) | Summary of vulnerabilities found, risk evaluations and fixes |
| Article 87 | Reporting of serious incidents and field safety corrective actions | A cyber incident that causes or could cause death or serious deterioration in health is reportable; a security patch deployed as a corrective action may be a field safety corrective action |
| Article 88 | Trend reporting | A statistically significant rise in security-related incidents |
MDCG 2019-16 chapter 5.2 lists International Medical Device Regulators Forum (IMDRF) codes for cybersecurity-related problems and root causes, so that reports use a common vocabulary. Article 87 sets short reporting deadlines, counted in days from awareness and shorter for the most serious cases, so check the article text and build the clock into the vulnerability handling procedure.
Timeline and current status
| Date | Event |
|---|---|
| December 2019 | MDCG 2019-16 first published |
| July 2020 | MDCG 2019-16 Rev.1 published (the version reviewed for this guide) |
| 26 May 2021 | MDR date of application; new devices certified under the MDR must meet Annex I in full |
| 26 May 2024 | Legacy devices relying on the extended transition needed a quality management system under Article 10(9) and a formal application lodged with a notified body (Article 120(3c)) |
| 26 September 2024 | Written agreement between notified body and manufacturer required for those legacy devices |
| 31 December 2027 | End of transition for class III devices and class IIb implantables (with listed exceptions) holding Directive certificates |
| 31 December 2028 | End of transition for other class IIb, class IIa, and class I sterile or measuring devices, and for devices up-classified to need a notified body |
The practical effect for security teams is that a growing share of the installed base is moving from Directive certificates, where cybersecurity expectations were thin, to MDR certificates assessed against Annex I 17.2, 17.4 and 18.8. A device certified under the old Directives and still sold under the transition must still meet MDR requirements for post-market surveillance and vigilance.
Overlapping EU laws
- Cyber Resilience Act: products covered by the MDR and IVDR are excluded from the CRA, so device manufacturers follow MDR Annex I rather than CRA Annex I for the device itself. Non-device software and accessories they also sell may still fall under the CRA. See the EU Cyber Resilience Act Guide.
- NIS2: hospitals and many healthcare providers are in scope of NIS2 as essential or important entities, which is why operators increasingly demand MDS2 forms, SBOMs and patch commitments in procurement. See the NIS2 Directive Guide.
- AI Act: AI systems that are, or are safety components of, devices requiring notified body assessment under the MDR are high-risk AI systems, adding requirements on accuracy, robustness and cybersecurity. See the EU AI Act High-Risk AI Systems Guide.
Enforcement and penalties
- Conformity assessment: for class IIa and above the notified body can refuse, suspend or restrict a certificate when the technical documentation does not show Annex I compliance, and cybersecurity is now a routine line of questioning.
- Competent authorities: national competent authorities carry out market surveillance and can require corrective action, restrict availability, or order withdrawal or recall of non-compliant devices.
- Penalties: The MDR requires Member States to lay down effective, proportionate and dissuasive penalties for infringements. Amounts differ by country, so check national implementing law.
- Vigilance failures: failing to report a serious incident or field safety corrective action on time is a separate infringement from the underlying vulnerability, and is the one regulators find easiest to prove.
- Liability: a device harmed by a known, unpatched vulnerability exposes the manufacturer to product liability claims, separate from regulatory action.
What it means for AI agents and non-human identities
Annex I 18.8 is, at its core, an identity requirement: protect against unauthorised access. In connected devices most of that access is by machines rather than people.
| Non-human identity | Typical weakness | Control that evidences 17.2, 17.4 and 18.8 |
|---|---|---|
| Device identity (certificate or key used to talk to the hospital network or cloud) | Shared keys across a product line, no revocation | Per-device credentials provisioned in manufacturing, documented renewal and revocation. See the Device and IoT Identity Guide. |
| Service and maintenance accounts | Hard-coded or default service passwords documented in service manuals | Unique per-device or per-engineer credentials, logged maintenance sessions, no hidden accounts |
| Cloud and companion app API credentials | Long-lived API keys embedded in apps or gateways | Short-lived tokens, secret storage, rotation without a device recall |
| Software update signing keys | Keys on developer workstations | HSM-held signing keys, verified updates, documented validated update procedure in the IFU |
| Integration accounts (HL7, DICOM, EHR interfaces) | One shared account for every interface | Per-interface accounts with least privilege, as listed in the operator security information |
AI features add two issues. A device that uses an AI model, or a clinical assistant that can query or configure devices, has new interfaces and data flows that belong in the security risk assessment and in the IFU's list of ports, services and accounts. And AI agents used by manufacturers to triage vulnerability reports or generate test cases need credentials to repositories, ticketing and telemetry: they are non-human identities in the manufacturer's quality system and should be owned, scoped and logged like any other. See the Healthcare Identity Security Guide for the provider side.
Compliance steps
- Classify and scope. List devices and software with electronic programmable systems or network connectivity, their risk class and their certificate status (MDR or legacy Directive with transition date).
- Write the security risk management plan. Align it to the safety risk management process, define how security risks with safety impact cross over, and record the threat model per device.
- Map Annex I to evidence. For 17.2, 17.4, 18.8 and 23.4(ab), list the design inputs, controls, verification activities and documents that prove each one, using the Table 3 security capabilities as a checklist.
- Test before release. Run vulnerability scanning, fuzzing of external interfaces and penetration testing, and record results in the technical documentation with closure or risk acceptance.
- Prepare customer security information. Produce the IFU security section, an MDS2, network port and service lists, a software bill of materials and the validated patch procedure. See the SBOM Guide.
- Set up coordinated vulnerability disclosure. Publish an intake channel, triage with safety and security together, and link outcomes to Articles 83 to 88. See the Bug Bounty and Vulnerability Disclosure Guide.
- Define the vigilance decision. Write the criteria for when a vulnerability or exploitation becomes a reportable serious incident or field safety corrective action, with IMDRF coding, and rehearse it.
- Plan support periods. State how long security updates will be provided and how end of support is communicated to operators.
Measuring progress
- Annex I evidence completeness: share of in-scope devices with a traced evidence map for 17.2, 17.4 and 18.8.
- Patch latency: median days from vulnerability confirmation to validated patch availability, by severity.
- Component exposure: number of shipped devices with known exploited vulnerabilities in third-party components.
- Customer information coverage: share of products with a current MDS2 and SBOM.
- Vigilance timeliness: share of reportable events reported within the Article 87 deadline.
Framework mapping
| MDR or MDCG element | NIST CSF 2.0 | NIST SP 800-53 Rev 5 |
|---|---|---|
| 17.2 secure development life cycle | PR.PS-01 | SA-8, SA-15, SA-11 |
| Security risk management (MDCG chapter 3.2) | ID.RA-05 | RA-3 |
| 18.8 protection against unauthorised access | PR.AA-01, PR.AA-05 | IA-2, IA-5, AC-3 |
| 17.4 and 23.4(ab) minimum IT requirements | ID.AM-02 | CM-2, CM-8 |
| Post-market surveillance and patching | ID.RA-01, PR.PS-02 | RA-5, SI-2 |
| Article 87 vigilance | RS.CO-02, RS.AN-03 | IR-6, IR-4 |
| Supplier components | GV.SC-04, GV.SC-07 | SR-3, SR-4 |
Common failure patterns
- Security buried in the safety file: no separate security risk management plan, so threats without an obvious safety hazard are never analysed.
- IFU that says "use a secure network": 17.4 and 23.4(ab) want concrete minimum requirements, ports and settings, not a generic instruction.
- Default and shared service credentials: a maintenance password that is the same on every unit fails 18.8 and is usually found by the first hospital penetration test.
- No route from vulnerability to vigilance: security teams fix the issue, but nobody decides whether it was a field safety corrective action, so reports are late or missing.
- Third-party components outside post-market surveillance: operating system and library vulnerabilities in shipped devices are not tracked against an SBOM.
Practitioner checklist
- Record risk class, certificate route and transition date for each connected device.
- Maintain a security risk management plan linked to the safety risk file.
- Keep an evidence map for MDR Annex I 17.2, 17.4, 18.8 and 23.4(ab) (IVDR 16.2, 16.4, 20.4.1(ah)).
- Justify each MDCG 2019-16 Table 3 security capability as implemented or not applicable.
- Remove default and shared service credentials; issue per-device identities.
- Ship an IFU security section, MDS2, port list and SBOM with every release.
- Run security testing before release and record it in the technical documentation.
- Write vigilance criteria for cyber events with IMDRF codes and Article 87 deadlines.
- Publish a disclosure channel and a stated security support period.
Standards and references
- EUR-Lex: Regulation (EU) 2017/745 on medical devices (consolidated text)
- EUR-Lex: Regulation (EU) 2023/607 amending the MDR transitional provisions
- European Commission (MDCG): MDCG 2019-16 Rev.1 Guidance on Cybersecurity for medical devices
- NIST: Cybersecurity Framework (CSF) 2.0
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- FDA: Cybersecurity in Medical Devices, Quality Management System Considerations and Content of Premarket Submissions
Related NHI Mgmt Group resources: FDA Medical Device Cybersecurity Guide · Medical Device Security Guide · Healthcare Cyber Regulation Map · Device and IoT Identity Guide. This guide summarises the cybersecurity provisions of the EU Medical Device Regulation and MDCG 2019-16 and is not legal advice.