Es ist 2026 und alle sprechen über den künftigen Cyber Resilience Act (CRA). Der Cyber Resilience Act ist neu und er ist groß. Digitale Produkte müssen strikte Cyber Security-Pflichten einhalten: Sicherheitslücken melden, Updates liefern, und das über die ganze Lebensdauer. Betroffen ist fast jede Branche.
Daher stellt sich die Frage: Gilt der CRA eigentlich auch für (Software-)Medizinprodukte nach MDR und IVDR?
In diesem Artikel geben wir klare, abschließende Antworten auf diese und weitere Fragen:
- Was regelt der Cyber Resilience Act (CRA)?
- Gilt der CRA für MDR- und IVDR-Produkte?
- Welche Cyber Security-Anforderungen müssen Medizinprodukte stattdessen erfüllen?
- Wann betrifft der CRA Sie trotzdem?
- Ausblick: Die MDR-Revision holt die CRA-Logik ins Medizinprodukterecht
- Unser Fazit
1. Was regelt der Cyber Resilience Act?
Der Cyber Resilience Act (Verordnung (EU) 2024/2847) ist am 10.12.2024 in Kraft getreten. Die ersten Pflichten greifen bereits ab 11.09.2026.
➡ Verordnungstext des Cyber Resilience Acts: Link zum Cyber Resilience Act
Der CRA ist eine horizontale Verordnung. Er stellt Anforderungen an die Cybersecurity von „Produkten mit digitalen Elementen“, also branchenübergreifend an Software und an Hardware mit Software-Anteil.
Doch nicht jedes Software-Produkt fällt unter den CRA. Nach Artikel 2 Absatz 1 gilt die Verordnung für Produkte, deren bestimmungsgemäßer Zweck oder vernünftigerweise vorhersehbare Verwendung „eine direkte oder indirekte logische oder physische Datenverbindung mit einem Gerät oder Netz einschließt“. Konnektivität ist damit das entscheidende Kriterium.
Der Nachweis läuft über die CE-Kennzeichnung. Verlangt werden grundlegende Sicherheitsanforderungen, eine Konformitätsbewertung, technische Dokumentation und die Behandlung von Schwachstellen über den Lebenszyklus.
Ob ein Produkt hochgestuft wird, hängt an zwei Kriterien: Erfüllt es selbst eine Funktion, die für die Cybersicherheit anderer Produkte, Netze oder Dienste kritisch ist, oder kann eine Störung viele andere Produkte oder die Gesundheit und Sicherheit der Nutzer erheblich beeinträchtigen?
-
Standardkategorie: alles, was nicht in Anhang III oder IV gelistet ist. Hier genügt die interne Kontrolle ohne Beteiligung einer notifizierten Stelle. Schätzungen gehen davon aus, dass rund 90 Prozent aller Produkte hier landen.
-
Wichtig, Klasse I (Anhang III): Betriebssysteme, Passwortmanager, Identitätsverwaltung, Browser, VPN, Router, Smart-Home-Produkte mit Sicherheitsfunktionen, und ausdrücklich auch am Körper tragbare Produkte zur Gesundheitsüberwachung, für die MDR und IVDR nicht gelten. Selbstbewertung bleibt möglich, aber nur wenn Sie harmonisierte Normen, gemeinsame Spezifikationen oder ein Zertifizierungsschema vollständig anwenden. Sonst kommt eine notifizierte Stelle dazu.
-
Wichtig, Klasse II (Anhang III): Hypervisoren und Container-Runtime-Systeme, Firewalls, Intrusion-Detection- und Intrusion-Prevention-Systeme, manipulationssichere Mikroprozessoren. Hier ist immer eine dritte Stelle beteiligt, denn eine reine Selbstbewertung ist nicht vorgesehen.
-
Kritisch (Anhang IV): Hardware-Geräte mit Sicherheitsboxen, Smart-Meter-Gateways und Smartcards einschließlich Secure Elements. Hier greift ein europäisches Cybersicherheits-Zertifizierungsschema, soweit die Kommission es für die Kategorie vorschreibt.
Zwei Termine sind besonders relevant
- 11.09.2026: die Meldepflichten greifen. Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle sind an die European Union Agency for Cybersecurity (ENISA) und an die nationalen Computer Security Incident Response Teams (CSIRTs) zu melden.
- 11.12.2027: volle Anwendung, also grundlegende Anforderungen, Konformitätsbewertung, CE-Kennzeichnung und technische Dokumentation
Stichdaten und Fristen des Cyber Resilience Act (CRA)
2. Gilt der CRA für MDR- und IVDR-Produkte?
Das ist eine Frage, die uns Medizinproduktehersteller regelmäßig stellen. Die Antwort ist ganz klar: nein.
Artikel 2 Absatz 2 des CRA nimmt Medizinprodukte und In-vitro-Diagnostika ausdrücklich aus dem Anwendungsbereich heraus:
„Diese Verordnung gilt nicht für Produkte mit digitalen Elementen, auf die folgende Rechtsakte der Union Anwendung finden: a) Verordnung (EU) 2017/745, b) Verordnung (EU) 2017/746, c) Verordnung (EU) 2019/2144.“
Verordnung (EU) 2017/745 ist die MDR, Verordnung (EU) 2017/746 die IVDR. Produkte, die unter eine dieser beiden Verordnungen fallen, sind vom CRA also nicht erfasst.
Wichtig für das Verständnis: Der Gesetzgeber wollte keine Sonderbehandlung für Medizinprodukte schaffen, sondern Doppelregulierung vermeiden. Das sagt Erwägungsgrund 25 des CRA selbst:
„Diese Verordnungen dienen der Bewältigung von Cybersicherheitsrisiken und folgen besonderen Ansätzen, die auch dieser Verordnung zugrunde liegen. […] Produkte mit digitalen Elementen, die unter eine dieser Verordnungen fallen, sollten daher nicht von der vorliegenden Verordnung erfasst werden.“
Begründet wird das also damit, dass an Medizinprodukte bereits vergleichbare Cyber Security-Anforderungen gestellt werden.
In der Praxis heißt das für Sie: kein zweites Konformitätsbewertungsverfahren, keine zweite CE-Kennzeichnung neben der aus MDR oder IVDR, keine Einordnung Ihres Produkts in eine CRA-Produktklasse.
Achtung: Der Ausschluss hängt am Produkt, nicht am Unternehmen. Er sagt nichts über die übrigen Produkte in Ihrem Portfolio und nichts über Pflichten, die Sie als Unternehmen treffen. Mehr dazu in Kapitel 3 und 4.
3. Welche Cyber Security-Anforderungen müssen Medizinprodukte stattdessen erfüllen?
Der Ausschluss bedeutet jedoch nicht weniger Arbeit, sondern nur eine andere Rechtsgrundlage.
Hersteller von (Software-)Medizinprodukten nach MDR und IVDR tragen bereits umfangreiche Pflichten im Bereich der Cyber Security. Diese kommen nicht aus dem Cyber Resilience Act, sondern aus der MDR (oder IVDR) und anderen Gesetzen oder Normen.
Anforderungen speziell an Medizinprodukte nach MDR & IVDR
Die wohl zentralste rechtliche Grundlage in der MDR für Informationssicherheit ist Anhang I Kapitel II Nummer 17 der MDR zu programmierbaren Elektroniksystemen. Nummer 17.1 verlangt, dass solche Produkte so ausgelegt werden, dass Wiederholbarkeit, Zuverlässigkeit und Leistung entsprechend der bestimmungsgemäßen Verwendung gewährleistet sind. Für den Fall des Erstauftretens eines Defekts sind geeignete Vorkehrungen zu treffen, um sich daraus ergebende Risiken oder Leistungsbeeinträchtigungen auszuschließen oder sie so weit wie möglich zu verringern. Die für die Cybersecurity wichtigste Nummer ist 17.2:
„Bei Produkten, zu deren Bestandteilen Software gehört, oder bei Produkten in Form einer Software wird die Software entsprechend dem Stand der Technik entwickelt und hergestellt, wobei die Grundsätze des Software-Lebenszyklus, des Risikomanagements einschließlich der Informationssicherheit, der Verifizierung und der Validierung zu berücksichtigen sind.“
Nummer 17.4 verlangt von Ihnen zusätzlich Mindestanforderungen an Hardware, an Eigenschaften von IT-Netzen und an IT-Sicherheitsmaßnahmen einschließlich des Schutzes vor unbefugtem Zugriff. In der IVDR stehen die entsprechenden Regelungen in Anhang I Kapitel II Nummer 16, die IT-Sicherheit in Nummer 16.4.
Damit ist auch das Problem beschrieben: Der Anhang bleibt sehr vage und unkonkret. Er verlangt zwar Entwicklung „entsprechend dem Stand der Technik“ und nennt die Informationssicherheit ausdrücklich, aber er sagt nicht, welche konkrete Maßnahme diesen Stand der Technik ausfüllt.
Genau diese Lücke füllen Guidance und Norm:
- Die MDCG 2019-16 Rev.1 („Guidance on Cybersecurity for medical devices“) ist die zentrale EU-Auslegungshilfe. Sie trennt Pre-Market- und Post-Market-Anforderungen, also das, was Sie vor dem Inverkehrbringen nachweisen müssen, und das, was Sie danach dauerhaft leisten. Rechtlich bindend ist sie nicht. In Audits und Reviews kann sie aber die Prüfgrundlage ihres Auditors sein. Daher ist es empfehlenswert, sich mit den Inhalten zu beschäftigen.
- Die IEC 81001-5-1 („Health software and health IT systems safety, effectiveness and security, Part 5-1: Security, Activities in the product life cycle“) setzt genau hier an: Sie beschreibt, was der von Nummer 17.2 geforderte Stand der Technik in der Security konkret bedeutet, nämlich die Security-Aktivitäten im Produktlebenszyklus. Damit ergänzt sie die IEC 62304, die den Software-Lebenszyklus und die Safety regelt, aber Security-Aktivitäten wenig konkret behandelt. Die meisten Benannten Stellen behandeln die IEC 81001-5-1 mittlerweile faktisch als Stand der Technik für MDR-Software. Sie ist damit kein formaler Zwang, aber der Maßstab für Ihre Entwicklung.
Andere Regulierungen unabhängig vom Medizinprodukt-Status
Neben dem Medizinprodukterecht gelten für Sie Regelungen, die sich über alle Branchen erstrecken. Hier sind einige Beispiele:
- DSGVO: Artikel 32 der Datenschutz-Grundverordnung (DSGVO) verlangt technische und organisatorische Maßnahmen (TOM), sobald Sie personenbezogene Gesundheitsdaten verarbeiten, unabhängig vom Produktstatus. Implizit entstehen daraus eine Menge an Cyber Security-Maßnahmen.
- AI Act: die Verordnung (EU) 2024/1689 ist zu prüfen, sobald Ihr Produkt KI-Funktionen enthält, siehe unseren Artikel zum AI Act für Medizinprodukte.
- BSI TR-03161: die technische Richtlinie des Bundesamts für Sicherheit in der Informationstechnik (BSI) ist für digitale Gesundheitsanwendungen (DiGA) Pflicht, Details in unserem Artikel zur BSI TR-03161.
- NIS-2-Richtlinie: die Zweite EU-Richtlinie zur Netzwerk- und Informationssicherheit (Richtlinie (EU) 2022/2555) trifft Sie als Unternehmen, und zwar allein wegen Branche und Größe. Die Herstellung von Medizinprodukten und In-vitro-Diagnostika ist in Anhang II der Richtlinie erfasst. Sie gelten als „wichtige Einrichtung“, sobald Sie mindestens 50 Beschäftigte haben oder Jahresumsatz und Jahresbilanzsumme jeweils 10 Mio. Euro übersteigen. In Deutschland umgesetzt über das NIS2-Umsetzungsgesetz und das novellierte BSI-Gesetz.
Je nach Produkt, Einsatzgebiet und Unternehmenskontext können weitere Pflichten für Sie gelten. Dies muss immer individuell für jedes Produkt untersucht werden.
Übersicht der Cyber-Security-Anforderungen für (Software-)Medizinprodukte
4. Wann betrifft der CRA Sie trotzdem?
Der Ausschluss gilt produktbezogen. Im Portfolio eines Medizinprodukteherstellers stehen manchmal auch Produkte ohne MDR-Bezug, und genau dort greift der CRA.
Als Faustregel gilt: Sobald ein Produkt oder ein Modul nicht unter die MDR fällt, eigenständig auf dem Markt bereitgestellt wird und das Konnektivitätskriterium aus Kapitel 1 erfüllt, ist der CRA zu prüfen.
Die kritische Frage ist also, ob alle Ihre Produkte Medizinprodukte sind? (siehe auch unseren Leitfaden „Ist Ihre Software ein Medizinprodukt?“)
Typische Fälle von Nicht-Medizinprodukten sind z.B.:
- Wellness- und Lifestyle-Apps ohne medizinische Zweckbestimmung
- Praxis- und Klinik-Tools, etwa für Terminverwaltung oder Abrechnung
- Auswertungs-Dashboards und Portale
- separat vermarktete Bausteine wie ein Software Development Kit (SDK)
Die Frage ist also nicht, ob Sie Medizinproduktehersteller sind, sondern welches Ihrer Produkte unter welche Verordnung fällt.
Bei der Abgrenzung hilft eine klare Zweckbestimmung je Produkt und bei Modulen die Frage, ob das Modul eigenständig bereitgestellt wird oder Teil des Medizinprodukts ist.
Unsere Empfehlung: Legen Sie einmal eine Portfolio-Liste an und ordnen Sie jedem Produkt und jedem eigenständig vermarkteten Modul genau eine Kategorie zu: MDR, IVDR oder CRA (sowie weitere Regulierungen).
5. Ausblick: Die MDR-Revision holt die CRA-Logik ins Medizinprodukterecht
Am 16.12.2025 hat die Europäische Kommission ihren Vorschlag zur Überarbeitung von MDR und IVDR vorgelegt: Link zum Änderungsvorschlag. Darin benennt die Kommission den CRA-Ausschluss ausdrücklich als Lücke.
Der Gedankengang von Erwägungsgrund 44 des Vorschlags: Der CRA verpflichtet Hersteller, aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle an die CSIRTs und die ENISA zu melden. Medizinprodukte und In-vitro-Diagnostika sind davon ausgenommen. Sicherheitsvorfälle ohne Auswirkung auf die öffentliche Gesundheit oder die Patientensicherheit werden damit im Medizinprodukterecht nicht gemeldet, denn die Vigilanzregeln von MDR und IVDR greifen nur bei schwerwiegenden Vorkommnissen. Der Erwägungsgrund zieht daraus den Schluss:
„Dies stellt eine erhebliche Lücke im Bereich der Cybersicherheit dar. Hersteller vernetzter Produkte sollten daher verpflichtet werden, auch diese Vorfälle über Eudamed an die CSIRTs und ENISA zu melden.“
Eudamed ist dabei die Europäische Datenbank für Medizinprodukte nach Artikel 33 der MDR.
Umgesetzt werden soll das über einen neuen Artikel 87a der MDR, mit einem Pendant in Artikel 82a der IVDR. Seine Überschrift lautet:
„Meldung aktiv ausgenutzter Schwachstellen und schwerwiegender Sicherheitsvorfälle im Zusammenhang mit Produkten“
Bemerkenswert ist, dass die Definitionen direkt aus dem CRA übernommen werden. Die CRA-Mechanik wandert damit inhaltlich ins Medizinprodukterecht, ohne dass der CRA selbst anwendbar wird.
Zusätzlich soll Cybersecurity in Anhang I der MDR aufgenommen werden. Die Übersichtstabelle des Vorschlags formuliert die Absicht so:
„In Anhang I MP-VO/IVD-VO wird die Cybersicherheit in den grundlegenden Sicherheits- und Leistungsanforderungen ausdrücklich genannt.“
Konkret soll MDR Anhang I Nummer 17.4 um das Wort ‚Cybersicherheit‘ ergänzt werden. In der IVDR wird Nummer 16.4 entsprechend geändert.
Hinweis: Das ist ein Vorschlag der Kommission und noch nicht geltendes Recht. Europäisches Parlament und Rat müssen zustimmen, danach folgt eine Übergangszeit.
6. Fazit
Der Cyber Resilience Act ist auf MDR- und IVDR-Produkte nicht anwendbar. Artikel 2 Absatz 2 des CRA schließt sie ausdrücklich aus. Der Gesetzgeber will hier sinnvollerweise Doppelregulierung vermeiden.
Irrelevant ist der CRA für Sie deshalb nicht. Zu klären bleiben die Nicht-Medizinprodukte in Ihrem Portfolio, die in Kapitel 4 beschriebenen separat vermarkteten Softwarebausteine wie ein Software Development Kit.
Für Software-Medizinprodukte gelten dennoch strikte Anforderungen an Cyber Security. Die kommen jedoch nicht aus dem Cyber Resilience Act und sind auch nicht neu. Sie kommen aus der MDR (oder IVDR) und damit verbunden aus der MDCG 2019-16, IEC 81001-5-1 und weiteren anwendbaren Regulierungen.
Sie planen die Umsetzung einer Medical Software, einer DiGA oder eines Embedded-Projekts? Kontaktieren Sie uns gerne. Wir entwickeln regulierte Medical Software (Health Apps, DiGA, Web-Plattformen etc.) und Embedded Software auf Auftragsbasis.
