Cybersecurity bei Medizinprodukten 2026: Der MITRE-Bericht entschlüsselt
Interlynk
Im April 2026 veröffentlichte MITRE einen Bericht, der weit mehr Aufmerksamkeit verdient, als er in den meisten Compliance-Gesprächen erhält: Cybersecurity Risk Analysis for Medical Devices in the Era of Evolving Technologies (Cybersicherheitsrisikoanalyse für Medizinprodukte im Zeitalter sich entwickelnder Technologien). Er wurde für die US-Regierung erstellt und basiert auf Interviews mit Medizinprodukteherstellern (MDMs), Organisationen des Gesundheitswesens (HDOs), Anbietern von Cybersicherheitslösungen und Regulierungsberatern. Der Bericht stellt drei Technologien – Cloud-Computing, KI/ML und Post-Quanten-Kryptographie – den aktuellen Realitäten der Cybersicherheit gegenüber, mit denen Medizinproduktehersteller heute konfrontiert sind.
Dieser Bericht ist keine Checkliste. Er skizziert eine Risikolandschaft. Und wenn man ihn aufmerksam liest, kristallisiert sich ein Thema immer wieder heraus, selbst wenn die Autoren es nicht direkt aussprechen: Die Lieferkette für Medizinprodukte ist heute die eigentliche Angriffsfläche.
Dieser Beitrag schlüsselt auf, was der Bericht tatsächlich aussagt, wo er MDMs zum Handeln auffordert und warum diejenigen Unternehmen, die ihre Software-Stückliste (Software Bill of Materials – SBOM) als lebendiges Sicherheitsinstrument und nicht bloß als regulatorisches Pflichtdokument behandeln, am besten für das gerüstet sind, was auf sie zukommt.
Der zentrale Wandel: Gemeinsame Verantwortung im gesamten Ökosystem
Jahrzehntelang war das Cybersicherheitsmodell für Medizinprodukte relativ klar definiert. Ein Medizinproduktehersteller (MDM) entwickelte und verkaufte das Gerät; eine Gesundheitseinrichtung (HDO) betrieb es in einem von ihr kontrollierten Netzwerk. Die Verantwortlichkeiten waren klar abgegrenzt.
Dieses Modell gehört der Vergangenheit an.
Der Bericht von MITRE dokumentiert, was Anwender in der Praxis bereits selbst erleben: Das moderne Medizinprodukt ist zunehmend ein verteiltes System. Seine wesentlichen Funktionen hängen oft von einer Cloud-Infrastruktur ab, die von einem Drittanbieter verwaltet wird, von KI/ML-Modellen, die auf Datenpipelines trainiert wurden, die der Hersteller nicht vollständig besitzt, und von kryptografischen Kontrollen, die innerhalb eines Jahrzehnts veraltet sein werden. Gleichzeitig wird das Gerät selbst möglicherweise außerhalb des Krankenhauses betrieben – in der Wohnung eines Patienten, ohne dass jemand mit Sicherheitskompetenz es verwaltet.
Der Bericht bringt es auf den Punkt: Das Risikomanagement der Cybersicherheit von Medizinprodukten war schon immer eine gemeinsame Verantwortung von Herstellern und Gesundheitseinrichtungen, aber bei der Definition von Rollen und Zuständigkeiten kommen nun zusätzliche Drittanbieter ins Spiel.
Was das in der Praxis bedeutet: Die Angriffsfläche ist nicht mehr das Gerät selbst. Es ist das gesamte Ökosystem, von dem das Gerät abhängt.
Cloud-Anwendungen in Medizinprodukten: Risikokategorien
Die Einführung von Cloud-Technologien im Design von Medizinprodukten hat sich beschleunigt, was zum Teil auf die Rechenanforderungen von KI/ML und zum Teil auf die Wirtschaftlichkeit von SaaS-Diensten zurückzuführen ist. Der Bericht von MITRE äußert sich offen zu den Risiken, die dies mit sich bringt.
Wenn die wesentliche Funktionalität eines Medizinprodukts in der Cloud liegt — unabhängig davon, ob der MDM (Medizinproduktehersteller) IaaS, PaaS oder SaaS von einem Drittanbieter bezieht —, kann der MDM die Sicherheitslage dieser Infrastruktur nicht vollständig kontrollieren. Cloud-Service-Anbieter unterliegen nicht denselben regulatorischen Rahmenbedingungen wie Medizinprodukte. Deren Ausfälle, Fehlkonfigurationsereignisse und Sicherheitsverletzungen werden alle zum Patientensicherheitsproblem des MDMs.
Der Ransomware-Angriff auf Elekta wird im Bericht direkt als Beleg angeführt: Eine einzige cloudbasierte Dienstunterbrechung beeinträchtigte gleichzeitig die Krebsbehandlung in über 170 Einrichtungen. Dies ist das Problem des Schadensradius (Blast-Radius), das On-Premise-Architekturen in diesem Ausmaß selten verursacht haben.
Der Bericht identifiziert drei Kategorien zur Schadensbegrenzung von Cloud-Risiken:
Richtlinien und Prozesse. Service-Level-Agreements (SLAs) zwischen MDMs und Cloud-Service-Anbietern müssen Sicherheitserwartungen präzise definieren — nicht nur SLAs bezüglich der Ausfallzeit. Die Beschaffungskontrollen der ISO 13485:2016 (Klauseln 7.4.1–7.4.3) bieten einen Rahmen, um von Lieferanten, einschließlich Cloud-Anbietern, angemessene Notfallpläne zu fordern.
Resiliente Architektur und Design. Hier wird die Diskussion um die Software-Stückliste (SBOM) unumgänglich. Der Bericht von MITRE stellt unmissverständlich fest, dass SBOMs für cloudbasierte Medizinprodukte alle Cloud-Komponenten enthalten müssen — virtuelle Maschinen, Container, jede Schicht des Container-Images, Maschinen-Images und cloud-native Dienste. Eine SBOM, die an der Grenze des Anwendungscodes endet, ist für ein mit der Cloud verbundenes Gerät unvollständig. Sie sagt Ihnen, was Sie ausgeliefert haben. Sie sagt Ihnen nicht, wovon Ihr Gerät zur Laufzeit abhängt.
Vorbereitung und Reaktion. Multi-Regionen-Bereitstellung, lokales Caching als Fallback-Architektur und Backup-Strategien, die Cyberangriffsszenarien anstelle von reinen Hardwareausfällen berücksichtigen.
Die betriebliche Auswirkung: MDMs müssen den Inhalt ihres Cloud-Stacks mit derselben Präzision kennen, die sie auch für die Dokumentation von Hardware-Komponenten aufbringen. Die meisten tun dies heute nicht.
KI/ML in Medizinprodukten: Blackbox als Problem für die Patientensicherheit
Bis September 2025 war die Datenbank der FDA für KI-gestützte Medizinprodukte auf 1.357 Einträge angewachsen – die überwältigende Mehrheit davon konzentriert in der Radiologie (76 %) und der Kardiologie (9,5 %). Dies sind keine experimentellen Technologien mehr. Sie ebnen sich den Weg und erreichen die Patienten.
Der Bericht von MITRE äußert sich bemerkenswert zurückhaltend über den Enthusiasmus für KI/ML im medizinischen Kontext. Ihre Interviews ergaben, dass es für MDMs (Medizinproduktehersteller) und HDOs (Gesundheitsdienstleister) im Allgemeinen nicht klar ist, wo KI/ML Vorteile bieten würde, die die damit verbundenen Risiken überwinden. Das ist eine bemerkenswerte Aussage für eine Forschungsorganisation und spiegelt wider, was Kliniker seit Jahren sagen: Das Vertrauensdefizit ist real.
Die Cybersicherheitsdimensionen dieses Vertrauensdefizits sind detailliert dokumentiert.
Die Integrität der Trainingsdaten ist ein Lieferkettenproblem. Wenn ein Angreifer die Daten in einer beliebigen Phase des KI/ML-Lebenszyklus manipuliert – bei der Rohdatenerfassung, der Kennzeichnung, dem Training oder der Validierung –, trägt das resultierende Modell diese Korrumpierung bis in die Produktion. Dies ist funktionell identisch mit einem Angriff auf die Software-Lieferkette. Man liefert die Sicherheitslücke mit dem Produkt aus. Angriffe zur Rekonstruktion von Trainingsdaten (Membership Inference Attacks) können sogar dazu genutzt werden, Informationen über die Subjekte der Trainingsdaten zu extrahieren, was neben dem Sicherheitsrisiko auch ein HIPAA-Datenschutzrisiko darstellt.
Das Black-Box-Problem bricht die traditionelle Sicherheitsgarantie. Die Analyse der Softwaresicherheit hängt von der Nachvollziehbarkeit ab: Man kann den Code Schritt für Schritt durchgehen, Variablenzustände beobachten, einen Stack-Trace verfolgen und einen Fehler reproduzieren. Bei KI/ML ist das zugrunde liegende Verhalten in der Regel eine Black Box, bei der die Ergebnisse bei jedem Durchlauf variieren können. Dies ist mit den heutigen Werkzeugen kein lösbares Problem – es ist eine inhärente Eigenschaft der Technologie. MITRE ist hierbei direkt: Es kann kein vollständiges Vertrauen darauf geben, dass eine Lösung in 100 % der Fälle fehlerfrei funktioniert.
Der adaptive Modus schafft eine kontinuierliche Angriffsfläche. MDMs, die sich für adaptive KI/ML-Modelle entscheiden – bei denen das Modell in der Produktionsumgebung weiterlernt –, erben eine dauerhafte Angriffsfläche: die Datenpipeline. Manipulierte Eingabedaten können die Modellleistung im Laufe der Zeit auf eine Weise verschlechtern, die möglicherweise nicht sofort erkennbar ist, insbesondere wenn der Angreifer geduldig vorgeht.
Der gesperrte Modus schafft Klarheit bei der Versionskontrolle, aber auch Rigidität. Statische, versionierte Modelle bieten vorhersehbarere Sicherheitseigenschaften und eine klarere Überprüfbarkeit. Der Nachteil ist, dass Aktualisierungen bewusste Retrainingszyklen erfordern, die hinter der klinischen Realität, die das Modell abbilden muss, hinterherhinken können.
Die im Bericht empfohlenen Schadensbegrenzungsmaßnahmen – gesicherte Lernumgebungen, Schutzbarrieren mit Tests auf Robustheit gegenüber gegnerischen Angriffen (Adversarial Robustness Testing), Bedrohungsanalysen, die KI/ML-Komponenten explizit einschließen, sowie Least-Privilege-Architekturen für KI-Subsysteme – sind alle fundiert. Aber sie erfordern, dass KI/ML-Komponenten als erstklassige Software-Artefakte mit eigener Herkunft, Versionierung und Abhängigkeitsverfolgung behandelt werden. Was wiederum ein SBOM-Problem (Software-Stückliste) ist.
Post-Quanten-Kryptografie: Die Bedrohung mit einer Frist
Von den drei im Bericht behandelten Technologiebereichen ist die Post-Quanten-Kryptographie (PQC) derjenige mit dem am klarsten definierten regulatorischen Weg und der geringsten Dringlichkeit in der Branche – eine Kombination, die in der Vergangenheit stets zu schlechten Ergebnissen geführt hat.
Die Lage ist ganz einfach: Quantencomputer, die in der Lage sind, den Shor-Algorithmus in großem Maßstab auszuführen – was das NIST als kryptanalytisch relevanten Quantencomputer (CRQC) bezeichnet –, würden RSA, Diffie-Hellman und die Elliptic Curve Cryptography mathematisch brechen. Jedes Medizinprodukt, das heute durch diese Algorithmen gesichert ist, würde anfällig für Entschlüsselung.
Der Angriffstyp „Jetzt ernten, später entschlüsseln“ (Harvest now, decrypt later) ist auf staatlicher Ebene bereits im Gange. Angreifer benötigen heute noch keinen CRQC. Sie müssen lediglich den verschlüsselten Datenverkehr – Gerätekommunikation, Patientendaten, herstellereigene Telemetrie – erfassen und speichern, bis die Quantenrechenleistung so weit ist. Bei medizinischen Geräten mit einer Einsatzlebensdauer von 10 bis 15 Jahren könnten heute übertragene Daten noch innerhalb der Betriebslebenszeit des Geräts entschlüsselbar sein.
Das NIST hat im August 2024 seine ersten endgültigen Post-Quanten-Algorithmus-Standards (FIPS 203, 204 und 205) veröffentlicht. Das NIST hat Pläne angekündigt, alle CRQC-anfälligen asymmetrischen Algorithmen bis 2035 als „unzulässig“ (Disallowed) einzustufen. Die NSA hat sich zum Ziel gesetzt, nationale Sicherheitsanwendungen bis zum 31. Dezember 2031 auf CNSA 2.0 (eine reine Post-Quanten-Algorithmen-Suite) umzustellen.
Das Problem der Medizintechnikbranche ist struktureller Natur. Wie der MITRE-Bericht anmerkt, würde eine kryptographische Migration bei einem implantierbaren medizinischen Gerät, das ohne physischen Zugang zum Patienten nicht neu programmiert werden kann, einen medizinischen Eingriff erfordern. Das ist kein Software-Patch. Das ist eine klinische Entscheidung, was bedeutet, dass der Zeitrahmen für den Übergang bei einigen Gerätekategorien nicht in Sprints, sondern in Gerätegenerationen gemessen wird.
Der Bericht empfiehlt folgende praktische Maßnahmen:
Durchführung einer kryptographischen Bestandsaufnahme über alle Geräte und Systeme hinweg, um festzustellen, welche quantenanfällige asymmetrische Kryptographie verwenden
Priorisierung der Geräte nach Risikoprofil und verbleibender Zeitdauer
Integration von Krypto-Agilität in neue Gerätedesigns – also die Fähigkeit, kryptographische Implementierungen auszutauschen, ohne das Gerät neu zu entwerfen
Koordinierung der PQC-Migrationsplanung mit HDO-Partnern (Gesundheitsdienstleistern), da die Interoperabilität mit Altsystemen auch nach der Aktualisierung neuer Geräte ein dauerhaftes Risiko darstellt
Der Bericht stellt fest, dass Tools zur automatisierten kryptographischen Erkennung und Bestandsaufnahme (ACDI) zwar existieren, diese jedoch auf die allgemeine Unternehmens-IT ausgerichtet und nicht für spezialisierte Medizingeräteumgebungen validiert sind. Medizinproduktehersteller können nicht einfach ein Unternehmens-Scanning-Tool ausführen und die Arbeit als erledigt betrachten.
Was der Bericht von Ihrer SBOM-Praxis erwartet
MITRE erwu00e4hnt SBOMs explizit und spezifisch. Es lohnt sich, den Wortlaut im Kontext zu zitieren: SBOMs fu00fcr cloudbasierte Medizinprodukte wu00fcrden alle Cloud-Komponenten umfassen, wie virtuelle Maschinen, Container und alle Schichten im Container-Image, das Machine-Image und die cloudnativen Dienste.
Dies ist eine wesentlich andere Erwartung als das, was die meisten Medizinproduktehersteller (MDMs) derzeit erstellen. Die bestehenden SBOM-Richtlinien der FDA konzentrieren sich auf Softwarekomponenten im Geru00e4t selbst. MITRE beschreibt eine SBOM, die den vollstu00e4ndigen operativen Abhu00e4ngigkeitsgraphen erfasst u2013 einschlieu00dflich der Laufzeitinfrastruktur, die mu00f6glicherweise von einem Dritten verwaltet wird und sich ohne direktes Zutun des Herstellers u00e4ndern kann.
Fu00fcr KI/ML-gestu00fctzte Geru00e4te geht die Implikation noch weiter. Eine vollstu00e4ndige SBOM fu00fcr ein KI/ML-Medizinprodukt mu00fcsste die Herkunft der Trainingsdaten, die Modellversionierung, die Inferenzinfrastruktur und die Datenpipeline-Komponenten umfassen, durch die neue Trainingsdaten flieu00dfen. Nichts davon passt nahtlos in die aktuellen Spezifikationen fu00fcr SBOM-Formate, die fu00fcr Softwarepakete und nicht fu00fcr Datengu00fctzer oder Modellgewichte entwickelt wurden.
Dies ist keine Kritik am aktuellen SBOM-u00d6kosystem. Es ist eine Beschreibung dessen, wohin sich die Arbeit als Nu00e4chstes bewegen muss.
Die 10 besten Methoden aus dem Bericht entschlüsselt
Der MITRE-Bericht ist eine Risikoanalyse, keine Verschreibung. Aber sein Inhalt weist eindeutig in Richtung spezifischer Betriebspraktiken. Diese sind nicht erstrebenswert – sie sind das, was die Risikobefunde des Berichts erfordern.
Kartieren Sie Ihr Cloud-Abhängigkeitsdiagramm, nicht nur Ihre Code-Abhängigkeiten. Identifizieren Sie jeden Cloud-Dienst, den Ihr Gerät während des Betriebs berührt, einschließlich der Dienste, die nur während der Entwicklungspipelines (CI/CD-Infrastruktur, Modell-Trainingsumgebungen) verwendet werden. Ein Software-Lieferkettenangriff auf Ihre Trainingspipeline ist ein Problem für die Geräteintegrität.
Erweitern Sie Ihre SBOM um Container-Layer und Cloud-native Komponenten. Ein Container-Image ist kein einzelnes Artefakt – es ist ein Stapel von Layern, von denen jeder sein eigenes CVE-Risiko birgt. Ihre SBOM muss diese Struktur widerspiegeln.
Führen Sie vertragliche Sicherheitsüberprüfungen für jede CSP-Beziehung durch. Cloud-Anbieter werden nicht als Lieferanten der Medizinprodukte-Lieferkette reguliert, aber sie agieren funktional als solche. Ihre Einkaufsprüfungen nach ISO 13485 müssen diese erreichen.
Bauen und testen Sie Ihren Offline-Degradationsmodus. Wenn Ihre Cloud-Abhängigkeit nicht mehr verfügbar ist, was passiert mit dem Patienten? Die Entwicklung für einen kontrollierten Funktionsverlust (Graceful Degradation) ist für Geräte, die wesentliche klinische Funktionen bereitstellen, nicht optional.
Behandeln Sie Versionen von KI/ML-Modellen genauso wie Software-Releases. Modellgewichte sind Code. Trainingshyperparameter sind Konfigurationen. Die Datenherkunft ist die Abstammung der Lieferkette. Versionieren, signieren und auditieren Sie diese entsprechend.
Trennen Sie Ihre Trainings- und Testdatensätze mit der gleichen Strenge, die Sie bei den Zugriffskontrollen für Produktionsdaten anwenden. Datenkontamination (bei der Trainingsdaten in Validierungssets durchsickern oder umgekehrt) ist sowohl ein Modellqualitätsfehler als auch ein potenzieller Sicherheitsindikator.
7. Wenden Sie Bedrohungsmodellierung explizit auf KI/ML-Komponenten an. MITRE ATLAS – das Adversarial Threat Landscape for Artificial-Intelligence Systems – bietet das gegnerische Framework, das ATT&CK für traditionelle Software bereitstellt. Nutzen Sie es.
Inventarisieren Sie jede asymmetrische kryptografische Kontrolle in Ihrem gesamten Geräteportfolio. RSA, Diffie-Hellman, ECC – dokumentieren Sie, wo sie auftreten, in welchem Kontext und wie der Migrationspfad aussieht. Tun Sie dies vor 2027, nicht erst als Reaktion auf eine regulatorische Anforderung im Jahr 2034.
Entwickeln Sie neue Geräte von Anfang an für Krypto-Agilität. Die Geräte, die Sie heute bauen, werden immer noch im klinischen Einsatz sein, wenn die „Disallowed“-Frist der NIST für 2035 abläuft. Wenn die kryptografische Implementierung nicht ohne einen Hardware-Austausch aktualisiert werden kann, bauen Sie sich ein zukünftiges Rückrufproblem auf.
Definieren Sie Ihren PQC-Migrationsfahrplan in Abstimmung mit Ihren HDO-Kunden. Ein Gerät mit PQC-Kontrollen, das mit einer veralteten HDO-Infrastruktur interagiert, der diese Kontrollen fehlen, birgt weiterhin ein Quantenrisiko. Die Migration ist ein Problem auf Systemebene, nicht auf Geräteebene.
Wo die Branche steht
Der MITRE-Bericht ist bemerkenswert für das, was er nicht behauptet. Er sagt nicht, dass Hersteller von Medizinprodukten (MDMs) diese Herausforderungen im Griff haben. Er dokumentiert, womit sie konfrontiert sind und wie eine gute Praxis aussieht. Die Lücke zwischen beiden ist die eigentliche Geschichte.
Mit der Cloud verbundene Medizinprodukte werden heute von Organisationen entwickelt und zugelassen, die kein vollständiges Bild ihrer Cloud-Abhängigkeitsgraphen haben. KI/ML-Komponenten gehen in Produktion, ohne dass formale Bedrohungsmodelle existieren, die gegnerische Eingaben oder die Vergiftung von Trainingsdaten berücksichtigen. Kryptografische Inventare, deren Umsetzung 18 Monate dauern würde, wurden noch gar nicht erst begonnen.
Nichts davon liegt daran, dass MDMs nachlässig sind. Es liegt daran, dass dies wirklich schwierige Probleme sind, die regulatorischen Rahmenbedingungen der Technologie hinterherhinken und die Werkzeuge, die eine Compliance handhabbar machen würden, speziell für den Kontext von Medizinprodukten noch nicht existieren.
An diesem letzten Punkt wird die eigentliche Arbeit geleistet. Die Organisationen, die diese Werkzeuge entwickeln – und die MDMs, die frühzeitig mit ihnen zusammenarbeiten –, werden diejenigen sein, die über saubere Migrationspfade verfügen, wenn sich die regulatorischen Fristen verfestigen.
Der MITRE-Bericht ist eine Landkarte. Die Frage ist, ob Sie ihn zur Planung nutzen oder warten, bis das Gelände Sie zum Handeln zwingt.
Interlynk entwickelt Sicherheitsinfrastrukturen für die Software-Lieferkette für Teams, die SBOM als operative Disziplin und nicht als regulatorisches Kontrollkästchen betrachten. Wenn Sie daran arbeiten, wie eine vollständige SBOM-Abdeckung für cloud-connected oder KI-gestützte Medizinprodukte aussieht, würden wir uns gerne mit Ihnen unterhalten.