Cybersecurity for Medical Device Manufacturers: MDR, MDCG 2019-16 and NIS2

Which rules apply to you

Medical device cybersecurity is regulated through the MDR itself, not through a separate cyber law, and that has been the case since 26 May 2021.

MDR (EU) 2017/745, Annex I. Section 17.2 requires software to be developed and manufactured according to the state of the art, taking into account the development life cycle, risk management including information security, verification and validation. Section 17.4 requires you to set out minimum requirements for hardware, IT network characteristics and IT security measures, including protection against unauthorised access. The IVDR (EU) 2017/746 has the same text in sections 16.2 and 16.4. Articles 83 to 87 add post-market surveillance and vigilance: a vulnerability that could lead to a serious incident is a post-market matter, with the reporting deadlines of Article 87.

MDCG 2019-16 rev.1 is the guidance notified bodies and competent authorities use. It expects a security risk management process linked to the ISO 14971 safety risk management, defined security capabilities, a documented operating environment, verification including penetration testing, and instructions for use that tell the operator what the device needs from the network. IEC 81001-5-1 describes the secure product life cycle that fits this, and IEC 62304 the software life cycle.

Cyber Resilience Act (EU) 2024/2847. Article 2(2) excludes MDR and IVDR products. Anything you sell that is not a device or accessory, for example a general-purpose gateway or software with no medical purpose, falls under the CRA with reporting duties from 11 September 2026 and full application from 11 December 2027.

NIS2 via the German BSIG. Manufacturing of medical devices is a sector in Annex II of the NIS2 Directive. A manufacturer with 50 or more employees or more than 10 million euros in turnover and balance sheet total is an important entity under § 28 BSIG, with the risk management measures of § 30 and the reporting duties of § 32. Your hospital customers are essential entities and pass supply chain requirements down to you.

US market. Section 524B of the FD&C Act requires a cybersecurity plan, a software bill of materials and a process for post-market vulnerabilities for every “cyber device” submitted to the FDA.

Where attackers start

A connected medical device has the attack surface of an IoT product plus the data sensitivity of a health record.

• Debug and service ports: UART, JTAG or SWD left active on production units, often with a root shell behind a known service password.
• Firmware and update path: unencrypted flash, update images that are checked for a version number but not for a signature, recovery modes that accept any image.
• Wireless interfaces: BLE pairing without authentication on wearables and home devices, Wi-Fi provisioning over an open access point, proprietary radio links without encryption.
• Companion apps and cloud APIs: the device is small, the backend holds every patient’s data. Object-level authorisation and token handling are where it goes wrong.
• Clinical network interfaces: DICOM, HL7 and vendor service protocols designed for trusted networks, plus remote service access from your own support team.
• Legacy operating systems in imaging and laboratory equipment with a ten-year service life.

What assessments typically find

Typical findings from penetration tests of connected medical and household appliances, anonymised: a UART console that dropped into a root shell without a password; eFuses for flash read-out protection never programmed, so the firmware and the Wi-Fi credentials could be read with a 20-euro adapter; an update mechanism that verified a checksum but no signature; a companion-app API that returned another user’s measurement history when the record identifier was changed; a BLE control characteristic writable by any nearby phone after a “Just Works” pairing; and a Linux-based device with no mandatory access control, so one compromised service owned the whole system.

The fixes are well known: disable or authenticate debug access, program the eFuses, sign updates, enforce authorisation per object in the API, use authenticated BLE pairing, add SELinux and nftables policies. Each of these also closes a gap against Annex I section 17.2 and a security capability in MDCG 2019-16.

A sensible first project

Pick one device, ideally the one next in line for a notified body review or a significant change.

1. Scoping and security risk analysis: interfaces, data flows, operating environment, intended use and foreseeable misuse, linked to your ISO 14971 file. Two to three days with your development and regulatory team.
2. Penetration test of the device in our lab: hardware and debug ports, firmware extraction and analysis, wireless interfaces, update path, companion app and cloud API against a test tenant. Two to three weeks.
3. Mapping of the results to Annex I sections 17.2 and 17.4, the MDCG 2019-16 security capabilities and IEC 81001-5-1 activities, delivered as a prioritised fix list and as text you can place in the technical documentation.
4. Fix and retest, then carry the architecture decisions into the next product.

Typical effort for steps 1 to 3 is 15 to 25 person-days, which is 18,000 to 40,000 euros at market rates. Compared with the cost of a notified body round that fails on cybersecurity, it is the cheaper path.

What Zyberum does and does not do here

We test devices, companion apps and backends, write the security risk analysis and the test evidence for your technical documentation, help your engineers harden debug ports, boot chain and Linux platform, and set up the vulnerability handling process that post-market surveillance and NIS2 both need. We train embedded developers in secure coding. We are not a notified body, do not issue CE marks and do not do your clinical evaluation or regulatory submission; we work alongside your regulatory affairs team so the cybersecurity part holds up.