Ein vernetztes Medizinprodukt besteht heute selten nur aus dem Gerät. Begleit-App, Cloud-Portal, Service-Tool, Zulieferer-Komponenten – für jedes dieser Teile kann eine andere Rechtsgrundlage gelten.
Diesen Zusammenhang vertiefen wir am 22. September beim Health Electronics Summit in Stuttgart. Wer vor Ort ist, ist herzlich eingeladen vorbeizuschauen.
Zwei Gesetze für ein Produkt
Die Medical Device Regulation (MDR, Verordnung (EU) 2017/745) fragt, ob ein Gerät oder eine Softwarefunktion einen medizinischen Zweck erfüllt. Diagnose, Überwachung, Behandlung. Geprüft werden klinische Sicherheit und Wirksamkeit, nicht IT-Sicherheit.
Der Cyber Resilience Act (CRA) verlangt dagegen von allen „Produkten mit digitalen Elementen", die sich mit einem Netzwerk verbinden lassen, ein Mindestmaß an Cybersicherheit über den gesamten Lebenszyklus. Welche Fristen, Pflichten und Bußgelder damit konkret verbunden sind, haben wir bereits an anderer Stelle zusammengefasst CRA: Pflichten, Fristen und Bußgelder. Hier soll es um die Frage gehen, die dort offenbleibt: Was passiert, wenn ein Produkt beide Regelwerke gleichzeitig erfüllen muss?
Art. 2 Abs. 2 CRA nimmt Produkte aus, „auf die die MDR Anwendung findet". Das klingt nach einer klaren Trennlinie, ist aber keine Ausnahme für das ganze Produkt – nur für den Teil, der tatsächlich als Medizinprodukt zertifiziert ist. Bei einem vernetzten Gerät ist das meist nur das Gerät selbst samt eingebetteter Software. Die Begleit-App (sofern sie eine eigene medizinische Zweckbestimmung hat), das Cloud-Portal, das Service-Tool und Komponenten von Zulieferern bleiben beim CRA. Wer sich auf die MDR-Ausnahme verlässt, hat damit oft nur einen kleinen Teil seiner Systemlandschaft abgedeckt.
Wo sich beide Regelwerke treffen
Trotz unterschiedlicher Rechtsgrundlage verlangen MDR und CRA an mehreren Stellen ziemlich dasselbe:
| Thema | MDR | CRA |
| Sicher ausgeliefert | Anhang I, Abschnitt 17 | Anhang I, Teil I |
| Risiko über den Lebenszyklus | Risikomanagement nach MDCG 2019-16 | Art. 13 |
| Beobachten und melden | Vigilanzsystem, Meldung an Behörden wie das BfArM | Art. 14, Meldepflicht seit 11. September 2026 |
| Belegen, was drin ist | Technische Dokumentation | Software Bill of Materials, ab Dezember 2027 |
Ein Wort zur Unterscheidung, weil sie gern verwechselt wird: Art. 14 CRA regelt die 24- und 72-Stunden-Meldung bei aktiv ausgenutzten Schwachstellen. Art. 64 regelt die Bußgelder – bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes. Beide Details stehen im verlinkten Grundlagenbeitrag; an dieser Stelle geht es nur um den MDR-Bezug.
Was die MDR schon heute an Cybersicherheit verlangt
Auch ohne jeden CRA-Bezug fordert die MDR selbst bereits IT-Sicherheitsmaßnahmen. Anhang I, Abschnitt 17.4 verpflichtet Hersteller, Mindestanforderungen an Hardware, IT-Netzwerkeigenschaften und Schutz vor unbefugtem Zugriff festzulegen. Abschnitt 18.8 ergänzt das um eingebettete Systeme.
Konkreter wird es über die MDCG-2019-16-Leitlinie der EU-Kommission: sicheres Design, Risikomanagement über den Produktlebenszyklus, Dokumentation der Cybersicherheitsmerkmale, Marktüberwachung nach Inverkehrbringen. Und inzwischen gibt es dafür sogar eine Norm, die diese eher allgemeinen Vorgaben in einen prüfbaren Prozess übersetzt: IEC 81001-5-1, in der Branche längst als De-facto-Standard für den MDR-Cybersicherheitsnachweis etabliert.
Cybersicherheit ist in der Medizintechnik also kein Thema, das erst mit dem CRA 2027 beginnt. Über die MDR gehört sie schon länger zur Zulassung.
Baxter Life2000: der Debug-Port, der nie hätte offen sein dürfen
Der Life2000 ist ein Beatmungsgerät für Patienten, die nicht selbstständig atmen können – ein Gerät, dessen Ausfall lebensbedrohlich ist. Bei internen Sicherheitstests fand Baxter mehrere Schwachstellen gleichzeitig: einen Debug-Port an der seriellen Schnittstelle, der werksseitig aktiv war und unverschlüsselt Nachrichten empfing; fest im Code hinterlegte Zugangsdaten; und keine Prüfung, ob eine aufgespielte Firmware tatsächlich von Baxter stammte, bevor sie ausgeführt wurde. CISA bewertete die Schwachstelle CVE-2024-48973 mit einem CVSS-v4-Score von 10,0 – dem höchsten möglichen Wert.
Wer physischen Zugriff auf ein unbeaufsichtigtes Gerät bekam, konnte Therapieeinstellungen verändern oder auf Gerätedaten zugreifen. Bei einem Beatmungsgerät heißt das im schlimmsten Fall: Die lebenserhaltende Luftzufuhr funktioniert nicht mehr wie vorgesehen. Baxter meldete zum Zeitpunkt der Rückrufmeldung keine bekannten Vorfälle mit Personenschaden. Entscheidend ist die Reaktion: Baxter entschied sich nicht für ein Firmware-Update, sondern für die dauerhafte Marktrücknahme der gesamten Baureihe. Mehr als 4.800 Geräte weltweit mussten entfernt werden. FDA Class I, die höchste Risikoklasse, November 2025.
Der Grund für diese radikale Entscheidung lag genau in der Kombination der Schwachstellen: Ein offener Debug-Port allein wäre ein Konfigurationsfehler. Zusammen mit festen Zugangsdaten und einer fehlenden Integritätsprüfung für Firmware-Updates ergab sich ein Angriffspfad, der sich nicht durch ein einzelnes Patch schließen ließ, ohne die gesamte Vertrauenskette der Firmware-Verteilung neu aufzusetzen.
Medtronic MiniMed/Paradigm: die Insulinpumpe, die jedem Befehl vertraute
Die MiniMed- und Paradigm-Insulinpumpen kommunizieren per Funk mit Blutzuckermessgeräten, Sensor-Sendern und einem USB-Empfangsgerät. Sicherheitsforscher fanden 2019: Dieses Funkprotokoll prüfte nicht, von wem ein Befehl tatsächlich stammte. Jedes Gerät mit passender Ausrüstung in Funkreichweite konnte theoretisch Befehle einschleusen, verändern oder mitlesen – und damit die Insulinabgabe beeinflussen. CISA vergab dafür CVE-2019-10964 mit einem CVSS-Score von 7,1.
Ein Angreifer brauchte dafür allerdings mehr als nur Funkreichweite: die Seriennummer der konkreten Pumpe, passende Funktechnik und technisches Wissen. Die FDA bestätigte, dass ihr zum Zeitpunkt der Warnung keine tatsächlichen Missbrauchsfälle bekannt waren. Das theoretische Risiko war trotzdem gravierend, weil eine manipulierte Insulinabgabe in beide Richtungen gefährlich werden kann: zu viel Insulin kann eine Unterzuckerung auslösen, zu wenig eine Überzuckerung bis zur diabetischen Ketoazidose.
Der eigentliche Grund für den Rückruf lag nicht im Angriffsszenario selbst, sondern in der fehlenden Reparaturmöglichkeit. Weil die Pumpen keine individuelle Geräteidentität besaßen, mit der sich Kommunikationspartner eindeutig authentifizieren ließen, war ein reines Software-Update keine Lösung – die Schwachstelle steckte im Protokoll, nicht in einer einzelnen fehlerhaften Codezeile. Rund 4.000 Patienten in den USA mussten deshalb auf ein anderes, nicht betroffenes Pumpenmodell (MiniMed 670G) umgestellt werden. FDA Class I, Juni 2019.
Medtronic CareLink 2090: zwei verwandte Lücken, ein gemeinsames Problem
Der CareLink 2090 ist das Programmiergerät, mit dem Ärzte Herzschrittmacher und Defibrillatoren einstellen und auslesen. Er kommuniziert dafür per Funk – über das sogenannte Conexus-Telemetrieprotokoll – mit dem implantierten Gerät im Patienten. Sicherheitsforscher fanden: Diese Funkverbindung übertrug Daten unverschlüsselt und ohne ausreichende Zugriffskontrolle. CISA bewertete die zugehörige Schwachstelle CVE-2019-6538 mit einem CVSS-Score von 9,3 – nur knapp unter dem Maximum, weil sich die Lücke aus der Nähe und ohne besondere Vorkenntnisse ausnutzen ließ.
Das Problem lag nicht im Programmiergerät selbst, sondern im implantierten Gerät, mit dem es sprach. Und genau das machte die Reparatur so langwierig: Medtronic musste nicht ein zentrales Gerät patchen, sondern für jedes betroffene Herzschrittmacher- und Defibrillator-Modell einzeln ein Firmware-Update entwickeln und über reguläre Arzttermine an Tausende Patienten ausrollen – ein implantiertes Gerät lässt sich schließlich nicht einfach per Fernupdate über Nacht aktualisieren. Die CISA-Advisory wurde noch 2021 aktualisiert, weil zu diesem Zeitpunkt weiterhin nicht für alle betroffenen Modelle Patches verfügbar waren. (Eine kleinere, frühere Schwachstellen-Welle am Programmiergerät selbst – unsicher gespeicherte Zugangsdaten, eine Pfad-Traversal-Lücke – hatte die FDA bereits 2018 gemeldet und ist von der hier beschriebenen Telemetrie-Lücke unabhängig zu betrachten.)
Der eigentliche Engpass war der fehlende Überblick: Medtronic wusste zum Start der Patch-Kampagne nicht mit letzter Sicherheit, welches Implantatmodell mit welcher Firmwareversion bei welchem Patienten tatsächlich verbaut war. Genau dieser Versionsüberblick fehlte – nicht weil niemand ihn wollte, sondern weil er in der bestehenden Prozesskette nicht systematisch mitgeführt wurde.
Alle drei Fälle laufen auf denselben Punkt zusammen: den Moment, in dem Firmware zum ersten Mal auf den Chip kommt. Und in jedem Fall wurde dort eine von drei Entscheidungen versäumt – ein sicherer Auslieferungszustand, eine individuelle Geräteidentität, oder ein Versionsüberblick, der auch Jahre später noch stimmt.
Alle drei Fälle zeigen zudem dieselbe Zweiteilung, die sich auch juristisch als entscheidend erweist: Es geht nicht nur um die Frage, was passiert ist, sondern auch darum, ob der Programmiervorgang selbst hätte manipuliert werden können, ohne dass es jemand bemerkt hätte.
Die Beweislast verschiebt sich
Die neue Produkthaftungsrichtlinie (EU) 2024/2853 muss in Deutschland bis Dezember 2026 umgesetzt werden, und sie verschiebt die Beweislast zulasten der Hersteller. Nach Art. 10 Abs. 2 wird die Fehlerhaftigkeit eines Produkts vermutet, wenn der Beklagte relevante Beweismittel nicht offenlegt, wenn nachgewiesen wird, dass verbindliche Sicherheitsanforderungen nicht eingehalten wurden, oder wenn bei üblichem Gebrauch eine offensichtliche Funktionsstörung vorlag.
Die Fertigung eines Bauteils lässt sich auslagern. Was mit diesem Bauteil vor Verlassen der Fertigung geschehen ist, muss der Hersteller trotzdem belegen können – notfalls vor Gericht. Reine Dokumentation allein genügt dabei nicht: Ein lückenloser Nachweis über einen Programmiervorgang, der technisch manipulierbar gewesen wäre, beantwortet im Streitfall nur die halbe Frage. Die andere Hälfte lautet: Konnte der Prozess selbst überhaupt kompromittiert werden – oder war das technisch ausgeschlossen?
Was btv SEEL® an dieser Stelle liefert
An genau der Schnittstelle, an der in allen drei Fällen etwas versäumt wurde, setzt btv SEEL® an – unabhängig davon, ob das betroffene Bauteil später unter MDR, CRA oder beide Regelwerke fällt. Die vollständige Funktionsweise von CORE, INTERCONNECT und UNLIMITED steht auf der btv SEEL® Leistungsseite; hier nur die Punkte, die für Medizinprodukte besonders zählen.
Firmware und Schlüssel werden über kontrollierte, geschützte Datenräume mit standardisierten Verschlüsselungsprotokollen übertragen und beim Programmieren ausschließlich im flüchtigen Arbeitsspeicher entschlüsselt. Auf Datenträgern entstehen zu keinem Zeitpunkt unverschlüsselte temporäre Dateien – weder auf dem Übertragungsweg noch bei der Verarbeitung.
Root-Zertifikate bleiben zu 100 Prozent beim Hersteller, weil die kundeneigene PKI-Infrastruktur eingebunden wird, statt Schlüsselmaterial abzugeben. Bei Firmware mit medizinischer Funktion ist das kein Detail, sondern eine Frage des geistigen Eigentums.
Und jedes Bauteil bekommt in Serienfertigung eine individuelle, automatisiert dokumentierte und kryptografisch signierte Identität – bis auf Ebene der einzelnen Verpackungseinheit, wo nötig auch auf Ebene des einzelnen Geräts. Das liegt über dem gesetzlichen Minimum: Art. 13 Abs. 15 CRA verlangt lediglich eine Typen-, Chargen- oder Seriennummer. Der Unterschied ist aber genau der, der beim MiniMed-Vorfall zwischen einem Software-Update und dem physischen Austausch von 4.000 Geräten lag – und der, der bei CareLink darüber entschieden hätte, ob Medtronic von Anfang an wusste, welches Implantat welchen Patch braucht, statt es über Jahre herausfinden zu müssen.
Ein Punkt zur Einordnung, der nicht fehlen soll: btv SEEL® macht ein Medizinprodukt nicht „MDR-konform" oder „CRA-konform". Diese Regelwerke adressieren das Endprodukt des Herstellers, nicht die Dienstleistung von btv technologies. Was btv SEEL® liefert, sind zwei Dinge, die zusammengehören: ein Programmierverfahren, das unautorisierte Veränderungen entlang des gesamten Wegs erschwert – von der Übertragung über geschützte Datenräume bis zur Verarbeitung ausschließlich im flüchtigen Speicher – und der daraus resultierende, belastbare Nachweis auf Bauteilebene.
Ein Nachweis über einen verwundbaren Prozess wäre im Zweifel wenig wert; ein geschützter Prozess ohne Nachweis lässt sich im Audit oder Rückruf nicht belegen. Beides zusammen ist die Grundlage, die Hersteller für ihre eigene Konformitätsbewertung und im Haftungsfall brauchen. Und dieser Nachweis reicht weit zurück: btv dokumentiert Komponenten über mindestens 20 Jahre, rückverfolgbar bis 2006. Bei Medizinprodukten mit langen Marktzyklen ist das kein Nebensatz.
Warum das gerade jetzt zählt
Seit dem 11. September 2026 gilt die 24-Stunden-Meldepflicht für aktiv ausgenutzte Schwachstellen nach Art. 14 CRA. Ein Sicherheitsvorfall in der Konnektivitäts-, Cloud- oder Service-Komponente eines vernetzten Medizinprodukts muss künftig genauso schnell eingegrenzt werden können wie ein Vorkommnis über das MDR-Vigilanzsystem. Ab Dezember 2026 kommt die verschärfte Beweislast nach der Produkthaftungsrichtlinie hinzu.
Drei Fristen gleichzeitig zu bedienen, ohne dass Firmware, Charge und Zertifikat im Nachhinein rekonstruiert werden müssen – das ist der eigentliche Unterschied zwischen Herstellern, die vorbereitet sind, und solchen, die es erst im Ernstfall merken.
Häufige Fragen zu MDR und CRA bei Medizinprodukten
Ja, teilweise. Art. 2 Abs. 2 CRA nimmt nur den Teil eines Produkts aus, der tatsächlich als Medizinprodukt zertifiziert ist – zum Beispiel eine EKG-Funktion mit eigener Zweckbestimmung. Begleit-Apps ohne eigene medizinische Zweckbestimmung, Cloud-Portale, Service-Tools und Zulieferer-Komponenten bleiben CRA-pflichtig, auch wenn das Gesamtgerät eine MDR-Zulassung trägt.
Nein. MDR prüft klinische Sicherheit und Wirksamkeit, der CRA prüft Cybersicherheit über den gesamten Produktlebenszyklus. Beide Regelwerke überschneiden sich inhaltlich an mehreren Stellen – etwa bei Risikomanagement oder Meldepflichten –, sind aber rechtlich getrennt zu erfüllen und werden auch getrennt geprüft.
Nein. MDR und CRA adressieren das Endprodukt des Herstellers, nicht die Dienstleistung eines Zulieferers. btv SEEL® liefert zwei zusammengehörige Dinge: ein Programmierverfahren, das unautorisierte Veränderungen bei Übertragung und Verarbeitung erschwert, und den daraus resultierenden Nachweis auf Bauteilebene – etwa zu Firmware-Version, Programmierzeitpunkt und Geräteidentität –, die Grundlage, die Hersteller für ihre eigene Konformitätsbewertung benötigen.
Art. 13 Abs. 15 CRA verlangt rechtlich nur eine Typen-, Chargen- oder Seriennummer zur Identifikation. Bei sicherheitskritischen Medizinprodukten kann das im Ernstfall zu grob sein: Der MiniMed-Vorfall zeigt, dass eine fehlende individuelle Geräteidentität aus einem eingrenzbaren Software-Update einen physischen Austausch von Tausenden Geräten machen kann.
