Cybersecurity bei Medizinprodukten: Was MDR, IVDR und IEC 81001-5-1 verlangen

Cybersecurity ist bei Medizinprodukten keine freiwillige Zusatzleistung, sondern Teil der grundlegenden Sicherheits- und Leistungsanforderungen. MDR und IVDR verlangen, dass Produkte mit Software nach dem Stand der Technik entwickelt werden und gegen unbefugten Zugriff geschützt sind. Die Anforderungen gelten nicht nur zum Zeitpunkt der Konformitätsbewertung, sondern über den gesamten Lebenszyklus, von der Konzeptphase bis zum Ende des Supportzeitraums.

Für Hersteller ergeben sich daraus zwei Aufgaben. Vor dem Inverkehrbringen müssen Security-Anforderungen in Entwicklung, Risikomanagement und technische Dokumentation eingearbeitet sein. Nach dem Inverkehrbringen müssen Schwachstellen erkannt, bewertet und behoben werden, teilweise mit Meldepflichten gegenüber Behörden und Benannter Stelle.

Dieser Beitrag ordnet die rechtlichen Grundlagen der Europäischen Verordnungen über Medizinprodukte, (EU) 2017/745 (MDR), und In-vitro-Diagnostika, (EU) 2017/746 (IVDR), ein, beschreibt die maßgeblichen Normen und Leitlinien und zeigt, wie sich die Anforderungen praktisch umsetzen lassen.
 

Rechtliche Grundlage in MDR und IVDR

Die zentralen Vorgaben finden sich in Anhang I der beiden Verordnungen. Nach Anhang I Nr. 17.2 MDR und Anhang I Nr. 16.2 IVDR müssen Medizinprodukte mit Software nach dem Stand der Technik entwickelt und hergestellt werden. Ausdrücklich genannt sind dabei Software-Lebenszyklus, Risikomanagement einschließlich Informationssicherheit sowie Verifizierung und Validierung.

Anhang I Nr. 17.4 MDR und Anhang I Nr. 16.4 IVDR ergänzen die Perspektive der Anwendungsumgebung. Hersteller müssen Mindestanforderungen an Hardware, Eigenschaften von IT-Netzen und IT-Sicherheitsmaßnahmen festlegen und mitteilen. Für programmierbare Produkte fordern beide Verordnungen zusätzlich, das Risiko unbefugten Zugriffs so weit wie möglich zu verringern.

Diese Anforderungen sind allgemein formuliert. Konkretisiert werden sie durch das allgemeine Risikomanagement nach Art. 10 MDR beziehungsweise Art. 10 IVDR, durch ISO 14971 sowie durch Leitlinien und Normen. Wichtig ist die Abgrenzung der Begriffe Safety (Schutz von Patienten und Anwendern vor Schäden) und Security (Schutz des Produkts vor unbefugtem Zugriff und Manipulation). Beides greift ineinander. Ein Security-Problem kann zu einem Safety-Problem werden.
 

Abgrenzung zu angrenzenden Rechtsakten

Medizinprodukte und IVD unterliegen mehreren Cybersecurity-Rechtsakten. Die folgende Übersicht ordnet die wesentlichen Gesetze zu.

Stand der Technik: MDCG 2019-16 und IEC 81001-5-1

MDCG 2019-16 ist die maßgebliche europäische Leitlinie zur Cybersecurity von Medizinprodukten und gilt für MDR- und IVDR-Produkte gleichermaßen. Sie beschreibt Security-by-Design und Security-by-Default, ein sicherheitsbezogenes Risikomanagement sowie Anforderungen an Verifizierung, Validierung und die Phase nach dem Inverkehrbringen.

IEC 81001-5-1 konkretisiert Security-Aktivitäten im Software-Lebenszyklus für Health Software. Sie ergänzt IEC 62304 um Security-Aktivitäten wie Threat Modeling, sichere Implementierung, Security-Tests und Schwachstellenmanagement. Beide Normen sind nach derzeitigem Stand nicht formal unter MDR und IVDR harmonisiert. Sie werden von Benannten Stellen dennoch als Stand der Technik herangezogen. Eine Konformitätsvermutung entsteht daraus nicht, die Anwendung erleichtert die Argumentation aber erheblich.

Ergänzend hat die IEC im Dezember 2025 das Interpretation Sheet IEC 81001-5-1:2021/ISH1:2025 veröffentlicht, das unter anderem den Umgang mit Softwarekomponenten präzisiert. Für Teilaspekte wird zusätzlich oft die Normenreihe IEC 62443 herangezogen, insbesondere IEC 62443-4-1 für sichere Entwicklungsprozesse.

Darüber hinaus können je nach Produkttyp weitere MDCG-Dokumente relevant sein, insbesondere Leitlinien zu Medical Device Software (MDSW), Klassifizierung, PMS und Vigilanz. Cybersecurity-Anforderungen sollten stets im regulatorischen Gesamtkontext betrachtet werden.
 

Cybersecurity bei Medizinprodukten: Anforderungen vor dem Inverkehrbringen

Vor der Konformitätsbewertung muss der Nachweis in der technischen Dokumentation nachvollziehbar dargestellt sein. Üblich sind folgende Bestandteile:

1. Security-Risikomanagement: eigener, mit ISO 14971 verzahnter Prozess mit Bedrohungsmodell, Angriffsvektoren und Bewertung der Auswirkungen auf Patientensicherheit und Datenintegrität.
2. Security-Anforderungen: abgeleitet aus dem Bedrohungsmodell, unter anderem Authentifizierung, Rechtevergabe, Verschlüsselung, Protokollierung, sichere Update-Mechanismen.
3. Sichere Entwicklung: Security-by-Design und Security-by-Default, sichere Standardkonfiguration, Härtung.
4. Software Bill of Materials (SBOM): Nach aktuellem Stand der Technik etabliertes Verzeichnis aller Softwarekomponenten einschließlich Fremd- und Open-Source-Anteilen als Grundlage für die spätere Schwachstellenbeobachtung.
5. Verifizierung und Validierung: Security-Tests, etwa statische Analyse, Fuzz-Tests und Penetrationstests. Die Tests sollten von Personen durchgeführt werden, die die Maßnahmen nicht selbst entworfen haben.
6. Informationen für Anwender und Betreiber: Mindestanforderungen an IT-Umgebung und Netzbetrieb, Angaben zum Supportzeitraum, Hinweise in der Gebrauchsanweisung nach Anhang I Kapitel III Nr. 23 MDR bzw. Nr. 20 IVDR.

Besonderheiten bei In-vitro-Diagnostika

Bei IVD verschiebt sich der Schwerpunkt vom unmittelbaren Patientenkontakt zur Integrität von Daten und Befunden. Analysesysteme und Software sind in der Regel an Labor-Informationssysteme (LIS), Middleware und Krankenhaus-IT angebunden. Ein manipuliertes oder fehlerhaft übertragenes Ergebnis kann zu einer falschen Diagnose oder Therapieentscheidung führen, ohne dass am Gerät selbst ein Fehler sichtbar wird. Schnittstellen, Übertragungswege und die korrekte Zuordnung von Probe und Patient gehören daher in das Bedrohungsmodell.

Besondere Aufmerksamkeit verdienen die folgenden drei Konstellationen:

• Bei Software zur Interpretation von Ergebnissen, etwa in der Genomdiagnostik, sollten Algorithmus- und Datenbankversionen sowie deren Aktualisierungen abgesichert werden.
• Bei Companion Diagnostics kann sich ein fehlerhaftes Ergebnis direkt auf die Arzneimitteltherapie auswirken.
• Bei Produkten zur Eigenanwendung und zugehörigen Apps kommen ungeschützte Endgeräte und Cloud-Anbindungen hinzu.

Für Produkte der Klassen C und D ist die Prüftiefe der Benannten Stelle höher. Bei bestimmten Produktarten der Klasse D kommt der Kontext der EU-Referenzlaboratorien hinzu. Das ändert die inhaltlichen Security-Anforderungen nicht, erhöht aber die Anforderungen an die Dokumentationsqualität.
 

Cybersecurity bei Medizinprodukten: Anforderungen nach dem Inverkehrbringen

Die Pflichten enden nicht mit der CE-Kennzeichnung. Der Post-Market-Surveillance-Prozess nach Art. 83 ff. MDR und Art. 78 ff. IVDR muss auch sicherheitsrelevante Informationen erfassen. Dazu gehört die laufende Beobachtung bekannter Schwachstellen in den eigenen und in fremden Softwarekomponenten, üblicherweise gestützt auf die SBOM und öffentliche Schwachstellendatenbanken.

Erkannte Schwachstellen müssen bewertet und, soweit erforderlich, durch Updates oder andere Maßnahmen behoben werden. Der Prozess sollte festlegen, in welchen Fristen bewertet wird, wie über Maßnahmen entschieden wird und wie Anwender informiert werden. Ein definierter Weg zur Meldung von Schwachstellen durch Dritte ist Stand der Technik (Coordinated Vulnerability Disclosure, CVD).

Führt ein Vorfall zu einem schwerwiegenden Vorkommnis, greifen die Meldepflichten nach Art. 87 MDR beziehungsweise Art. 82 IVDR. Sicherheitskorrekturmaßnahmen im Feld sind dann entsprechend zu melden. Es muss außerdem geklärt werden, ob eine Änderung als wesentliche Änderung einzustufen ist und die Benannte Stelle eingebunden werden muss. Auch das Ende des Supportzeitraums sollte geplant und kommuniziert werden, da danach Sicherheitsupdates entfallen.
 

Nachweisführung gegenüber der Benannten Stelle

Benannte Stellen prüfen Cybersecurity strukturiert. Die Interessengemeinschaft der Benannten Stellen (IG-NB) veröffentlicht dazu Fragebögen und Positionspapiere, die als Vorbereitungshilfe dienen. Erfahrungsgemäß werden insbesondere die Verzahnung von Safety und Security, das Threat Modeling, die Pflege der SBOM sowie die Durchführung und Wirksamkeit von Security-Tests hinterfragt. Weicht der Hersteller von EN IEC 81001-5-1 ab, sollte die Begründung nachvollziehbar und dokumentiert sein.
 

Praktische Vorgehensweise

• Rechtlichen Rahmen zuerst klären: Prüfen, welche Anforderungen aus MDR oder IVDR gelten und welche angrenzenden Rechtsakte auf Ihr Produkt, Ihre Komponenten und Ihr Unternehmen wirken.
• Security-Risikomanagement aufbauen und mit dem Risikomanagement nach ISO 14971 verknüpfen. Dies kann entweder als eigenständiger, gekoppelter Prozess oder als integrierter Bestandteil des Gesamtrisikomanagements erfolgen.
• SBOM früh einführen und automatisiert pflegen. Die SBOM ist Grundlage für die Schwachstellenbeobachtung nach dem Inverkehrbringen.
• Security-Tests als festen Bestandteil der Verifizierung planen und die Unabhängigkeit der Prüfenden dokumentieren.
• Prozesse für Schwachstellenmanagement, Updates und Meldewege festlegen, bevor der erste Vorfall eintritt.

FAQ

Fordern MDR und IVDR ausdrücklich Cybersecurity?
Ja. Beide Verordnungen verlangen Entwicklung nach dem Stand der Technik unter Berücksichtigung der Informationssicherheit, des Risikomanagement verbunden mit Angaben zu IT-Sicherheitsmaßnahmen.

Gilt der Cyber Resilience Act für Medizinprodukte?
Nein. Medizinprodukte und IVD, die unter MDR oder IVDR fallen, sind vom Anwendungsbereich ausgenommen. Relevant kann das Gesetz dennoch werden, wenn Komponenten zugekauft oder Produkte außerhalb von MDR und IVDR vertrieben werden.

Muss EN IEC 81001-5-1 angewendet werden?
Eine formale Pflicht besteht nicht. Die Norm ist zudem nicht harmonisiert. Sie gilt jedoch als Stand der Technik. Eine Abweichung sollte begründet und dokumentiert werden.

Gelten für IVD dieselben Anforderungen?
Ja, die Systematik ist identisch. Die Schwerpunkte liegen bei IVD stärker auf der Integrität von Messdaten und Befunden sowie auf den Schnittstellen zu Labor- und Krankenhaus-IT.

Wie lange müssen Sicherheitsupdates bereitgestellt werden?
Eine feste Frist nennen MDR und IVDR nicht. Maßgeblich ist der vom Hersteller festgelegte und kommunizierte Supportzeitraum, der sich an der erwarteten Lebensdauer des Produkts orientieren sollte.
 

Fazit

Cybersecurity ist bei Medizinprodukten und IVD ein durchgehender Prozess und kein einmaliger Nachweis. Eine frühzeitige Verankerung von Security-Risikomanagement, SBOM, Tests und Schwachstellenmanagement vermindert Nacharbeiten in der Konformitätsbewertung und dient der Vorbereitung auf Vorfälle nach dem Inverkehrbringen.

Sie möchten wissen, wo Ihr Produkt und Ihre Dokumentation in diesen Punkten stehen? In einem Erstgespräch ordnen wir Ihre Ausgangslage ein und benennen die nächsten sinnvollen Schritte.

Dieser Beitrag dient ausschließlich der allgemeinen Information und stellt keine Rechtsberatung dar. Sämtliche Inhalte wurden vor Veröffentlichung fachlich geprüft und werden regelmäßig auf Aktualität, Vollständigkeit und Richtigkeit überprüft. Trotz sorgfältiger Erstellung und Qualitätskontrolle können Fehler, Unvollständigkeiten oder zwischenzeitlich eingetretene Änderungen der Rechtslage nicht ausgeschlossen werden.