Instandhaltung vernetzter Medizinprodukte

Medizintechnische Abteilungen planen Instandhaltung traditionell entlang von Prüffristen, Herstellervorgaben und Ausfallkosten. Für vernetzte Geräte reicht das nicht mehr: Ein Ultraschallsystem, ein Patientenmonitor oder eine Infusionspumpe mit Netzanschluss enthält ein Betriebssystem, Bibliotheken und Schnittstellen, deren Sicherheitslage sich täglich ändert – auch dann, wenn am Gerät selbst nichts passiert. Ein Gerät, das jede elektrische Sicherheitsprüfung besteht, kann deshalb zugleich ein offenes Einfallstor sein.

Wie real das Problem ist, zeigte die BSI-Studie ManiMed: Das Bundesamt untersuchte zehn netzwerkfähige Medizinprodukte aus fünf Produktkategorien und meldete den Herstellern im Projektverlauf mehr als 150 Schwachstellen. Der Abschlussbericht erschien im Dezember 2020.

Was Cyber-Resilienz im Betrieb heißt

Cyber-Resilienz meint die Fähigkeit, ein Gerät trotz neuer Schwachstellen und Angriffe sicher weiter zu betreiben oder begründet einzuschränken. Daraus folgen zusätzliche Aufgaben neben dem Wartungsplan:

• ein aktuelles Inventar aller Geräte, Softwarestände und Drittkomponenten,
• ein laufendes Lagebild zu neuen Schwachstellen und aktiven Angriffen,
• eine Bewertung, die technische Schwere mit klinischen Folgen verbindet,
• Updates und Ersatzmaßnahmen als dokumentierte, freigegebene Änderungen,
• ein Kanal für Schwachstellenhinweise von außen,
• Überwachung, Vorfallbehandlung und fristgerechte Meldungen.

Diese Seite fasst den Fachbeitrag „Instandhaltung vernetzter Medizinprodukte“ aus mt|medizintechnik, Ausgabe 4.2026, zusammen, ordnet ihn neu und ergänzt ihn um Entwicklungen bis Oktober 2026.

Neben Vertraulichkeit, Integrität und Verfügbarkeit stellt sich bei Medizinprodukten eine vierte Frage: Kann ein Angriff die vorgesehene Leistung beeinträchtigen oder Menschen schädigen? Die Leitlinie MDCG 2019-16 betont, dass Security-Risiken bei Medizinprodukten nicht losgelöst von Safety-Risiken betrachtet werden dürfen.

Wie aus einer IT-Lücke ein klinisches Risiko wird

• Integrität: Manipulierte Messwerte, Bilder oder Befunde führen zu falschen Diagnosen.
• Verfügbarkeit: Ein verschlüsseltes oder abgestürztes System verzögert Untersuchungen oder Eingriffe.
• Steuerung: Wer Therapie- oder Alarmparameter verändern kann, greift unmittelbar in die Behandlung ein.
• Vertraulichkeit: Abgeflossene Gesundheitsdaten berühren den Datenschutz und das Vertrauen der Patientinnen und Patienten.

Daraus folgt eine zentrale Regel für die Bewertung im Feld: Der technische Schweregrad allein bestimmt nicht die Dringlichkeit – entscheidend ist, was ein Angreifer am konkreten Gerät und im konkreten Behandlungsablauf bewirken könnte.

Zwei Risikoakten, ein Ergebnis

Hersteller führen ihr Risikomanagement nach ISO 14971, die als EN ISO 14971 unter der MDR harmonisiert ist. Security-Risiken werden oft in einer eigenen Analyse bewertet. Entscheidend ist die Verbindung: Jedes Security-Szenario mit möglicher Auswirkung auf Patienten oder Anwender muss in der Safety-Risikoakte auftauchen, und jede Safety-Maßnahme, die auf Software beruht, braucht eine Security-Betrachtung. Im Feld wiederholt sich diese Prüfung bei jeder neuen Schwachstelle und jedem Vorfall – einschließlich der Frage, ob das Nutzen-Risiko-Verhältnis neu zu bewerten ist.

MDR: Pflichten des Herstellers

Die MDR gilt seit dem 26. Mai 2021. Sie verlangt Software nach dem Stand der Technik mit einem Risikomanagement, das Informationssicherheit einschließt, Schutz vor unbefugtem Zugriff und Mindestanforderungen an IT-Netze in der Gebrauchsanweisung. Nach dem Inverkehrbringen betreiben Hersteller ein System zur Überwachung (Post-Market Surveillance, PMS). Ab Klasse IIa gehört dazu ein regelmäßig aktualisierter Sicherheitsbericht (Periodic Safety Update Report, PSUR) – für die Klassen IIb und III mindestens jährlich, für Klasse IIa mindestens alle zwei Jahre.

MDCG 2019-16: gemeinsame Verantwortung

Die Leitlinie MDCG 2019-16 in der Revision vom Juli 2020 überträgt diese Anforderungen auf den gesamten Lebenszyklus. Sie stellt klar, dass Cybersecurity Teil des PMS-Systems ist und auch Drittkomponenten einschließt. Zugleich beschreibt sie eine gemeinsame Verantwortung: Rechtlich ist der Hersteller gebunden, praktisch tragen auch Lieferanten, Integratoren, Gesundheitseinrichtungen und Behörden Verantwortung. Änderungen am Gerät, einschließlich Patches und Fremdsoftware, sind nur auf Grundlage ausdrücklicher, veröffentlichter Herstellervorgaben vorgesehen.

Normen als Stand der Technik

Medizinprodukte-Betreiberverordnung: Updates sind Instandhaltung

Für Betreiber in Deutschland konkretisiert die Medizinprodukte-Betreiberverordnung, die in neuer Fassung seit dem 20. Februar 2025 gilt, was Instandhaltung umfasst: neben Wartung, Inspektion und Instandsetzung bei Software ausdrücklich auch die Installation sicherheitsrelevanter Updates – unter Beachtung der Herstellerangaben. Ändert ein Update die Handhabung wesentlich, ist das Personal erneut einzuweisen. Für Software, die als Medizinprodukt der Klassen IIb oder III eingestuft ist, verlangt die Verordnung in Gesundheitseinrichtungen seit dem 1. August 2025 außerdem IT-Sicherheitsüberprüfungen nach den anerkannten Regeln der Technik, spätestens alle zwei Jahre und mit Protokoll.

BSI-Gesetz: Pflichten der Klinik

Seit dem 6. Dezember 2025 setzt das neue BSI-Gesetz die NIS2-Richtlinie in Deutschland um. Krankenhäuser gehören zum Sektor Gesundheit. Erfasst sind in der Regel Einrichtungen ab 50 Beschäftigten oder mit mehr als 10 Millionen Euro Umsatz und Bilanzsumme; ab 250 Beschäftigten oder mehr als 50 Millionen Euro Umsatz und 43 Millionen Euro Bilanzsumme gelten sie als besonders wichtig, Krankenhäuser mit kritischer Anlage – bisher ab 30.000 vollstationären Fällen pro Jahr – unabhängig von ihrer Größe. Zu den Pflichten gehören ausdrücklich Sicherheit bei Erwerb, Entwicklung und Wartung einschließlich des Managements und der Offenlegung von Schwachstellen sowie die Sicherheit der Lieferkette.

Cyber Resilience Act und FDA im Umfeld

Der Cyber Resilience Act gilt nicht für Produkte, auf die MDR oder IVDR anwendbar sind. Er wirkt dennoch in die Medizintechnik hinein: Zulieferer, die Komponenten mit digitalen Elementen eigenständig vertreiben, unterliegen seit dem 11. September 2026 seinen Meldepflichten und ab dem 11. Dezember 2027 den Hauptpflichten. International setzt die US-Arzneimittelbehörde FDA Maßstäbe: Für sogenannte Cyber Devices verlangt sie in Zulassungseinreichungen seit dem 29. März 2023 unter anderem eine SBOM, einen Plan für den Umgang mit Schwachstellen samt Coordinated Vulnerability Disclosure und Updates in einem begründeten Zyklus.

Am Tag der Veröffentlichung von Log4Shell, dem 10. Dezember 2021, stellte sich in vielen Organisationen dieselbe Frage: In welchen Produkten steckt die betroffene Bibliothek? Für Medizinprodukte ist diese Ungewissheit besonders heikel, weil Kliniken Geräte in der Regel weder selbst scannen noch verändern dürfen, ohne dass der Hersteller dies vorsieht.

Was eine SBOM leistet

Die Software Bill of Materials (SBOM) listet die Softwarebestandteile eines Produkts maschinenlesbar auf – mit Bezeichnung, Version, Lieferant, Prüfsumme und Abhängigkeiten. Zwei Formate haben sich durchgesetzt: CycloneDX, seit Juni 2024 als ECMA-424 standardisiert, und SPDX, dessen Version 2.2.1 als ISO/IEC 5962:2021 normiert ist. Welche Mindestinhalte eine SBOM haben sollte, beschreibt in Deutschland die Technische Richtlinie TR-03183-2 des BSI.

Pflicht oder Erwartung?

In den USA ist die SBOM für Cyber Devices Teil der Zulassungseinreichung. Das europäische Medizinprodukterecht kennt keine ausdrückliche SBOM-Pflicht; MDCG 2019-16 nennt die Stückliste als Beispiel für Sicherheitsinformationen an Betreiber. Die Erwartung folgt hier aus dem Stand der Technik nach IEC 81001-5-1. Für Zulieferkomponenten, die unter den Cyber Resilience Act fallen, wird eine SBOM als Teil der technischen Dokumentation ab dem 11. Dezember 2027 verpflichtend.

Von der Liste zum Lagebild

Wirksam wird eine SBOM erst, wenn der Hersteller sie bei jedem Build neu erzeugt und laufend gegen Schwachstellendaten abgleicht. Weil eine verwundbare Bibliothek nicht automatisch ein verwundbares Gerät bedeutet, ergänzt der Hersteller Aussagen zur tatsächlichen Betroffenheit (Vulnerability Exploitability eXchange, VEX). Ausgetauscht werden solche Hinweise maschinenlesbar im Common Security Advisory Framework (CSAF), seit November 2022 ein OASIS-Standard in Version 2.0.

Was Kliniken in der Beschaffung festlegen sollten

• Lieferung einer maschinenlesbaren SBOM mit dem Gerät und Aktualisierung bei jedem Softwarestand,
• Sicherheitshinweise und VEX-Aussagen über einen festen Kanal, möglichst im CSAF-Format,
• Angaben zum Supportzeitraum für Sicherheitsupdates und zu deren Bereitstellung,
• das ausgefüllte MDS2-Formular und die Mindestanforderungen an die Netzumgebung,
• einen benannten Ansprechpartner für Sicherheitsfragen und Vorfälle.

Risiken jenseits des eigenen Codes

Lieferkettenangriffe wie der auf SolarWinds Orion Ende 2020 oder die Hintertür in XZ Utils im März 2024 zeigen, wie Schadcode über vertrauenswürdige Quellen eindringt. Gegenmittel sind überprüfbare Builds, signierte Artefakte, Herkunftsnachweise und sparsam gewählte Abhängigkeiten; einen gestuften Rahmen bietet Supply-chain Levels for Software Artifacts (SLSA), aktuell Version 1.2.

Quellen für das Lagebild

• Sicherheitshinweise der Gerätehersteller und der Komponentenlieferanten, idealerweise maschinenlesbar im CSAF-Format,
• der Warn- und Informationsdienst von CERT-Bund beim BSI,
• der Katalog Known Exploited Vulnerabilities (KEV) der US-Behörde CISA,
• der Austausch im Health-ISAC, dem internationalen Informationsverbund des Gesundheitssektors,
• eigene Erkenntnisse aus Netzüberwachung, Protokollen und Vorfällen.

Drei technische Signale

Die technische Einordnung stützt sich auf drei Signale: CVSS, seit November 2023 in Version 4.0, für die Schwere; EPSS für die täglich aktualisierte Prognose einer Ausnutzung in den nächsten 30 Tagen; den seit November 2021 geführten KEV-Katalog für nachgewiesene Angriffe.

Die klinischen Fragen

• Erreichbarkeit: Ist das Gerät aus dem Kliniknetz, aus Fernwartungszugängen oder gar aus dem Internet ansprechbar?
• Klinische Einbettung: Steuert oder überwacht es eine Therapie, liefert es Befunde, steht es am Patienten?
• Folgen einer Manipulation: Welche Auswirkung hätte ein Verlust von Integrität oder Verfügbarkeit auf Diagnose und Behandlung?
• Schutzmaßnahmen: Wirken Segmentierung, Zugriffsbeschränkungen oder Überwachung bereits nachweisbar?
• Herstelleraussage: Bestätigt eine VEX-Angabe die Betroffenheit, oder ist die Komponente nicht erreichbar?

Prioritätsklassen als gemeinsame Sprache

Hersteller und Kliniken profitieren von wenigen, klar beschriebenen Prioritätsklassen. Die folgende Einteilung ist ein Vorschlag; konkrete Reaktionszeiten legt jede Organisation produktspezifisch fest.

Riskant sind zwei Extreme: jedes verfügbare Update reflexhaft einzuspielen oder an Medizintechnik grundsätzlich nichts zu verändern. MDCG 2019-16 erwartet, dass Betreiber Patchprozesse haben, mit denen sicherheitsrelevante Updates zeitnah ausgerollt werden, und dass die Betriebsumgebung Updates ohne Kompatibilitätsverlust zulässt. Die Leitlinie sieht ausdrücklich vor, dass Updates auch außerhalb einer Sicherheitskorrekturmaßnahme im Feld bereitgestellt werden.

Der Weg vom Hinweis zum belegten Update

1. 1
   Betroffenheit feststellen

   Hinweis mit SBOM, Geräteinventar und VEX-Angaben abgleichen: Welche Geräte, Softwarestände und Standorte sind tatsächlich betroffen?

2. 2
   Bewerten und einstufen

   Technische Signale, klinische Einbettung und vorhandene Schutzmaßnahmen zusammenführen, Prioritätsklasse festlegen und Safety-Bezug dokumentieren.

3. 3
   Maßnahme wählen

   Update, Konfigurationsänderung oder Ersatzmaßnahme wie Segmentierung, Härtung, verstärkte Überwachung oder Nutzungsbeschränkung – abgestimmt mit den Vorgaben des Herstellers.

4. 4
   Testen und freigeben

   Der Hersteller verifiziert und validiert das Update; die Klinik prüft es in einer realitätsnahen Umgebung mit ihren Schnittstellen und gibt es nach festgelegten Kriterien frei.

5. 5
   Gestaffelt ausrollen

   Erst Pilotgeräte, dann die Flotte, in abgestimmten Wartungsfenstern und mit vorbereitetem Rückweg für den Fall von Störungen.

6. 6
   Verifizieren und dokumentieren

   Installationsstand prüfen, Funktion bestätigen, Restrisiko festhalten und Inventar, SBOM und Risikoakte aktualisieren.

Ersatzmaßnahmen werden genauso bewertet, freigegeben, befristet und überprüft wie ein Patch. Aus Sicht der MDR zählt der Nachweis, dass eine Entscheidung begründet, getestet und mit ihrem Restrisiko dokumentiert wurde – nicht allein die Installation.

Updates über das Netz (OTA)

Over-the-Air-Updates bringen Korrekturen schneller auf viele Geräte, schaffen aber ein Klumpenrisiko: Ein fehlerhaftes oder manipuliertes Paket erreicht im schlimmsten Fall die gesamte Flotte. Die Firmware-Update-Architektur der IETF, beschrieben in RFC 9019 vom April 2021, benennt die tragenden Prinzipien:

• ein signiertes Manifest, das Herkunft, Kompatibilität und Prüfsummen des Pakets beschreibt,
• die Prüfung von Echtheit und Integrität vor der Installation und erneut beim Start durch einen Bootloader mit Vertrauensanker (Secure Boot),
• ein Rückfall-Image in einem getrennten Speicherbereich (A/B-Prinzip), damit ein fehlgeschlagenes Update das Gerät nicht lahmlegt,
• einen Schutz vor Downgrades über Sequenznummern, damit Angreifer keine ältere, verwundbare, aber gültig signierte Version einspielen können,
• Robustheit gegen Stromausfall oder Verbindungsabbruch.

Rückfall-Image und Downgrade-Schutz lösen verschiedene Probleme: Das eine sichert die Verfügbarkeit, das andere verhindert einen Angriff. Hinzu kommen verschlüsselte Übertragung, gestaffelte Ausrollwellen und Telemetrie zur Erfolgsquote, im klinischen Betrieb außerdem abgestimmte Wartungsfenster und klare Information der Anwender. Verändert ein Update Sicherheits- oder Leistungsmerkmale wesentlich, kann je nach Klassifizierung eine erneute Bewertung unter Einbindung der Benannten Stelle nötig sein.

Vorbereitet auf den Zero-Day

Als Zero-Day gilt eine Schwachstelle, für die zum Zeitpunkt ihres Bekanntwerdens kein Patch bereitsteht. Für Medizinprodukte ist das besonders schwierig: Das Gerät soll weiter versorgen, ein freigegebenes Update fehlt, und eigenmächtige Eingriffe der Klinik sind ausgeschlossen. Bewährt haben sich vier Vorkehrungen:

• ein dokumentierter Eskalationspfad, der festlegt, wer in den ersten Stunden entscheidet – Produktverantwortung, Security, Klinik-IT, Medizintechnik und Regulatory Affairs,
• vorab abgestimmte Sofortmaßnahmen wie Netztrennung, Abschalten nicht benötigter Dienste und gezielte Überwachung auf Angriffsspuren,
• für sicherheitskritische Geräteklassen vorbereitete und klinisch geprüfte Ersatzkonfigurationen,
• Vorlagen für Sicherheitsmitteilungen an Anwender (Field Safety Notice), die technisch korrekt und klinisch verständlich sind.

Eine Sicherheitskorrekturmaßnahme im Feld (Field Safety Corrective Action) ist nach der MDR grundsätzlich vor ihrer Durchführung der Behörde zu melden; nur in dringenden Fällen darf die Meldung nachfolgen. Wird eine Lücke bereits aktiv ausgenutzt, verschärft sich die Lage zusätzlich – technisch wie regulatorisch.

Coordinated Vulnerability Disclosure

Viele Schwachstellen entdecken Forschende, Pentester, Integratoren oder Anwender. Ohne erkennbaren Meldeweg bleiben solche Hinweise liegen oder werden unkoordiniert öffentlich. Coordinated Vulnerability Disclosure (CVD) ordnet den Ablauf: Der Hinweis wird angenommen, geprüft, behoben und anschließend gemeinsam veröffentlicht. Den Rahmen setzen ISO/IEC 29147:2018 für Annahme und Veröffentlichung und ISO/IEC 30111:2019 für die interne Behandlung.

Was Kliniken prüfen sollten

Ohne funktionierenden CVD-Prozess lässt sich die Reaktionsfähigkeit eines Herstellers kaum abschätzen. Aussagekräftig sind eine veröffentlichte Richtlinie, ein erreichbares PSIRT und eine nachvollziehbare Historie von Sicherheitshinweisen.

Überwachung jenseits der Verfügbarkeit

Ein Monitoring, das nur prüft, ob ein Gerät erreichbar ist, erkennt keine Angriffe. Aussagekräftig sind ungewöhnliche Verbindungen, gehäufte fehlgeschlagene Anmeldungen, unerwartete Konfigurationsänderungen und verletzte Integritätsprüfungen. Weil auf vielen Medizinprodukten keine zusätzliche Software installiert werden darf, bietet sich eine passive Netzüberwachung in segmentierten Gerätezonen an.

Incident Response über Organisationsgrenzen

Aus Auffälligkeiten muss ein handlungsfähiger Ablauf werden – mit Rollen, Eskalationskriterien und Schnittstellen zu Medizintechnik, Klinikleitung, Datenschutz und Hersteller. MDCG 2019-16 erwartet ausdrücklich, dass Betreiber den Hersteller unverzüglich über jeden vermuteten Sicherheitsvorfall informieren. Beim Hersteller bündelt das PSIRT Analyse, Priorisierung und Behebung und begleitet die Kommunikation mit CERTs, Informationsverbünden und Behörden.

Vier Meldewege im Vergleich

Für die MDR-Vigilanz spielt es keine Rolle, ob ein Ereignis auf einen Angriff, eine Lücke oder einen Softwarefehler zurückgeht. Es kommt darauf an, ob das Produkt in Sicherheit oder Leistung beeinträchtigt war oder hätte sein können. Beispiele zur Abgrenzung von Vorkommnis und schwerwiegendem Vorkommnis enthält MDCG 2019-16; für die Kodierung bietet das International Medical Device Regulators Forum (IMDRF) Problemcodes wie „Software Security Vulnerability“. Bei Unsicherheit über die Meldepflicht ist fristgerecht zu melden, eine zunächst unvollständige Meldung ist zulässig.

Was der Revisionsvorschlag ändern würde

Die Kommission hat am 16. Dezember 2025 vorgeschlagen, MDR und IVDR zu überarbeiten. Hersteller sollen danach aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle innerhalb von 30 Tagen über die europäische Datenbank Eudamed an die zuständigen CSIRTs und an ENISA melden; zudem soll die allgemeine Vigilanzfrist für sonstige schwerwiegende Vorkommnisse von 15 auf 30 Tage steigen. Der Vorschlag ist noch nicht beschlossen. Bis dahin gelten die heutigen Fristen.

Marktüberwachung, Schwachstellenmanagement und Vorfallbehandlung brauchen einander: Neue Risiken werden nur sichtbar, wenn das Security-Lagebild in die Marktüberwachung einfließt; Prioritäten stimmen nur, wenn die Safety-Bewertung mitläuft; Fristen werden nur gehalten, wenn Regulatory Affairs früh eingebunden ist. Das Zielbild verbindet diese Stränge zu einem Kreislauf mit klaren Verantwortlichen.

Startplan für die ersten Monate

• Inventar und Verantwortliche: alle vernetzten Medizinprodukte mit Softwarestand, Netzanbindung, Hersteller-Kontakt und Supportende erfassen.
• Lücken bei Herstellerinformationen schließen: SBOM, MDS2, Sicherheitshinweise und Patchvorgaben anfordern und vertraglich verankern.
• Prioritätsklassen und interne Reaktionszeiten festlegen, die technische und klinische Kriterien verbinden.
• Änderungsprozess für Updates und Ersatzmaßnahmen mit Test-, Freigabe- und Dokumentationsschritten aufsetzen und mit den Instandhaltungs- und Prüfpflichten der Betreiberverordnung verzahnen.
• Meldematrix für MDR-Vigilanz, Anwendermeldung, BSI-Gesetz und Datenschutz mit Vorlagen, Zuständigkeiten und Vertretungen erstellen und üben.
• Kennzahlen einführen, etwa Anteil der Geräte mit aktueller SBOM, Durchlaufzeit je Prioritätsklasse und Anzahl befristeter Ersatzmaßnahmen.

Wer diese Bausteine früh verbindet, reagiert schneller, kann Entscheidungen belegen und stärkt das Vertrauen in digitale Medizintechnik. Ein sicher entwickeltes Gerät bleibt nur dann sicher, wenn es im Feld ebenso sorgfältig instand gehalten wird.

Die Hinweise auf dieser Seite ersetzen keine Rechtsberatung. Welche Pflichten im Einzelfall gelten, hängt von Klassifizierung, Rolle und Größe der Organisation ab.