{"id":3685,"date":"2026-09-15T09:19:50","date_gmt":"2026-09-15T07:19:50","guid":{"rendered":"https:\/\/security.sauer.ninja\/?p=3685"},"modified":"2026-09-15T09:24:56","modified_gmt":"2026-09-15T07:24:56","slug":"penetrationstest-nach-mdr-medizinprodukteverordnung","status":"publish","type":"post","link":"https:\/\/security.sauer.ninja\/de\/pentesting\/penetrationstest-nach-mdr-medizinprodukteverordnung\/","title":{"rendered":"Penetrationstests nach MDR: Anforderungen, Scope-Definition & Erfahrungen aus der Praxis"},"content":{"rendered":"\n

In unseren Projekten mit Herstellern von Medizinprodukten r\u00fcckt das Thema IT-Sicherheit in den letzten Jahren immer st\u00e4rker in den Fokus. Viele Hersteller stehen vor der Herausforderung, dass Benannte Stellen im Rahmen der Konformit\u00e4tsbewertung konkrete Nachweise zur Informationssicherheit einfordern.<\/p>\n\n\n\n

Der Grund daf\u00fcr liegt in der fortschreitenden Digitalisierung der Medizintechnik. Kaum ein modernes Medizinprodukt kommt noch ohne Cloud-Backends, mobile Steuerungs-Apps f\u00fcr iOS\/Android oder Bluetooth-Low-Energy-Schnittstellen (BLE) aus. Auch reine Software as a Medical Device<\/em> (SaMD) nimmt einen immer gr\u00f6\u00dferen Stellenwert ein. Mit jedem dieser Bausteine w\u00e4chst jedoch die Angriffsfl\u00e4che, was eine systematische \u00dcberpr\u00fcfung der IT-Sicherheit erforderlich macht.<\/p>\n\n\n\n

Rechtliche Grundlage<\/h2>\n\n\n\n

Die MDR verlangt dabei im Anhang I bei „Produkte, zu deren Bestandteilen programmierbare Elektroniksysteme geh\u00f6ren, und Produkte in Form einer Software“ unter Punkt 17.2 die Verifzierung und Validierung, dass das Produkt bzw die Software nach dem Stand der Technik entwickelt wurde – aus der Perspektive der IT-Sicherheit:<\/p>\n\n\n\n

\n

17.2 Bei Produkten, zu deren Bestandteilen Software geh\u00f6rt, oder bei Produkten in Form einer Software wird die Software entsprechend dem Stand der Technik entwickelt und hergestellt, wobei die Grunds\u00e4tze des Software-Lebenszyklus, des Risikomanagements einschlie\u00dflich der Informationssicherheit, der Verifizierung und der Validierung zu ber\u00fccksichtigen sind.<\/p>\nMDR, Anhang I – Verordnung (EU) 2017\/745 des Europ\u00e4ischen Parlaments und des Rates vom 5. April 2017 \u00fcber Medizinprodukte, zur \u00c4nderung der Richtlinie 2001\/83\/EG, der Verordnung (EG) Nr. 178\/2002 und der Verordnung (EG) Nr. 1223\/2009 und zur Aufhebung der Richtlinien 90\/385\/EWG und 93\/42\/EWG des Rates (Text von Bedeutung f\u00fcr den EWR. )<\/cite><\/blockquote>\n\n\n\n

Im Medical Device Coordination Group Document „MDCG 2019-16 Guidance on Cybersecurity for medical devices“ findet sich nun als Konkretisierung der vorherigen Verifzierung- und Validierungsbestimmung Penetration Testing als eine M\u00f6glichkeit:<\/p>\n\n\n\n

\n

MDR Annex I Section 17.2 and IVDR Annex I Section 16.2 require for devices that incorporate software or for software that are devices in themselves, that the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of the development life cycle, risk management, including information security, verification and validation. The primary means of security verification and validation is testing. Methods can include security feature testing, fuzz testing, vulnerability scanning and penetration testing. Additional security testing can be one by using tools for secure code analysis and tools that scan for open source code and libraries used in the product, to identify components with known issues.<\/p>\n\n\n\n

<\/p>\nMedical Device Coordination Group Document, MDCG 2019-16<\/cite><\/blockquote>\n\n\n\n

Scope-Definition und Abgleich mit der Risikoanalyse<\/h2>\n\n\n\n

Bei der Scoping-Phase beobachten wir in der Praxis h\u00e4ufig zwei unterschiedliche Probleme:<\/p>\n\n\n\n

    \n
  1. Zu stark verk\u00fcrzter Scope:<\/strong> Potenziell relevante Schnittstellen (wie Cloud-APIs oder physische Wartungsschnittstellen) werden ausgeklammert, um Zeit und Aufwand zu sparen. Das kann funktionieren, f\u00fchrt aber bei den Benannten Stellen eher zu kritischen R\u00fcckfragen und Probleme im Zulassungsprozess.<\/li>\n\n\n\n
  2. \u00dcberm\u00e4\u00dfig breiter Scope:<\/strong> Es wird versucht, jeden theoretisch denkbaren Vektor zu pr\u00fcfen. Unabh\u00e4ngig davon, wie realistisch das Bedrohungsszenario f\u00fcr das konkrete Produkt \u00fcberhaupt ist.<\/li>\n<\/ol>\n\n\n\n

    Aus unserer Erfahrung ist es entscheidend, den Scope eines MDR-Pentests eng an der herstellereigenen Risikoanalyse<\/strong> auszurichten und dabei pragmatisch vorzugehen.<\/p>\n\n\n\n

    Beispiel aus der Praxis:<\/strong> Bei einem Medizinprodukt, das ausschlie\u00dflich f\u00fcr den h\u00e4uslichen Bereich (Home-Only<\/em>) vorgesehen ist, ist die Bedrohungslage eine andere als bei einem Ger\u00e4t im Krankenhausnetzwerk. Es ist in der Regel nicht verh\u00e4ltnism\u00e4\u00dfig, tagelang zu pr\u00fcfen, ob ein Angreifer physisch vor Ort eine lokale BLE-Verbindung manipulieren k\u00f6nnte, wenn derselbe Angreifer \u00fcber unzureichend gesch\u00fctzte Backend-APIs oder App-Schnittstellen potenziell auf weitaus mehr Daten zugreifen oder gr\u00f6\u00dfere Sch\u00e4den anrichten k\u00f6nnte.<\/p>\n\n\n\n

    \n

    Der Pr\u00fcffokus sollte daher auf den Angriffsvektoren liegen, die ein realistisches Risiko f\u00fcr die Patientensicherheit oder den Datenschutz darstellen.<\/p>\n\n\n\n

    Fazit<\/h2>\n<\/blockquote>\n\n\n\n

    Ein Penetrationstest im Kontext der MDR erf\u00fcllt dann seinen Zweck, wenn der Scope auf Basis einer realistischen Risikoanalyse definiert wird. Auf diese Weise erhalten Hersteller einen fundierten Nachweis f\u00fcr die Konformit\u00e4tsbewertung und stellen sicher, dass die tats\u00e4chlichen Risiken des Produkts angemessen adressiert werden.<\/p>\n\n\n\n

    Die Kernfragen f\u00fcr einen Penetrationstest eines Medizinprodukts oder einer SaMD sind dabei meistens:<\/p>\n\n\n\n