MDR · IVDR · MDCG 2019-16 rev.1
Verankern Sie Cybersicherheit als Produkteigenschaft des Medizinprodukts
Konformität wird nicht durch einen einzigen Penetrationstest nachgewiesen. Der Hersteller muss Architektur, Bedrohungen, Patientenrisiken, Risikokontrollmaßnahmen, Verifizierung, Anwenderinformationen und den Umgang mit Schwachstellen über den gesamten unterstützten Lebenszyklus verknüpfen.
Regulatorische Grundlage
Beginnen Sie mit den Produktanforderungen, nicht mit einer Prüfliste
MDCG 2019-16 rev.1 schafft kein gesondertes Zertifizierungsverfahren. Der Leitfaden erläutert, wie die cybersicherheitsbezogenen Anforderungen aus Anhang I der MDR und IVDR mit technischer Dokumentation, PMS und Vigilanz verknüpft werden.
Verordnung (EU) 2017/745
Medizinprodukte
- 17.2
- Entwicklungslebenszyklus, Risikomanagement einschließlich Informationssicherheit, Verifizierung und Validierung
- 17.4
- Mindestanforderungen an Hardware, IT-Netze und IT-Sicherheitsmaßnahmen, die für den bestimmungsgemäßen Betrieb der Software erforderlich sind
- 23.4
- Informationen für die sichere Anwendung einschließlich Anforderungen an die IT-Umgebung und Sicherheitsmaßnahmen
Verordnung (EU) 2017/746
In-vitro-Diagnostika
- 16.2
- Entwicklungslebenszyklus, Risikomanagement einschließlich Informationssicherheit, Verifizierung und Validierung
- 16.4
- Mindestanforderungen an Hardware, IT-Netze und IT-Sicherheitsmaßnahmen, die für den bestimmungsgemäßen Betrieb der Software erforderlich sind
- 20.4.1
- Informationen in der Gebrauchsanweisung einschließlich Anforderungen an die IT-Umgebung und Sicherheitsmaßnahmen
Konformitätsmodell
Steuern Sie die Sicherheit während des gesamten unterstützten Lebenszyklus
Bedrohungen und Schwachstellen ändern sich schneller als die grundlegende Produktkonstruktion. Eine Sicherheitsbewertung bleibt daher nur belastbar, wenn der Hersteller nach der Freigabe wirksame Prozesse für Überwachung, Bewertung und rechtzeitige Behebung betreibt.
-
01
Kontext definieren
Architektur, Schutzgüter, Daten, Anwender, klinische Funktionen, Schnittstellen, Betriebsumgebung und Unterstützungsdauer.
-
02
Bedrohungen modellieren
Vertrauensgrenzen, Angriffsflächen, vorhersehbare Szenarien, Ausnutzbarkeit und mögliche Auswirkungen auf Patienten.
-
03
Risiken konstruktiv reduzieren
Minimale Berechtigungen, Authentifizierung, Segmentierung, Datenschutz, Protokollierung, Resilienz und sichere Aktualisierung.
-
04
Komponenten kontrollieren
Software Dritter und Open-Source-Software, Versionsherkunft, bekannte Schwachstellen, SBOM und gelenkter Austausch.
-
05
Umsetzung verifizieren
Codeanalyse, Scans, Fuzzing, Prüfung von Schnittstellen und Updates, Penetrationstests und Prüfung des Restrisikos.
-
06
Sicherheit aufrechterhalten
Bedrohungsmonitoring, Annahme von Meldungen, Schwachstellenbewertung, Patches, Kommunikation, CAPA, PMS und erforderlichenfalls Vigilanz oder FSCA.
Technische Dokumentation
Zeigen Sie den rückverfolgbaren Weg von der Bedrohung zur verifizierten Kontrolle
Ein eigenständiger Cybersicherheitsbericht kann hilfreich sein, reicht aber nicht aus. Die Nachweise müssen mit Zweckbestimmung, Architektur, Softwareanforderungen, Risikomanagement, Verifizierung, Gebrauchsanweisung, PMS und der tatsächlich freigegebenen Konfiguration übereinstimmen.
Cybersicherheitsplan
Rollen, Prozesse, Kriterien, Methoden, Werkzeuge, Lieferanten, Änderungskontrolle und Tätigkeiten nach der Freigabe.
Architektur und Datenflüsse
Komponenten, Vertrauensgrenzen, Schnittstellen, Protokolle, Ports, externe Dienste, Cloud-Umgebung und Updates.
Bedrohungsmodell und Risikobewertung
Schutzgüter, Angriffsszenarien, Schwachstellen, Ausnutzbarkeit, Schaden, Kontrollen und Restrisiko.
Komponenten und SBOM
Identifizierung von Drittkomponenten, Versionen, Lizenzen, Quellen, bekannte Schwachstellen und Unterstützungsstatus.
Verifizierungs- und Validierungsberichte
Begründeter Methodenumfang, Annahmekriterien, Ergebnisse, ungelöste Anomalien und Regressionstests nach Änderungen.
Informationen für den sicheren Betrieb
Unterstützte Umgebung, Konfiguration, Netzanforderungen, Zugriffsrollen, Sicherung, Protokollierung und Installation von Updates.
Plan für das Schwachstellenmanagement
Meldekanal, Triage, Fristen, koordinierte Offenlegung, Sofortmaßnahmen, Patches und Anwenderkommunikation.
PMS- und Vigilanzaufzeichnungen
Signale, Trends, Vorkommnisse, Korrekturmaßnahmen, Risikoaktualisierungen und Auswirkungen auf die klinische Bewertung oder Leistungsbewertung.
Betriebsumgebung
Verteilen Sie Tätigkeiten, nicht die Verantwortung des Herstellers
Die Sicherheit eines vernetzten Produkts hängt von Hersteller, Integrator, Gesundheitseinrichtung und Anwender ab. Der Hersteller muss angemessene Annahmen zur Umgebung definieren und relevante Informationen bereitstellen. Risiken, die durch die Produktkonstruktion zu reduzieren sind, kann er jedoch nicht auf den Betreiber übertragen.
Sicheres Produkt und unterstützter Lebenszyklus
- Definiert Sicherheitskontext und Anforderungen
- Implementiert und verifiziert Kontrollen
- Pflegt Komponenten und behebt Schwachstellen
- Stellt Informationen bereit und aktualisiert die Dokumentation
Gelenkte Installation und Konfiguration
- Befolgt die Anforderungen des Herstellers
- Prüft Schnittstellen und Kompatibilität
- Dokumentiert Konfiguration und Änderungen
- Übermittelt Informationen zu festgestellten Problemen
Geschützte Infrastruktur und Betrieb
- Segmentiert Netze und steuert Zugriffe
- Betreibt Sicherungs- und Wiederherstellungsprozesse
- Installiert abgestimmte Aktualisierungen
- Reagiert auf Ereignisse und informiert den Hersteller
Anwendung in der festgelegten Umgebung
- Befolgt Anweisungen und Einschränkungen
- Schützt Zugangsdaten und physischen Zugriff
- Deaktiviert vorgesehene Schutzmaßnahmen nicht
- Meldet Ausfälle und verdächtige Ereignisse
Nach dem Inverkehrbringen
Setzen Sie eine Schwachstelle nicht automatisch mit einem schwerwiegenden Vorkommnis gleich
Ein eingehendes Signal erfordert zunächst eine technische und klinische Bewertung. Auch wenn keine Vigilanzmeldung erforderlich ist, müssen Entscheidung und Maßnahmen in PMS, Risikomanagement und CAPA rückverfolgbar bleiben.
-
01
Signal annehmen und sichern
Forschende, Anwender, Lieferanten, Veröffentlichungen, Schwachstellendatenbanken, Beschwerden oder internes Monitoring.
-
02
Betroffene Konfiguration bestätigen
Versionen, Komponenten, Betriebsbedingungen, Zugänglichkeit des Angriffs und Hinweise auf bekannte Ausnutzung.
-
03
Patientensicherheit bewerten
Auswirkungen auf Leistung, diagnostische oder therapeutische Entscheidungen, Verfügbarkeit und möglichen Schaden.
-
04
Regulatorische Maßnahmen bestimmen
Reguläre Behebung, Sofortmaßnahme, Anwenderinformation, schwerwiegendes Vorkommnis, FSCA, Trend- oder sonstige Meldung.
-
05
Beheben und Rückkopplung schließen
Patch oder kompensierende Maßnahme, V&V, gelenkte Bereitstellung sowie Aktualisierung von Risiken, PMS und Dokumentation.
Veröffentlichen Sie einen eindeutigen Meldekanal, bestätigen Sie den Eingang, schützen Sie sensible Informationen, stimmen Sie Fristen für Behebung und Kommunikation ab und verzögern Sie keine Maßnahmen, die zur Risikominderung erforderlich sind.
Benachbartes EU-Recht
Trennen Sie Produktkonformität und Pflichten der Organisation
MDR oder IVDR bleiben die Grundlage der CE-Kennzeichnung des Medizinprodukts. Andere Rechtsakte können parallel auf Daten, den Hersteller, eine Gesundheitseinrichtung, ein KI-System oder ein eigenständiges digitales Produkt anwendbar sein.
Cyber Resilience Act
Die Verordnung (EU) 2024/2847 gilt nicht für Produkte mit digitalen Elementen, die in den Anwendungsbereich der MDR oder IVDR fallen. Eigenständige Komponenten oder Plattformen außerhalb dieses Anwendungsbereichs sind gesondert zu bewerten.
NIS2
Die Richtlinie (EU) 2022/2555 erfasst bestimmte Hersteller von Medizinprodukten und IVD. Die Anwendbarkeit hängt von Kategorie und Größe der Einrichtung sowie vom nationalen Recht des Mitgliedstaats ab.
DSGVO
Datenschutz ersetzt nicht die Produktsicherheit. Rollen, Rechtsgrundlagen, Datenminimierung, Betroffenenrechte, Sicherheit der Verarbeitung und Pflichten bei Datenschutzverletzungen sind gesondert zu bestimmen.
Verordnung über künstliche Intelligenz
Bewerten Sie bei KI-gestützten Funktionen zusätzlich die Einstufung des Systems, Pflichten der Akteure, Datenqualität, menschliche Aufsicht, Robustheit und das Zusammenspiel mit dem Konformitätsbewertungsverfahren.
Primärquellen und Normen
Begründen Sie den Stand der Technik für das konkrete Produkt
Eine Norm oder ein Leitfaden sollte nicht mechanisch angewendet werden. Bestimmen Sie Anwendbarkeit, Ausgabe und Rolle jedes Dokuments und prüfen Sie den aktuellen Harmonisierungsstatus, bevor Sie eine Konformitätsvermutung geltend machen.
MDCG 2019-16 rev.1
Zentraler EU-Leitfaden zur Cybersicherheit von Medizinprodukten
Verordnung (EU) 2017/745
Offizieller MDR-Text auf EUR-Lex
Verordnung (EU) 2017/746
Offizieller IVDR-Text auf EUR-Lex
IEC 81001-5-1:2021
Sicherheitsaktivitäten im Produktlebenszyklus von Gesundheitssoftware
ISO 14971:2019
Risikomanagement für Medizinprodukte
IMDRF N73
Grundsätze und Praxis für SBOMs zur Cybersicherheit von Medizinprodukten
Häufig gestellte Fragen
Praktische Grenzen der Anforderungen
Der Arbeitsumfang hängt von Architektur, vorgesehener Betriebsumgebung, klinischer Funktion, unterstützter Lebensdauer und den Folgen eines Verlusts von Vertraulichkeit, Integrität oder Verfügbarkeit ab.
Gelten die Anforderungen nur für vernetzte Produkte?
Nein. Auch ein eigenständiges Produkt kann anfällige lokale Schnittstellen, Wechseldatenträger, Servicezugänge, Aktualisierungsmechanismen oder Komponenten Dritter enthalten. Die Bewertung muss die tatsächliche Architektur und vorhersehbare Angriffswege berücksichtigen.
Reicht ein Penetrationstest aus?
Nein. Er ist eine Verifizierungsmethode. Er ersetzt weder Bedrohungsmodellierung, Risikomanagement, sichere Architektur, Komponentenkontrolle und anforderungsbasierte Prüfung noch Anwenderinformationen und Prozesse nach dem Inverkehrbringen.
Ist eine SBOM verpflichtend?
MDR und IVDR schreiben kein einheitliches SBOM-Format vor. MDCG 2019-16 rev.1 nennt sie jedoch als relevante Information. Die Identifizierung von Komponenten Dritter ist erforderlich, um bekannte Schwachstellen zu überwachen und den Stand der Technik aufrechtzuerhalten.
Muss jede Schwachstelle gemeldet werden?
Nicht automatisch über das Vigilanzsystem. Jede Schwachstelle erfordert eine dokumentierte Bewertung der Ausnutzbarkeit und des möglichen Schadens. Die Meldepflicht hängt von den anwendbaren Definitionen eines Vorkommnisses, eines schwerwiegenden Vorkommnisses, einer Gefahr für die öffentliche Gesundheit und der Notwendigkeit einer FSCA ab.
Gilt der Cyber Resilience Act für ein MDR- oder IVDR-Produkt?
Nein. Produkte mit digitalen Elementen, die in den Anwendungsbereich der MDR oder IVDR fallen, sind vom Cyber Resilience Act ausgenommen. Eigenständige Produkte oder Komponenten außerhalb dieses Bereichs müssen gesondert bewertet werden.