Welche Auswirkungen hat das neue EU-Gesetz auf Medizinprodukte, begleitende Apps und Cloud-Dienste? 

Einleitung 

Die Digitalisierung im Gesundheitswesen wächst rasant. Immer mehr Prozesse, Geräte und Anwendungen werden vernetzt oder in die Cloud verlegt. Gleichzeitig steigen die Anforderungen an Datenschutz und Cybersicherheit. Nicht nur Patientendaten sind besonders schützenswert – Angriffe auf medizinische Systeme können auch lebensbedrohliche Situationen hervorrufen. 

Bislang unterlagen Medizinprodukte in der EU vor allem der Medical Device Regulation (MDR) und (sofern relevant) weiteren Normen, etwa der IEC 81001-5-1, die gezielt Cybersicherheitsanforderungen für medizinische Software regelt. Mit dem neuen Cyber Resilience Act (CRA) schafft die EU nun eine weitere, weitreichende Regulierungsebene. Interessant dabei: Medizinprodukte selbst sind zwar vom CRA ausgenommen, weil sie bereits durch MDR und IVDR reguliert sind, jedoch greift der CRA bei digitalen Komponenten, Diensten und Anwendungen, die kein Medizinprodukt im Sinne der MDR/IVDR darstellen – und das betrifft zunehmend auch das Gesundheitswesen. 

In diesem Blogbeitrag werfen wir einen Blick darauf, was der Cyber Resilience Act regelt, weshalb er trotz Ausschluss von Medizinprodukten erhebliche Auswirkungen auf Hersteller im Gesundheitsmarkt hat und wie sich das Zusammenspiel mit weiteren Richtlinien wie NIS2 oder US-Vorgaben gestaltet. Zusätzlich geben wir eine kompakte Checkliste an die Hand, die zeigt, worauf Unternehmen jetzt achten sollten. 

Was ist der Cyber Resilience Act? 

Der Cyber Resilience Act (CRA) ist ein geplantes EU-Gesetz, das die Cybersicherheit von Produkten mit digitalen Elementen drastisch erhöhen soll. Dazu zählen: 

  • Software (z. B. Apps, Betriebssysteme, Kommunikationsanwendungen) 
  • IoT-Geräte (z. B. smarte Wearables, vernetzte Haushaltsgeräte) 
  • Industriesteuerungen, die direkte oder indirekte Internetverbindungen haben 

Ziel des CRA ist es, einheitliche Mindeststandards für die IT-Sicherheit während des gesamten Produktlebenszyklus festzulegen: von der Entwicklung („Security by Design“) über Markteinführung und Betrieb bis zum Patch- und Update-Management. Konkret bedeutet das für Hersteller: 

Verpflichtung zu Sicherheitsmaßnahmen

Produkte mit digitalen Elementen müssen bestimmten Basisstandards entsprechen, etwa sichere Kommunikation, verschlüsselte Datenübertragung und Mechanismen zur Abwehr typischer Bedrohungen (z. B. SQL-Injections, DDoS-Angriffe).

Transparenz über Sicherheitslücken

Es müssen Prozesse etabliert werden, um erkannte Schwachstellen zeitnah zu beheben. Sicherheitslücken sind offen zu legen, u. a. gegenüber Behörden und Nutzern.

Einheitliche CE-Kennzeichnung für vernetzte Produkte

Die Einhaltung der CRA-Vorgaben wird in die CE-Kennzeichnung eingebunden. Wer seine Produkte ohne Erfüllung der CRA-Anforderungen in der EU auf den Markt bringt, riskiert empfindliche Strafen. 

Lebenszyklus-Ansatz

Die Herstellerverantwortung endet nicht mit dem Verkauf, sondern umfasst einen definierten Zeitraum, in dem Sicherheitsupdates bereitgestellt werden müssen. Die Übergangsphase nach Inkrafttreten des CRA wird voraussichtlich mehrere Jahre betragen. Man rechnet aktuell mit einem Inkrafttreten im Jahr 2024 und einer ca. 36-monatigen Frist, was eine volle Compliance ab etwa 2027 bedeuten könnte.

Der CRA reagiert damit auf die hohe Anzahl von Cyberangriffen, die mit dem verstärkten Einsatz digitaler Technologien und vernetzter Geräte einhergehen. Für Hersteller in sämtlichen Branchen – insbesondere aber im Gesundheitswesen – schafft das Gesetz einen verbindlichen Rahmen für mehr Cybersicherheit. 

BAYOOMED-Cyber_Resilience_Act

Bedeutung für das Gesundheitswesen 

Obwohl Medizinprodukte (z. B. zertifizierte OP-Roboter, Implantate, Insulinpumpen) per se vom Geltungsbereich des CRA ausgenommen sind, weil diese bereits umfassend über MDR, IVDR und Normen wie IEC 81001-5-1 reguliert werden, entfaltet das neue Gesetz dennoch eine erhebliche Sogwirkung ins Gesundheitswesen hinein. Warum? 

Begleit-Apps und Cloud-Dienste

Viele Medizinprodukte nutzen zusätzliche Apps oder Cloud-Komponenten, die selbst kein Medizinprodukt darstellen. Genau diese Teile fallen unter den CRA, weil sie „Produkte mit digitalen Elementen“ sind und im Sinne des Gesetzes nicht bereits durch die MDR abgedeckt werden. 

  • Beispiel: Insulinpumpen sind als Medizinprodukt klassifiziert und müssen MDR/IVDR erfüllen. Die zugehörige App zur Dosierungssteuerung oder Auswertung von Messwerten ist jedoch möglicherweise kein Medizinprodukt. Sie unterliegt somit dem CRA. 

Geräte, die im Krankenhausumfeld eingesetzt werden

Vernetzte Geräte (z. B. Telemedizin-Plattformen, Patienten-Apps) können von der CRA-Pflicht erfasst werden, wenn sie für den Betrieb zwar essenziell sind, jedoch rechtlich nicht dem Medizinprodukte-Status entsprechen.

Verknüpfung mit NIS2

Die überarbeitete NIS2-Richtlinie zwingt Betreiber kritischer Infrastrukturen (darunter Gesundheitssektor, Krankenhäuser) zu höheren Sicherheitsstandards. Wer Geräte oder Software (unter CRA) an solche Institutionen liefert, muss die geforderten Standards und Dokumentationen bereitstellen. Nur so können Kliniken ihre eigene NIS2-Compliance sicherstellen.

Datensicherheit und Patientenwohl

Angesichts der sensiblen Gesundheitsdaten und des hohen Risikos von Cyberangriffen ist es für Hersteller und Betreiber ohnehin unerlässlich, eng zusammenzuarbeiten und sich über Cybersicherheitsmaßnahmen auszutauschen – unabhängig davon, ob die jeweilige Anwendung „nur“ unter den CRA oder „auch“ unter die MDR fällt. 

Medizinprodukte (im Sinne der MDR/IVDR) haben bereits heute strenge Vorgaben zur Cybersicherheit. Die IEC 81001-5-1 konkretisiert diese Anforderungen für Software, indem sie einen standardisierten Rahmen für Risikomanagement und technische Schutzmaßnahmen vorgibt. Hersteller müssen damit beweisen, dass ihre Medizinprodukte sicher sind und z. B. vor Manipulation oder Datenlecks geschützt werden können. 

CRA: „Erweiterung“ des regulatorischen Spektrums 

Der Cyber Resilience Act kommt dann ins Spiel, wenn digitale Funktionen oder Systeme nicht in den MDR-Geltungsbereich fallen. Stattdessen gelten hier nun die einheitlichen Anforderungen des CRA. In einzelnen Aspekten kann der CRA sogar über die MDR-Vorgaben hinausgehen, etwa wenn es um Meldepflichten von Sicherheitslücken gegenüber Behörden oder regelmäßiges Patch-Management geht. 

Praktisches Beispiel:

Begleit-App zur Datenauswertung auf dem Smartphone:

Unterliegt dem CRA, da sie selbst kein Medizinprodukt ist. 

Cloud-Backend für medizinische Software

Eher CRA-relevant, sofern kein Medizinproduktstatus vorliegt. 

 

NIS2 für Betreiber und Hersteller 

Die 2023 aktualisierte NIS2-Richtlinie stärkt die Cybersicherheit in kritischen Infrastrukturen (u. a. Gesundheitssektor). Krankenhäuser und andere „Betreiber wesentlicher Dienste“ müssen nun erhöhte Anforderungen an Risikoanalyse, Vorfallmanagement und Meldepflichten erfüllen. Damit das reibungslos funktioniert, sind Hersteller angehalten, ihre Produkte (ob Medizinprodukt oder nicht) entsprechend sicher zu gestalten und ihren Kunden ausreichende technische Informationen bereitzustellen. 

Blick in die USA: FDA und Co. 

In den USA ist die FDA (Food and Drug Administration) führend bei der Regulierung von Cyber Security im Medizinproduktebereich. Allerdings existiert dort kein direktes Pendant zum Cyber Resilience Act. Der „U.S. Cyber Trust Mark Act“ setzt eher auf freiwillige Maßnahmen und ist stärker auf den Verbrauchermarkt fokussiert. Internationale Hersteller müssen daher EU-Vorgaben (CRA, MDR, IVDR) und US-Standards (FDA Guidances) gleichermaßen im Blick haben, sofern sie in beiden Märkten agieren. 

BAYOOMED-Richtlinien

Konsequenzen für Hersteller von Gesundheitssoftware 

Getrennte Betrachtung von Medizinprodukt-Software und sonstigen Komponenten

Es ist entscheidend, frühzeitig zu klären, welche Teile des Produktes (z. B. Firmware, App, Cloudkomponenten) unter die MDR fallen und welche den CRA-Anforderungen genügen müssen.

Dokumentations- und Meldepflicht

Der CRA verlangt – ähnlich wie MDR/IVDR – eine gewissenhafte Dokumentation aller Sicherheitsmaßnahmen. Dazu zählt u. a. ein regelmäßiges Patch-Management sowie das Melden relevanter Sicherheitslücken an Behörden und Kunden. 

Risikoanalyse und „Security by Design“

Sowohl MDR als auch CRA fordern ganzheitliche Risikobetrachtungen: Welche potenziellen Schwachstellen liegen vor? Wie lassen sich Angriffe minimieren? Hersteller müssen proaktiv Sicherheitsmaßnahmen in den Entwicklungsprozess integrieren („Security by Design“) und Produkte standardmäßig sicher konfigurieren („Security by Default“).

Checkliste:
Cyber Security für Hersteller 

Bedrohungs- und Risikoanalyse

Nutzen Sie standardisierte Methoden wie STRIDE (um unterschiedliche Risikotypen zu identifizieren) und CVSS (Common Vulnerability Scoring System), um Schwachstellen zu priorisieren. 

Security by Design

Integrieren Sie Schutzmaßnahmen bereits in der Konzeptions- und Entwicklungsphase. 

Software Bill of Materials (SBOM)

Führen Sie ein Inventar aller eingesetzten Softwarekomponenten (Open Source und proprietär). 

CVE-Analysen

Überprüfen Sie mindestens einmal pro Jahr (besser monatlich) bekannte Sicherheitslücken anhand Ihrer SBOM. 

Unabhängige Penetrationstests

Führen Sie regelmäßige Pentests durch externe Experten durch, um potenzielle Schwachstellen frühzeitig zu entdecken. 

Zusätzliche sinnvolle Aktivitäten 

DSGVO-Konformität

Achten Sie auf den Schutz personenbezogener Daten. Cybersicherheit und Datenschutz greifen hier ineinander. 

Privacy by Design

Verwenden Sie nur die Daten, die wirklich benötigt werden, und löschen Sie überflüssige Datensätze frühzeitig. 

Optimierte Sicherheitskonzepte

Reduzieren Sie Angriffsflächen durch Minimierung von Berechtigungen und Schnittstellen. 

Verbessertes Management von Schwachstellen

Richten Sie strukturierte Update- und Patch-Prozesse ein, um zeitnah auf neue Bedrohungen reagieren zu können. 

Fazit und Ausblick 

Obgleich der Cyber Resilience Act medizinische Produkte formal ausschließt, die bereits über MDR und IVDR geregelt sind, zeigt sich, dass vernetzte Software-Komponenten im Gesundheitsbereich trotzdem in den Geltungsbereich des CRA fallen können. Besonders Apps, Cloud-Dienste oder Peripheriesysteme, die ergänzend zu Medizinprodukten genutzt werden, unterliegen den strengen Anforderungen des CRA. 

Damit entsteht ein erweiterter regulatorischer Rahmen, der den steigenden Cyberbedrohungen Rechnung trägt und eine ganzheitliche Sicherheitsbetrachtung im Gesundheitssektor fördert. Unternehmen, die im Healthcare-Bereich agieren, sollten deshalb frühzeitig folgende Schritte gehen: 

  • Identifizieren, welche Teile ihrer Produkte unter den CRA und welche unter MDR/IVDR fallen. 
  • Zusammenführen der Anforderungen in ein gemeinsames Compliance- und Sicherheitskonzept. 
  • Austausch mit Kliniken und anderen Betreibern, die ihrerseits NIS2-Verpflichtungen nachkommen müssen. 

Die EU setzt mit dem CRA ein klares Signal für mehr Sicherheit in vernetzten Systemen. Angesichts einer Übergangsfrist, die voraussichtlich bis 2027 dauern könnte, bleibt zwar etwas Zeit – doch angesichts der dynamischen Bedrohungslage lohnt es sich, sofort mit der Umsetzung zu beginnen. Nur wer bereits heute „Security by Design“ denkt und lückenlose Prozesse etabliert, wird langfristig in einem durch immer mehr Richtlinien geprägten Umfeld bestehen und das Vertrauen von Patienten, Anwendern und Institutionen dauerhaft gewinnen können. 

Die Expert:innen von BAYOOMED und BAYOOCARE unterstützen Dich bei der Entwicklung Deiner Digitalen Gesundheitsanwendung – von der regulatorischen Beratung bis zur Post-Market-Surveillance (PMS). Vereinbare gerne einen Beratungstermin für ein erstes Gespräch.