Fachbeitrag in mt|medizintechnik 4.2026: Warum die Instandhaltung vernetzter Medizinprodukte Cybersecurity einschließt
19. Oktober 2026
Erschienen in mt|medizintechnik, Ausgabe 4.2026
Erschienen in mt|medizintechnik, Ausgabe 4.2026
In der Fachzeitschrift mt|medizintechnik zeigt Valeri Milke, warum die Instandhaltung vernetzter Medizinprodukte heute Cybersecurity einschließt. Sein Beitrag „Instandhaltung vernetzter Medizinprodukte“ mit der Dachzeile „Schwachstellen- und Patchmanagement sind Safety-relevant“ steht in Ausgabe 4.2026, die im August 2026 mit dem Heftschwerpunkt Instandhaltung erschienen ist. Die Zeitschrift erscheint bei der TÜV Media GmbH in Köln. Autor: Valeri Milke, CEO der VamiSec GmbH, Lead Auditor für ISO/IEC 27001 und ISO/IEC 42001. In fünf Abbildungen und einer Tabelle skizziert er, wie Hersteller und Betreiber den Betrieb vernetzter Geräte als durchgängigen Prozess aufsetzen – von der Bestandsaufnahme der Softwarekomponenten über Bewertung und Behebung von Schwachstellen bis zu den Meldepflichten nach einem Sicherheitsvorfall. Diese Meldung gibt die Kernaussagen in eigenen Worten wieder und ordnet sie in den regulatorischen Stand vom Oktober 2026 ein.
Die Kernthese: Funktionsfähig heißt noch nicht sicher
Klassische Instandhaltung folgt Wartungsintervallen und prüft, ob ein Gerät seine Funktion erfüllt. Für vernetzte Medizinprodukte genügt dieser Blick nicht mehr: Eine Infusionspumpe oder ein Bildgebungssystem kann jede Funktionsprüfung bestehen und dennoch ein unvertretbares Risiko bergen – etwa weil eine längst veröffentlichte Lücke nie bewertet wurde oder ein Eindringling unbemerkt im Netz agiert. Der Beitrag stützt sich auf einen Grundsatz der europäischen Leitlinie MDCG 2019-16 (Revision 1 vom Juli 2020): Risiken für die Informationssicherheit (Security) können im klinischen Umfeld unmittelbar zu Risiken für die Patientensicherheit (Safety) werden. Typische Beispiele sind veränderte Therapieparameter, unterdrückte Alarme oder verfälschte Befunde. Schwachstellen- und Patchmanagement, Angriffserkennung im Betrieb, die Überwachung nach dem Inverkehrbringen (Post-Market Surveillance, PMS) und die Vigilanz gehören deshalb in einen gemeinsamen Steuerungsprozess – mit klar verteilten Rollen für Hersteller, Integratoren und Kliniken.
Transparenz zuerst: Komponenten kennen, Lage bewerten
Wer nicht weiß, welche Bibliotheken, Betriebssysteme und Firmware in einem Gerät stecken, kann eine neue Schwachstelle nicht zuordnen. Ausgangspunkt ist deshalb eine maschinenlesbare Software Bill of Materials (SBOM) im Format SPDX (ISO/IEC 5962) oder CycloneDX (ECMA-424), die mit jedem Release fortgeschrieben wird. Herstellerangaben zur Betroffenheit (Vulnerability Exploitability eXchange, VEX) und Sicherheitshinweise im Common Security Advisory Framework (CSAF) machen daraus ein verwertbares Lagebild. Priorisiert wird aus mehreren Blickwinkeln: technische Schwere nach dem Common Vulnerability Scoring System (CVSS), die 30-Tage-Prognose einer Ausnutzung nach dem Exploit Prediction Scoring System (EPSS), nachgewiesene Ausnutzung laut KEV-Katalog (Known Exploited Vulnerabilities) der US-Behörde CISA – und der klinische Kontext. Eine mittelschwere Lücke auf einer Therapieplattform kann dringlicher sein als eine kritische auf einem isolierten Gerät. Log4Shell und XZ Utils zeigen, wie schnell Lieferkettenrisiken ins Produkt gelangen.
Patchen als kontrollierte Änderung – und was gilt, solange kein Patch existiert
Ein Sicherheitsupdate senkt Risiken, kann aber validierte Zustände und Schnittstellen verändern. Der Beitrag versteht Patchmanagement deshalb als geregelten Änderungsprozess: betroffene Komponenten über Inventar und SBOM ermitteln, Security- und Safety-Folgen im Risikomanagement nach ISO 14971 bewerten, in einer praxisnahen Umgebung testen, freigeben, ausrollen, Wirksamkeit prüfen und dokumentieren. Betreiber sollten Updates nur nach ausdrücklicher Anleitung des Herstellers einspielen, wie es auch MDCG 2019-16 vorsieht. Fehlt ein Patch – etwa bei einer noch unbehobenen Zero-Day-Schwachstelle –, helfen vorbereitete Ausweichmaßnahmen: Netzsegmentierung, Abschalten verwundbarer Dienste, engmaschige Überwachung und klinisch abgestimmte Notbetriebsvarianten. Auch sie sind zu begründen und nachzuweisen. Für Aktualisierungen aus der Ferne (Over-the-Air, OTA) kommen signierte Pakete, ein abgesicherter Systemstart (Secure Boot), ein Rückfall-Image, Schutz vor dem Wiedereinspielen veralteter Versionen und eine gestaffelte Verteilung hinzu.
Schwachstellen von außen annehmen: CVD und PSIRT
Viele Lücken finden nicht die Hersteller selbst, sondern Sicherheitsforschende, Pentester, Integratoren oder Anwender. Damit solche Hinweise weder versanden noch ungeordnet öffentlich werden, spricht sich der Beitrag für ein geregeltes Verfahren der Coordinated Vulnerability Disclosure (CVD) aus. Orientierung bieten ISO/IEC 29147 für Entgegennahme und Veröffentlichung sowie ISO/IEC 30111 für die interne Bearbeitung. Praktisch gehören dazu eine security.txt-Datei nach RFC 9116, ein verschlüsselt erreichbares Meldepostfach, zugesagte Reaktionszeiten, eine eigene CVE Numbering Authority (CNA) oder die Zusammenarbeit mit einer bestehenden sowie maschinenlesbare Advisories im CSAF-Format. Getragen wird das Verfahren von einem Product Security Incident Response Team (PSIRT). Für Kliniken ist die Reife dieses Prozesses ein handfestes Auswahlkriterium bei der Beschaffung: Ohne nachvollziehbare Advisory-Historie bleibt offen, wie schnell kritische Hinweise beim Betreiber ankommen.
Ein Vorfall, drei Meldewege: MDR, BSI-Gesetz und DSGVO
Wann wird ein Cyber-Ereignis meldepflichtig? Hersteller unterliegen den Vigilanzpflichten der MDR: Schwerwiegende Vorkommnisse sind unverzüglich zu melden, spätestens 2 Tage nach Kenntnis bei schwerwiegender Gefahr für die öffentliche Gesundheit, 10 Tage bei Tod oder unerwarteter schwerwiegender Verschlechterung des Gesundheitszustands und ansonsten 15 Tage. Kliniken, die als besonders wichtige oder wichtige Einrichtung unter das neue BSI-Gesetz fallen – seit 6. Dezember 2025 die deutsche Umsetzung der NIS2-Richtlinie –, melden erhebliche Sicherheitsvorfälle binnen 24 Stunden als frühe Erstmeldung, binnen 72 Stunden mit einer ersten Bewertung und spätestens einen Monat nach dieser Meldung abschließend. Sind personenbezogene Daten betroffen, verlangt die DSGVO in der Regel eine Meldung an die Datenschutzaufsicht möglichst binnen 72 Stunden. Ein einziger Angriff kann alle drei Wege zugleich auslösen – bei Hersteller und Klinik. Der Beitrag empfiehlt deshalb hinterlegte Fristen, geklärte Zuständigkeiten und vorbereitete Meldevorlagen.
Warum das Thema jetzt drängt – und was Sie tun können
Die EU-Kommission hat im Dezember 2025 vorgeschlagen, MDR und IVDR um eine eigene Meldung aktiv ausgenutzter Schwachstellen und schwerwiegender Sicherheitsvorfälle zu ergänzen – über Eudamed an CSIRTs und ENISA, spätestens 30 Tage nach Kenntnis. Zugleich soll die Frist für sonstige schwerwiegende Vorkommnisse von 15 auf 30 Tage steigen; beschlossen ist beides noch nicht. Seit dem 11. September 2026 gelten zudem die Meldepflichten des Cyber Resilience Act. Medizinprodukte nimmt er aus; Zulieferkomponenten, die eigenständig als Produkte mit digitalen Elementen in Verkehr kommen, kann er aber unmittelbar erfassen. Fünf Schritte bieten sich an: ein Geräteinventar mit Softwareständen und SBOM aufbauen; SBOM, VEX und CSAF-Advisories vertraglich bei Lieferanten einfordern; eine Triage einführen, die klinische Folgen ausdrücklich bewertet; Zero-Day-Abläufe gemeinsam mit Klinik-IT, Medizintechnik und Regulatory Affairs üben; schließlich die Meldewege aus MDR, BSI-Gesetz und DSGVO in einem abgestimmten Ablauf zusammenführen.
Neu auf vamisec.com: die Wissensseite zum Thema
Neu auf vamisec.com: die Wissensseite „Instandhaltung vernetzter Medizinprodukte“. Sie greift die Thesen des Heftbeitrags auf, aktualisiert sie auf den Stand vom Oktober 2026 und vertieft sie entlang des gesamten Instandhaltungsprozesses im Feld – von Inventar und SBOM über Lagebild, Triage, Patch- und OTA-Prozess, Zero-Day-Vorbereitung und CVD bis zu Monitoring, parallelen Meldewegen und einem operativen Zielbild, ergänzt um häufige Fragen und geprüfte Quellen. Sie finden die Seite unter https://vamisec.com/de/wissen/secure-software-development/instandhaltung-vernetzter-medizinprodukte. Unsere Beratung zu MDR-Vorhaben und zur Cybersecurity von Medizinprodukten beschreiben die Seiten https://vamisec.com/de/mdr und https://vamisec.com/de/medical-device-cybersecurity – die übergreifenden MDR-Anforderungen fasst https://vamisec.com/de/wissen/grc/mdr-cybersecurity zusammen.
Alle Links
Ausgabe 4.2026 bei mt|medizintechnik: https://mt-medizintechnik.de/fokus-auf-instandhaltung/ · Wissensseite Instandhaltung vernetzter Medizinprodukte: https://vamisec.com/de/wissen/secure-software-development/instandhaltung-vernetzter-medizinprodukte · Kategorie Secure Software & Product Development, Bereich Medizinprodukte: https://vamisec.com/de/wissen/secure-software-development#medizinprodukte · MDR-Cybersecurity im Überblick: https://vamisec.com/de/wissen/grc/mdr-cybersecurity · SBOM-Management: https://vamisec.com/de/wissen/secure-software-development/sbom-management · Schwachstellenmanagement: https://vamisec.com/de/wissen/it-security/schwachstellenmanagement · MDR-Beratung: https://vamisec.com/de/mdr · Medical Device Cybersecurity: https://vamisec.com/de/medical-device-cybersecurity
Haben Sie Fragen zur IT-Sicherheit Ihres Unternehmens?
Kostenlose Erstberatung →