Wie weisen Hersteller die Cybersecurity ihrer Medizinprodukte über den gesamten Produktlebenszyklus belastbar nach?
Wir begleiten Hersteller vernetzter und softwarebasierter Medizinprodukte beim Aufbau eines durchgängigen Cybersecurity-Nachweises: von Threat Modeling und Secure Development Lifecycle über die Software-Stückliste (SBOM) bis zum Schwachstellen-Monitoring nach Markteinführung. Cybersecurity ist unter der Medical Device Regulation (EU) 2017/745 keine separate Disziplin, sondern Teil der grundlegenden Sicherheits- und Leistungsanforderungen. Der eigentliche Engpass ist, dass dieselbe Bedrohungsanalyse das Risikomanagement, die Technische Dokumentation und das Post-Market-System speisen muss, statt als isoliertes Dokument zu existieren.
- MedTech
- IVD
Überblick
Welche Cybersecurity-Anforderungen stellen MDR und FDA an Hersteller?
Cybersecurity über den gesamten Lebenszyklus · MDR (EU 2017/745), MDCG 2019-16, IEC 81001-5-1, IEC 62304
Zuletzt aktualisiert: 2026-06-13
Vernetzte und softwarebasierte Medizinprodukte sind Angriffsfläche und reguliertes Produkt zugleich. Die Anforderungen verteilen sich auf mehrere Regelwerke, die denselben Nachweis aus unterschiedlichen Blickwinkeln verlangen. Die Hebel, an denen die Nachweisführung am häufigsten hängenbleibt:
- Die MDR (EU 2017/745) behandelt IT-Sicherheit nicht separat: Anhang I fordert für programmierbare elektronische Systeme Entwicklung nach dem Stand der Technik inklusive Schutz gegen unbefugten Zugriff. Cybersecurity ist damit Teil der grundlegenden Sicherheits- und Leistungsanforderungen, nicht ein Zusatzdokument.
- Die MDCG-2019-16-Leitlinie konkretisiert, wie diese GSPR für die Benannte Stelle nachgewiesen werden: Bedrohungsanalyse, Security-Anforderungen, Verifizierung und ein Plan für die Phase nach Markteinführung gehören in die Technische Dokumentation.
- Cybersecurity und Risikomanagement nach ISO 14971 müssen verzahnt sein: Security-Risiken, die zu Patientenschäden führen können, fließen in die produktbezogene Risikoanalyse ein. AAMI TIR57 beschreibt die Brücke zwischen Security- und Safety-Risikomanagement.
- Für den US-Markt verlangt der FD&C Act Section 524B für Cyber Devices unter anderem einen Plan zum Umgang mit Schwachstellen nach Markteinführung sowie eine Software-Stückliste (SBOM). Eine Premarket-Submission ohne diese Elemente weist die FDA seit Oktober 2023 als unvollständig zurück (Refuse to Accept).
- Der Secure Development Lifecycle nach IEC 81001-5-1 und der Software-Lebenszyklus nach IEC 62304 müssen ineinandergreifen, damit Security-Aktivitäten an die ohnehin geforderte Software-Dokumentation andocken statt parallel zu laufen.
Leistungen
Wie wir Sie unterstützen
Threat Modeling & Security-Risikoanalyse
Systematische Bedrohungsanalyse des Produkts und seiner Schnittstellen, dokumentiert als nachvollziehbares Threat Model, das in das Risikomanagement nach ISO 14971 und die GSPR-Nachweise der MDR einzahlt und die Grundlage für jeden weiteren Cybersecurity-Nachweis bildet.
Secure Development Lifecycle
Aufbau eines Security-Lebenszyklus nach IEC 81001-5-1, verzahnt mit dem Software-Lebenszyklus nach IEC 62304, mit definierten Security-Anforderungen, Design-Maßnahmen und Verifizierungsnachweisen für die Technische Dokumentation.
Mehr erfahren →SBOM-Management
Erstellung und Pflege einer Software-Stückliste (Software Bill of Materials), die alle Komponenten inklusive Open-Source- und Drittanbieter-Bibliotheken erfasst, als Basis für das Schwachstellen-Monitoring und als Pflichtbestandteil der FDA-Submission nach Section 524B.
Post-Market Cybersecurity
Aufbau eines Prozesses zum Monitoring neuer Schwachstellen, zur Bewertung ihrer Auswirkung auf das eigene Produkt und zur koordinierten Behebung, mit Anbindung an Post-Market Surveillance und das Meldewesen nach MDR.
Mehr erfahren →Technische Dokumentation Cybersecurity
Zusammenführung von Threat Model, Security-Anforderungen, Verifizierungsnachweisen und Post-Market-Plan zu einem nach MDCG 2019-16 prüffähigen Cybersecurity-Dossier als Teil der Technischen Dokumentation.
Gap-Analyse & Audit-Vorbereitung
Soll-Ist-Abgleich des bestehenden Security-Nachweises gegen MDR-GSPR, MDCG 2019-16 und die FDA-Anforderungen, mit priorisierter Maßnahmenliste vor dem Audit der Benannten Stelle oder der FDA-Einreichung.
Wie wir zusammenarbeiten
Worauf es ankommt
Cybersecurity bei Medizinprodukten scheitert selten an einer einzelnen Maßnahme, sondern an der Reihenfolge und der fehlenden Verzahnung. Den Ausgangspunkt bildet das Threat Model: Wer Bedrohungen und Angriffsvektoren nicht früh systematisch erfasst, leitet später Security-Anforderungen aus dem Bauchgefühl ab statt aus einer nachvollziehbaren Analyse. Aus dem Threat Model fließen zwei Stränge: die Security-Risiken in das Risikomanagement nach ISO 14971, über die Brücke, die AAMI TIR57 beschreibt, und die Security-Anforderungen in den Entwicklungsprozess. Beide müssen aus derselben Quelle stammen, sonst entstehen die Widersprüche zwischen Cybersecurity-Akte und Risikoanalyse, die im Audit der Benannten Stelle als Erstes auffallen.
Der zweite Engpass liegt nach der Markteinführung. Die SBOM ist kein Einreichungsdokument, sondern ein lebendes Register: Erst der laufende Abgleich gegen neu bekannt gewordene Schwachstellen macht aus ihr den Nachweis, den der FD&C Act Section 524B und MDCG 2019-16 verlangen. Deshalb planen wir den Post-Market-Prozess bereits, wenn die Technische Dokumentation entsteht, und binden ihn an die Post-Market Surveillance und das Meldewesen nach der MDR (EU 2017/745) an. So wird Cybersecurity vom Zusatzkapitel zu einem Strang, der dieselben Nachweise speist, die das Produkt ohnehin erbringen muss.
Unser Vorgehen
Unser Vorgehen
Schritt
Ergebnis
Scoping & Gap-Analyse
Bestandsaufnahme von Architektur, Schnittstellen und vorhandener Dokumentation; priorisierte Lückenliste gegen MDR-GSPR, MDCG 2019-16 und FDA-Anforderungen.
Threat Modeling
Dokumentiertes Threat Model mit identifizierten Bedrohungen, Angriffsvektoren und abgeleiteten Security-Anforderungen.
Security-Risikobewertung
Security-Risiken bewertet und in das Risikomanagement nach ISO 14971 überführt, Brücke zwischen Security und Safety nach AAMI TIR57 hergestellt.
SBOM & Security-Maßnahmen
Gepflegte Software-Stückliste, umgesetzte Design- und Verifizierungsmaßnahmen entlang IEC 81001-5-1 und IEC 62304.
Cybersecurity-Dossier
Prüffähige Cybersecurity-Dokumentation nach MDCG 2019-16 als Teil der Technischen Dokumentation, vorbereitet für Benannte Stelle bzw. FDA.
Post-Market-Betrieb
Etablierter Prozess für Schwachstellen-Monitoring und koordinierte Behebung, angebunden an Post-Market Surveillance und Meldewesen.
Typische Stolperfallen
Woran Projekte häufig scheitern
Cybersecurity wird als eigenständiges Dokument neben dem Risikomanagement geführt.
Security-Risiken, die zu Patientenschäden führen können, müssen nach AAMI TIR57 in die produktbezogene Risikoanalyse nach ISO 14971 einfließen. Eine getrennte Akte erzeugt Widersprüche, die im Audit der Benannten Stelle auffallen.
Die SBOM wird einmalig zur Einreichung erstellt und danach nicht gepflegt.
Eine Software-Stückliste hat nur dann Wert, wenn sie laufend gegen neue Schwachstellen abgeglichen wird; eine veraltete SBOM erfüllt weder den Zweck nach FD&C Act Section 524B noch das Post-Market-Monitoring nach MDCG 2019-16.
Der Post-Market-Teil der Cybersecurity wird erst nach Markteinführung geplant.
MDCG 2019-16 und Section 524B verlangen bereits vor der Einreichung einen Plan für den Umgang mit Schwachstellen nach Markteinführung. Wer ihn nachreicht, riskiert Nachforderungen statt einer geraden Zulassung.
Open-Source- und Drittanbieter-Komponenten werden nicht systematisch erfasst.
Gerade diese Komponenten sind eine häufige Quelle bekannt gewordener Schwachstellen; ohne vollständige SBOM lässt sich nach einem Sicherheitshinweis nicht belegen, ob das eigene Produkt betroffen ist.
Der Security-Lebenszyklus läuft parallel zum Software-Lebenszyklus nach IEC 62304 statt verzahnt mit ihm.
Werden Security-Anforderungen nicht an die ohnehin geforderten Software-Anforderungen und -Tests gekoppelt, entstehen doppelte Dokumentation und Lücken in der Verifizierung.
FAQ
Häufige Fragen
Quellen
- Verordnung (EU) 2017/745 (MDR), Primärtext, Anhang I (GSPR, programmierbare elektronische Systeme)
- Verordnung (EU) 2017/746 (IVDR), Primärtext, grundlegende Sicherheits- und Leistungsanforderungen
- MDCG 2019-16, Guidance on Cybersecurity for medical devices
- IEC 81001-5-1, IEC 62304, IEC 62443, ISO 14971, AAMI TIR57
- FD&C Act Section 524B (Ensuring Cybersecurity of Devices)
- https://theentourage.de/clinical-medical-affairs/cybersecurity-embedded-systems/ (bestehender Seiteninhalt, überarbeitet)
Life Science Journal
Regulatorische Updates, direkt ins Postfach.
Neue Anforderungen, Behördenentscheidungen und Praxishinweise. Einmal monatlich, jederzeit abbestellbar.
Referenzprojekte
Wie das in der Praxis aussieht
Passende Insights
Alle Insights →Berücksichtigte Verordnungen & Normen
- EU 2017/745 (MDR)
- MDR Anhang I (Grundlegende Sicherheits- und Leistungsanforderungen, GSPR)
- EU 2017/746 (IVDR)
- MDCG 2019-16 (Guidance on Cybersecurity for medical devices)
- IEC 81001-5-1 (Security im Lebenszyklus von Health Software)
- IEC 62304 (Software-Lebenszyklus für Medizinprodukte)
- IEC 62443 (Security für industrielle Automatisierungs- und Steuerungssysteme)
- ISO 14971 (Risikomanagement)
- AAMI TIR57 (Principles for medical device security, risk management)
- FD&C Act Section 524B (Cyber Devices, USA)
Angrenzende Themen
Risikomanagement →
Security-Risiken in die Risikoanalyse nach ISO 14971 überführen
Design Controls →
Security-Anforderungen im Entwicklungsprozess verankern
Post-Market Surveillance →
Schwachstellen-Monitoring an PMS und Meldewesen anbinden
MDR Consulting →
Cybersecurity als Teil der GSPR-Nachweise nach EU 2017/745
Dazu ein konkretes Vorhaben?
Schildern Sie uns kurz Ihre Ausgangslage. Wir melden uns mit einer ersten Einschätzung, in der Regel innerhalb eines Werktags.
Lieber direkt? +49 89 4161170-0
info@theentourage.de
- Antwort i.d.R. innerhalb eines Werktags
- 4 Standorte: DE · CH · IT · US
- 100% Life Sciences