Cybersecurity für Medizinprodukte: MDR, CRA und NIS2

Vernetzte Medizinprodukte, Cloud-Plattformen und Software als Medizinprodukt haben Cybersecurity von einem IT-Thema zu einer regulatorischen Kernanforderung gemacht. Gleichzeitig ist die Lage unübersichtlich geworden: MDR, Cyber Resilience Act (CRA), NIS2, dazu Normen wie IEC 81001-5-1. Dieser Beitrag ordnet ein, welche Regel für das Produkt, welche für das Unternehmen und welche für begleitende Software gilt, und richtet sich an Hersteller ebenso wie an IT-Teams und Softwaredienstleister, die für die Medizintechnik arbeiten.

Drei Ebenen, drei Regelwerke

Die wichtigste Unterscheidung vorweg:

Ebene	Regelwerk	Worum es geht
Medizinprodukt	MDR (EU) 2017/745	Sicherheit des Produkts über den gesamten Lebenszyklus, einschließlich IT-Sicherheit
Unternehmen	NIS2-Richtlinie (EU) 2022/2555, in Deutschland das NIS2-Umsetzungsgesetz	Informationssicherheit der Organisation, Risikomanagement, Meldepflichten
Andere digitale Produkte	Cyber Resilience Act (EU) 2024/2847	Cybersecurity von Produkten mit digitalen Elementen, die keine Medizinprodukte sind

Ein Hersteller kann also gleichzeitig unter alle drei fallen: mit seinem Medizinprodukt unter die MDR, als Unternehmen unter NIS2 und mit einer begleitenden App, die kein Medizinprodukt ist, unter den CRA.

Die MDR: Cybersecurity ist Teil der Produktsicherheit

Die MDR nennt das Wort „Cybersecurity" kaum, regelt das Thema aber in den grundlegenden Sicherheits- und Leistungsanforderungen in Anhang I. Die wichtigsten Stellen:

• Abschnitt 17.2: Software ist nach dem Stand der Technik zu entwickeln, unter Berücksichtigung von Lebenszyklus, Risikomanagement, Verifizierung, Validierung und Informationssicherheit.
• Abschnitt 17.4: Hersteller legen Mindestanforderungen an Hardware, IT-Netzwerke und IT-Sicherheitsmaßnahmen fest, einschließlich des Schutzes vor unbefugtem Zugriff.
• Abschnitt 18.8: Produkte sind so auszulegen, dass sie so weit wie möglich vor unbefugtem Zugriff geschützt sind, der ihren bestimmungsgemäßen Betrieb beeinträchtigen könnte.
• Abschnitt 14.2 und 14.5: Wechselwirkungen mit der IT-Umgebung und Interoperabilität mit anderen Systemen.
• Abschnitt 23.4: Die Gebrauchsanweisung muss die IT-Mindestanforderungen und Sicherheitsmaßnahmen benennen.

Weil Cybersecurity damit Teil der Produktsicherheit ist, prüft die Benannte Stelle sie im Rahmen der Konformitätsbewertung mit, ab Klasse IIa also immer.

MDCG 2019-16 und IEC 81001-5-1

Wie die Anforderungen umzusetzen sind, beschreibt die Leitlinie MDCG 2019-16 Rev. 1. Sie ist kein Gesetz, gilt aber für Benannte Stellen als zentraler Bezugspunkt. Kernerwartungen sind ein Security-Risikomanagement, das mit dem Sicherheitsrisikomanagement nach ISO 14971 verzahnt ist, Security by Design, Tests, Informationen für Betreiber und eine Überwachung nach dem Inverkehrbringen.

Für den Entwicklungsprozess hat sich die IEC 81001-5-1 als Stand der Technik etabliert. Sie ergänzt den Software-Lebenszyklus nach IEC 62304 um Security-Aktivitäten in jeder Phase: Bedrohungsmodellierung, sichere Implementierung, Security-Tests, Umgang mit Schwachstellen und Updates nach der Markteinführung. Für IT-Teams ist das gut anschlussfähig, denn die Norm orientiert sich an der IEC 62443-4-1 aus der Industrie-IT.

In der Praxis erwarten Benannte Stellen heute unter anderem:

• ein Bedrohungsmodell und eine Security-Risikoanalyse,
• eine Software Bill of Materials (SBOM), also eine Liste aller enthaltenen Softwarekomponenten inklusive Drittanbieter- und Open-Source-Bibliotheken,
• einen Prozess für Schwachstellenmanagement und Sicherheitsupdates über die Lebensdauer des Produkts,
• Nachweise aus Security-Tests, etwa Penetrationstests.

Der Cyber Resilience Act: nicht für Medizinprodukte, aber für ihr Umfeld

Der Cyber Resilience Act verpflichtet Hersteller von Produkten mit digitalen Elementen zu Security by Design, Schwachstellenmanagement und Meldungen. Produkte, die unter die MDR oder IVDR fallen, sind ausdrücklich ausgenommen (Artikel 2 Absatz 2). Für sie bleibt die MDR die speziellere Regelung.

Relevant bleibt der CRA trotzdem, und zwar für alles rund um das Medizinprodukt, das selbst keines ist:

• begleitende Apps ohne medizinische Zweckbestimmung,
• Gateways, Router oder Hardware-Komponenten, die separat in Verkehr gebracht werden,
• Software-Komponenten und Bibliotheken, die Zulieferer eigenständig vertreiben.

Die Fristen: Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gelten seit dem 11. September 2026, die übrigen Pflichten ab dem 11. Dezember 2027. Für IT-Dienstleister und Komponentenhersteller, die die Medizintechnik beliefern, ist der CRA damit oft direkter relevant als für die Hersteller selbst.

NIS2: Pflichten für das Unternehmen

Während MDR und CRA Produkte regulieren, richtet sich die NIS2-Richtlinie an Organisationen. Die Herstellung von Medizinprodukten und In-vitro-Diagnostika ist in Anhang II im Sektor „Verarbeitendes Gewerbe" aufgeführt. Betroffene Hersteller gelten damit als wichtige Einrichtungen, sofern sie mindestens mittelgroß sind, also in der Regel ab 50 Beschäftigten oder mehr als 10 Millionen Euro Jahresumsatz und Jahresbilanzsumme.

In Deutschland ist das NIS2-Umsetzungsgesetz am 6. Dezember 2025 in Kraft getreten. Daraus folgen insbesondere:

• Registrierung beim BSI. Die gesetzliche Frist ist abgelaufen. Wer betroffen und noch nicht registriert ist, sollte das laut BSI umgehend nachholen.
• Risikomanagementmaßnahmen, etwa zu Zugriffskontrolle, Backup, Krisenmanagement, Lieferkettensicherheit und Schulungen.
• Meldepflichten für erhebliche Sicherheitsvorfälle an das BSI, mit gestuften Fristen.
• Verantwortung der Geschäftsleitung, die die Maßnahmen billigen, überwachen und sich schulen lassen muss.

Wichtig für IT-Verantwortliche: NIS2 betrifft die gesamte Unternehmens-IT, von der Produktion über ERP und QMS-Software bis zur E-Mail. Ein bestehendes ISMS nach ISO 27001 ist eine gute Grundlage, deckt aber nicht automatisch alle Pflichten ab.

Was sich abzeichnet

Die Europäische Kommission hat im Dezember 2025 einen Vorschlag zur Überarbeitung von MDR und IVDR vorgelegt (COM(2025) 1023). Er sieht unter anderem detailliertere Cybersecurity-Anforderungen und eine Meldepflicht für aktiv ausgenutzte Schwachstellen über EUDAMED vor, angelehnt an die Logik des CRA. Der Vorschlag wird derzeit in Parlament und Rat beraten und ist noch kein geltendes Recht. Wer heute nach IEC 81001-5-1 arbeitet und ein funktionierendes Schwachstellenmanagement hat, ist für diese Entwicklung gut aufgestellt.

Für den US-Markt gilt zusätzlich Abschnitt 524B des Federal Food, Drug, and Cosmetic Act, nach dem die FDA für „cyber devices" unter anderem eine SBOM und einen Plan zur Überwachung von Schwachstellen verlangt.

Praxis-Checkliste

Für Hersteller:

1. Produkte inventarisieren: Welche haben Software, Schnittstellen oder Netzwerkzugang?
2. Security-Risikomanagement mit ISO 14971 verzahnen und in die technische Dokumentation aufnehmen.
3. Entwicklungsprozess an IEC 81001-5-1 ausrichten, SBOM erstellen und pflegen.
4. Schwachstellen- und Update-Prozess für die gesamte Produktlebensdauer definieren.
5. NIS2-Betroffenheit prüfen und gegebenenfalls BSI-Registrierung nachholen.
6. Begleitende Produkte ohne Medizinproduktestatus auf CRA-Pflichten prüfen.

Für IT-Dienstleister und Softwarezulieferer:

1. Klären, ob die eigene Software Teil eines Medizinprodukts ist oder eigenständig in Verkehr gebracht wird (MDR oder CRA?).
2. Sichere Entwicklungspraktiken dokumentieren und SBOMs liefern können.
3. Vertraglich festlegen, wie Schwachstellen gemeldet und Updates bereitgestellt werden.
4. Mit Audits rechnen: Hersteller müssen kritische Lieferanten bewerten und überwachen.

Fazit

Cybersecurity in der Medizintechnik ist keine einzelne Vorschrift, sondern ein Zusammenspiel aus Produktsicherheit (MDR), Unternehmenssicherheit (NIS2) und Produktsicherheit für das digitale Umfeld (CRA). Wer die Ebenen sauber trennt, kann Zuständigkeiten klar verteilen und vermeidet doppelte Arbeit. Den Rahmen dafür bildet ein Qualitätsmanagementsystem, das Security als festen Bestandteil von Entwicklung, Lieferantensteuerung und Marktbeobachtung behandelt (siehe auch ISO 13485 Zertifizierung).

Wir unterstützen an der Schnittstelle von QA, Regulatory Affairs und IT, damit Security-Anforderungen nicht nebeneinander, sondern im System umgesetzt werden. Mehr dazu im MedTech Consulting.