Cybersecurity für Medizinprodukte

Die MDR verwendet den Begriff „Cybersecurity“ nicht wörtlich, stellt aber in Anhang I klare Anforderungen: Abschnitt 17.1 verlangt für Produkte mit programmierbaren Elektroniksystemen Wiederholbarkeit, Zuverlässigkeit und Leistung entsprechend der Zweckbestimmung; Abschnitt 17.2 fordert Software-Entwicklung nach dem Stand der Technik unter Berücksichtigung von Lebenszyklus, Risikomanagement – einschließlich Informationssicherheit – sowie Verifizierung und Validierung. Nach Abschnitt 17.4 müssen Hersteller Mindestanforderungen an Hardware, IT-Netzwerkeigenschaften und IT-Sicherheitsmaßnahmen inklusive Schutz vor unberechtigtem Zugriff festlegen; Abschnitt 18.8 und Abschnitt 23.4 Buchstabe ab ergänzen den Schutz vor unbefugtem Zugriff und die Pflicht, diese Mindestanforderungen in der Gebrauchsanweisung zu kommunizieren. Der Cyber Resilience Act (Verordnung (EU) 2024/2847) nimmt Medizinprodukte in Art. 2 ausdrücklich aus seinem Anwendungsbereich aus, weil die MDR bereits lebenszyklusweite IT-Sicherheitsanforderungen stellt.

Die Guidance MDCG 2019-16 Rev. 1 (Juli 2020) der Medical Device Coordination Group konkretisiert, wie die Anhang-I-Anforderungen über den gesamten Lebenszyklus umzusetzen sind: Secure by Design, ein eigenes Security-Risikomanagement, das mit dem Safety-Risikomanagement verzahnt wird, sowie ein Katalog von Security Capabilities wie Authentifizierung, Autorisierung, Verschlüsselung und Audit-Logging. Sie etabliert das Prinzip der geteilten Verantwortung („joint responsibility“): Neben dem Hersteller tragen auch Integratoren, Betreiber und Anwender definierte Pflichten für den sicheren Betrieb – etwa sichere Konfiguration und Einhaltung der herstellerseitigen IT-Mindestanforderungen. Eine Mapping-Tabelle ordnet die relevanten Abschnitte in MDR- und IVDR-Anhang I einander zu, und ein Anhang mit Fallbeispielen grenzt Cybersecurity-Vorkommnisse von meldepflichtigen schwerwiegenden Vorkommnissen ab.

Die IEC 81001-5-1:2021 („Health software and health IT systems safety, effectiveness and security – Part 5-1: Security – Activities in the product life cycle“) definiert die Prozessanforderungen für sichere Entwicklung und Wartung von Health Software: Security-Risikomanagement mit Bedrohungsmodellierung, Sicherheitstests, Konfigurationsmanagement sowie Prozesse für Schwachstellen-Monitoring und Problembehebung. Sie erweitert die Lebenszyklus-Struktur der IEC 62304 um Security-Aktivitäten und ist an die IEC 62443-4-1 angelehnt. Die europäische Fassung EN IEC 81001-5-1:2022 ist zwar für die Harmonisierung unter MDR und IVDR vorgesehen, aber auch nach der Aktualisierung der Normenlisten im Juni 2026 (Durchführungsbeschluss (EU) 2026/1231) noch nicht im EU-Amtsblatt zitiert – eine Konformitätsvermutung besteht damit nicht. In der Praxis behandeln Benannte Stellen die Norm dennoch als Stand der Technik für den Nachweis der Anforderungen aus Anhang I Abschnitt 17.2 und 17.4.

Die KI-Verordnung (Verordnung (EU) 2024/1689, in Kraft seit dem 1. August 2024) ergänzt die MDR, ersetzt sie aber nicht: Nach Art. 6(1) gilt ein KI-System als Hochrisiko-KI, wenn es Sicherheitsbauteil eines Medizinprodukts oder selbst ein solches Produkt ist und dessen Konformitätsbewertung eine Benannte Stelle erfordert – unter der MDR regelmäßig ab Klasse IIa. Die gemeinsam mit dem AI Board erarbeitete FAQ MDCG 2025-6 (Juni 2025) beantwortet 36 Praxisfragen zum Zusammenspiel beider Regelwerke, etwa zur Rollenzuordnung (Hersteller nach MDR entspricht Anbieter nach KI-VO) und zur Kombination der Konformitätsbewertungen. Bei den Fristen gab es 2026 eine wesentliche Änderung: Der im Mai 2026 von Parlament und Rat vereinbarte „Digital Omnibus“ verschiebt die Anwendung der Hochrisiko-Pflichten für in regulierte Produkte eingebettete KI-Systeme vom 2. August 2027 auf den 2. August 2028; wirksam wird dies mit Veröffentlichung im EU-Amtsblatt. Ein weitergehender Vorschlag, Medizinprodukte weitgehend von der KI-VO auszunehmen, wurde dabei nicht übernommen.

Weil sich Bedrohungslage und Schwachstellen nach dem Inverkehrbringen laufend ändern, verlangt die MDR ein aktives Post-Market-Surveillance-System (Art. 83) mit PMS-Plan (Art. 84) und – je nach Klasse – PMS-Bericht oder regelmäßig aktualisiertem Sicherheitsbericht (PSUR, Art. 86); Cybersecurity ist nach MDCG 2019-16 ausdrücklich Teil dieses Systems. Führt eine ausgenutzte oder ausnutzbare Schwachstelle zu einem schwerwiegenden Vorkommnis, greifen die Vigilanz-Pflichten nach Art. 87: Meldung spätestens 15 Tage nach Kenntnis, bei Todesfall oder unerwarteter schwerwiegender Gesundheitsverschlechterung 10 Tage, bei schwerwiegender Gefahr für die öffentliche Gesundheit 2 Tage; hinzu kommt das Trend Reporting nach Art. 88. Für die Meldung stehen IMDRF-Codes für Security-Ursachen bereit, etwa „Computer System Security Problem“ und „Software Security Vulnerability“. Sicherheitsrelevante Patches sind regulatorisch Korrekturmaßnahmen und können als Sicherheitskorrekturmaßnahmen im Feld (FSCA) meldepflichtig sein – ein strukturierter Vulnerability-Handling-Prozess nach IEC 81001-5-1 verbindet beide Welten. Perspektivisch relevant: Der im Dezember 2025 vorgelegte Kommissionsvorschlag zur MDR-Revision (COM(2025) 1023) sieht ergänzend CRA-artige Meldungen aktiv ausgenutzter Schwachstellen an CSIRTs und ENISA vor – derzeit noch nicht beschlossen.

Benannte Stellen prüfen Cybersecurity als Teil der technischen Dokumentation nach MDR Anhang II und III – von der Security-Risikoanalyse über die Festlegung der Security Capabilities bis zu Nachweisen aus Sicherheitstests und den Prozessen für Schwachstellenbehandlung und PMS. Das Team-NB Position Paper „Cyber Security“ (Oktober 2022) beschreibt die gemeinsame Erwartungshaltung der europäischen Benannten Stellen an diese Nachweise; in einem Schreiben vom Februar 2026 mahnt Team-NB zudem die zügige Harmonisierung von Normen wie der IEC 81001-5-1 an. Solange harmonisierte Cybersecurity-Normen fehlen, gibt es keine Konformitätsvermutung – Hersteller müssen den Stand der Technik eigenständig begründen und sollten die Argumentation entlang von MDCG 2019-16 und IEC 81001-5-1 aufbauen.