Cybersecurity in der Medizintechnik: MDR, MDCG 2019-16 und NIS2

Welche Regeln für dich gelten

Cybersecurity für Medizinprodukte ist über die MDR selbst geregelt, nicht über ein eigenes Cybergesetz, und das seit dem 26. Mai 2021.

MDR (EU) 2017/745, Anhang I. Abschnitt 17.2 verlangt, dass Software nach dem Stand der Technik entwickelt und hergestellt wird, unter Berücksichtigung von Entwicklungslebenszyklus, Risikomanagement einschließlich Informationssicherheit, Verifizierung und Validierung. Abschnitt 17.4 verlangt, dass du Mindestanforderungen an Hardware, IT-Netzwerkeigenschaften und IT-Sicherheitsmaßnahmen festlegst, einschließlich Schutz vor unbefugtem Zugriff. Die IVDR (EU) 2017/746 hat denselben Text in den Abschnitten 16.2 und 16.4. Artikel 83 bis 87 ergänzen Überwachung nach dem Inverkehrbringen und Vigilanz: Eine Schwachstelle, die zu einem schwerwiegenden Vorkommnis führen kann, ist ein Post-Market-Thema mit den Meldefristen aus Artikel 87.

MDCG 2019-16 rev.1 ist die Leitlinie, mit der benannte Stellen und Behörden arbeiten. Erwartet werden ein Security-Risikomanagement, das mit dem Sicherheitsrisikomanagement nach ISO 14971 verknüpft ist, definierte Security Capabilities, eine dokumentierte Betriebsumgebung, Verifikation einschließlich Penetrationstests und eine Gebrauchsanweisung, die dem Betreiber sagt, was das Gerät vom Netz braucht. IEC 81001-5-1 beschreibt den passenden sicheren Produktlebenszyklus, IEC 62304 den Softwarelebenszyklus.

Cyber Resilience Act (EU) 2024/2847. Artikel 2 Absatz 2 nimmt MDR- und IVDR-Produkte aus. Alles, was du verkaufst und kein Produkt oder Zubehör ist, etwa ein Gateway für allgemeine Zwecke oder Software ohne medizinische Zweckbestimmung, fällt unter den CRA mit Meldepflichten ab 11. September 2026 und voller Anwendung ab 11. Dezember 2027.

NIS2 über das deutsche BSIG. Die Herstellung von Medizinprodukten ist ein Sektor in Anhang II der NIS2-Richtlinie. Ein Hersteller mit 50 oder mehr Beschäftigten oder mehr als 10 Millionen Euro Umsatz und Bilanzsumme ist eine wichtige Einrichtung nach § 28 BSIG, mit den Risikomanagementmaßnahmen aus § 30 und den Meldepflichten aus § 32. Deine Klinikkunden sind besonders wichtige Einrichtungen und reichen Lieferkettenanforderungen an dich weiter.

US-Markt. Section 524B des FD&C Act verlangt für jedes bei der FDA eingereichte “cyber device” einen Cybersecurity-Plan, eine Software Bill of Materials und einen Prozess für Schwachstellen nach Markteinführung.

Wo Angreifer anfangen

Ein vernetztes Medizinprodukt hat die Angriffsfläche eines IoT-Produkts plus die Sensibilität einer Patientenakte.

• Debug- und Service-Ports: UART, JTAG oder SWD auf Seriengeräten aktiv, oft mit einer Root-Shell hinter einem bekannten Servicepasswort.
• Firmware und Update-Pfad: unverschlüsselter Flash, Update-Images, die auf Versionsnummer, aber nicht auf Signatur geprüft werden, Recovery-Modi, die jedes Image annehmen.
• Funkschnittstellen: BLE-Pairing ohne Authentifizierung bei Wearables und Heimgeräten, WLAN-Provisionierung über einen offenen Access Point, proprietäre Funkstrecken ohne Verschlüsselung.
• Companion-Apps und Cloud-APIs: Das Gerät ist klein, das Backend hält die Daten aller Patienten. Objektbezogene Autorisierung und Token-Handling sind die Stellen, an denen es schiefgeht.
• Schnittstellen ins Kliniknetz: DICOM, HL7 und Hersteller-Serviceprotokolle, entworfen für vertrauenswürdige Netze, plus Fernwartung durch dein eigenes Support-Team.
• Alte Betriebssysteme in Bildgebungs- und Laborgeräten mit zehn Jahren Nutzungsdauer.

Was Assessments typischerweise finden

Typische Findings aus Penetrationstests vernetzter Medizin- und Haushaltsgeräte, anonymisiert: eine UART-Konsole, die ohne Passwort in eine Root-Shell fiel; nie programmierte eFuses für den Flash-Ausleseschutz, sodass Firmware und WLAN-Zugangsdaten mit einem 20-Euro-Adapter lesbar waren; ein Update-Mechanismus, der eine Prüfsumme, aber keine Signatur prüfte; eine App-API, die beim Ändern der Datensatz-ID die Messhistorie eines anderen Nutzers lieferte; eine BLE-Steuercharakteristik, die nach “Just Works”-Pairing von jedem Telefon in der Nähe beschreibbar war; und ein Linux-Gerät ohne Mandatory Access Control, bei dem ein kompromittierter Dienst das ganze System übernahm.

Die Fixes sind bekannt: Debug-Zugang deaktivieren oder authentifizieren, eFuses programmieren, Updates signieren, Autorisierung pro Objekt in der API erzwingen, authentifiziertes BLE-Pairing, SELinux- und nftables-Policies. Jeder davon schließt zugleich eine Lücke gegen Anhang I Abschnitt 17.2 und eine Security Capability aus MDCG 2019-16.

Ein sinnvolles erstes Projekt

Nimm ein Gerät, idealerweise das, das als Nächstes zur benannten Stelle geht oder eine wesentliche Änderung bekommt.

1. Scoping und Security-Risikoanalyse: Schnittstellen, Datenflüsse, Betriebsumgebung, Zweckbestimmung und vorhersehbarer Fehlgebrauch, verknüpft mit deiner ISO-14971-Akte. Zwei bis drei Tage mit Entwicklung und Regulatory Affairs.
2. Penetrationstest des Geräts in unserem Labor: Hardware und Debug-Ports, Firmware-Extraktion und -Analyse, Funkschnittstellen, Update-Pfad, App und Cloud-API gegen einen Test-Tenant. Zwei bis drei Wochen.
3. Mapping der Ergebnisse auf Anhang I Abschnitte 17.2 und 17.4, die Security Capabilities aus MDCG 2019-16 und die Aktivitäten der IEC 81001-5-1, geliefert als priorisierte Fix-Liste und als Text für die technische Dokumentation.
4. Fixen und Retest, dann die Architekturentscheidungen ins nächste Produkt übernehmen.

Typischer Aufwand für die Schritte 1 bis 3 sind 15 bis 25 Personentage, also 18.000 bis 40.000 Euro zu Marktpreisen. Verglichen mit einer Runde bei der benannten Stelle, die an Cybersecurity scheitert, ist das der günstigere Weg.

Was Zyberum hier tut und was nicht

Wir testen Geräte, Companion-Apps und Backends, schreiben die Security-Risikoanalyse und die Testnachweise für deine technische Dokumentation, helfen deinen Ingenieuren beim Härten von Debug-Ports, Boot-Kette und Linux-Plattform und bauen den Prozess zur Schwachstellenbehandlung auf, den Post-Market-Überwachung und NIS2 beide brauchen. Wir schulen Embedded-Entwickler in Secure Coding. Wir sind keine benannte Stelle, vergeben keine CE-Kennzeichnung und machen weder deine klinische Bewertung noch die regulatorische Einreichung; wir arbeiten neben deinem Regulatory-Team, damit der Cybersecurity-Teil hält.