Medizinprodukte-Cybersecurity: MDR/IVDR und IEC 81001-5-1

Problem in der Praxis

Viele Hersteller behandeln Cybersecurity und Konformität als getrennte Welten: Das Team baut Funktionen, das Qualitätsmanagement führt durch das Verfahren, Security kommt spät als Prüfpunkt vor dem Audit. Die Folge sind zwei Muster. Erstens entsteht die Cybersecurity-Dokumentation reaktiv kurz vor dem Audit statt aus der Entwicklung heraus und passt dann oft nicht zur realen Architektur. Zweitens endet die Betrachtung mit dem Inverkehrbringen, obwohl Aufsicht und Betreiber gerade beim Schwachstellenmanagement und bei Sicherheitsupdates nachfragen.

Hinzu kommt Zuständigkeitsverwirrung. Für Medizinprodukte sind die Benannten Stellen und die zuständigen Bundesoberbehörden maßgeblich, in Deutschland insbesondere das BfArM. Die Bundesnetzagentur ist für den Gesundheitssektor nicht zuständig.

CISO-Einordnung

Der CISO sollte das Thema entlang von vier Fragen einordnen statt entlang einzelner Paragraphen:

• Grundpflicht: Die MDR verankert in Anhang I, Abschnitt 17 (Software), insbesondere unter 17.2, die Entwicklung nach dem Stand der Technik unter Berücksichtigung der IT-Sicherheit; eng damit verbunden sind die Mindestanforderungen an die IT-Sicherheit (Abschnitt 17.4, genaue Abschnittsbezeichnung gegen den Konsolidierungsstand der Verordnung zu prüfen). Die IVDR enthält eine entsprechende Logik für In-vitro-Diagnostika.
• Konkretisierung: Die MDCG 2019-16 (Guidance on Cybersecurity for medical devices) beschreibt frei zugänglich Security-by-Design/-by-Default und Cybersecurity-Risikomanagement über den Lebenszyklus.
• Engineering-Nachweis: Die IEC 81001-5-1 wird von Benannten Stellen faktisch als Stand der Technik herangezogen und greift in den Software-Lebenszyklusprozess nach IEC 62304 ein.
• Prüfung: durch die Benannte Stelle im Konformitätsverfahren; die Marktüberwachung übt die zuständige Bundesoberbehörde aus.

Die Rollen müssen klar getrennt sein: Der Hersteller verantwortet die Produkt-Cybersecurity nach MDR/IVDR und liefert ein sicher entwickeltes Produkt samt Begleitinformationen. Der Betreiber, etwa ein Krankenhaus, verantwortet den sicheren Betrieb; dafür ist seit dem 26. März 2024 § 391 SGB V der Anker, der den früheren § 75c SGB V abgelöst hat. Beide Pflichtenkreise greifen ineinander, sind aber nicht deckungsgleich.

Umsetzungsperspektive

Tragfähig ist eine Umsetzung, die Cybersecurity in den regulatorischen Lebenszyklus einbettet, statt einen Parallelprozess zu bauen:

• Cybersecurity-Risikomanagement an das Produktrisikomanagement koppeln, sodass Sicherheitsrisiken und ihre Wirkung auf die Patientensicherheit gemeinsam bewertet werden.
• Ein Bedrohungsmodell führen, das mit Architektur und Schnittstellen mitwächst, und Security in alle Phasen des Software-Lebenszyklus einhängen.
• Begleitinformationen so gestalten, dass Betreiber ihre Sicherungspflicht erfüllen können: unterstützte Konfigurationen, Netzwerkannahmen, Update-Mechanismen, Restrisiken.
• Den Post-Market-Teil ernst nehmen: Schwachstellenbeobachtung, koordinierte Offenlegung, Sicherheitsupdates, Rückkopplung in die Risikobewertung.

Die Standards liefern den Prozessrahmen, sind aber Referenz und keine Kopiervorlage. Die Anforderungslisten der IEC 81001-5-1 und der IEC 62304 gehören in das beschaffte Originaldokument, nicht in interne Wiki-Volltexte.

Typische Fehler

1. Cybersecurity wird erst kurz vor dem Audit dokumentiert statt aus dem Entwicklungsprozess erzeugt.
2. Die Betrachtung endet beim Inverkehrbringen; Post-Market-Schwachstellenmanagement und Update-Fähigkeit fehlen.
3. Hersteller- und Betreiberrolle werden vermischt, sodass niemand klar für die sichere Konfiguration verantwortlich ist.
4. Zuständigkeiten werden falsch zugeordnet, etwa Verweise auf die Bundesnetzagentur.
5. Standards werden als Checkliste abgehakt, ohne das Cybersecurity-Risiko an das Produktrisiko zu koppeln.

Risiken und Trade-offs

Ein rein dokumentengetriebenes Vorgehen besteht zwar das Audit, erzeugt aber keine belastbare Produktsicherheit und gerät in der Marktphase unter Druck, sobald reale Schwachstellen gemeldet werden. Ein von der Entwicklung losgelöstes, zu schweres Security-Regime verlangsamt dagegen Releases und verliert die Akzeptanz der Teams.

Ein wesentlicher Trade-off besteht zwischen Updatefähigkeit und Stabilität: Medizinprodukte unterliegen strengen Änderungs- und Validierungsanforderungen, sodass häufige Sicherheitsupdates mit validierten Zuständen kollidieren. Update-Pfade müssen daher vorab so konzipiert sein, dass Sicherheitsupdates die Konformität nicht jedes Mal neu in Frage stellen.

Schließlich ist das Verhältnis zur horizontalen Produktregulierung zu klären. Der Cyber Resilience Act (CRA) adressiert die Cybersecurity von Produkten mit digitalen Elementen sektorübergreifend, während MDR/IVDR für Medizinprodukte als sektorspezifisches Regime gelten; der Gesetzgeber will Doppelregulierung vermeiden. Wie sich der CRA gegenüber MDR/IVDR abgrenzt, ist anhand des geltenden Rechtstextes zu prüfen und nicht aus dem Gedächtnis zu behaupten. Leitlinie: entlang MDR/IVDR, MDCG 2019-16 und der Engineering-Standards planen, die CRA-Berührung gesondert prüfen.

Entscheidungspunkte

• Welcher Standard dient als Nachweisgrundlage gegenüber der Benannten Stelle, und passt er zur eigenen Entwicklungslandschaft?
• Wie wird das Cybersecurity-Risikomanagement an das Produktrisikomanagement angebunden?
• Welche Update- und Patch-Strategie ist mit den Änderungs- und Validierungspflichten vereinbar?
• Wie ist die koordinierte Schwachstellenoffenlegung geregelt, und wer ist Ansprechpartner für Sicherheitsmeldungen?
• Wer prüft die CRA-Abgrenzung für das konkrete Produkt, und mit welcher Quelle?

Praktische Empfehlungen

1. Verankern Sie Cybersecurity als festen Bestandteil des Konformitäts- und Lebenszyklusprozesses, nicht als Audit-Vorbereitung.
2. Nutzen Sie die MDCG 2019-16 als gemeinsame Sprache zwischen Regulatory, Qualität und Security; sie ist frei verfügbar.
3. Behandeln Sie IEC 81001-5-1 und IEC 62304 als beschaffte Originalstandards und reproduzieren Sie keine Anforderungslisten intern.
4. Bauen Sie den Post-Market-Teil bewusst auf: Beobachtung, koordinierte Offenlegung, Update-Bereitstellung, Rückkopplung ins Risiko.
5. Definieren Sie die Schnittstelle zum Betreiber explizit und halten Sie die Zuständigkeiten sauber: Benannte Stelle und Bundesoberbehörde, nicht die Bundesnetzagentur.

Relevante Normreferenzen

• Verordnung (EU) 2017/745 (MDR): grundlegende Sicherheits- und Leistungsanforderungen, Software in Anhang I Abschnitt 17, insbesondere 17.2 (frei über EUR-Lex).
• Verordnung (EU) 2017/746 (IVDR): entsprechende Anforderungen für In-vitro-Diagnostika (frei über EUR-Lex).
• MDCG 2019-16, Guidance on Cybersecurity for medical devices (frei, Medical Device Coordination Group).
• IEC 81001-5-1: Cybersecurity im Lebenszyklus von Gesundheitssoftware, von Benannten Stellen als Stand der Technik herangezogen (lizenziert, nur Referenz).
• IEC 62304: Software-Lebenszyklusprozesse für Medizinprodukte-Software (lizenziert, nur Referenz).
• § 391 SGB V: IT-Sicherheit in Krankenhäusern als Betreiber-Anker, in Kraft seit 26.03.2024 (frei).
• Cyber Resilience Act (EU): horizontale Produkt-Cybersecurity-Regulierung; Abgrenzung zu MDR/IVDR im Einzelfall zu prüfen.