Freelance Cybersecurity-Experte Medizinprodukte (IEC 81001-5-1, FDA)

Aufgaben und Anforderungen im Überblick

Typische Projektanlässe

• FDA-Einreichung eines Cyber Device mit Nachforderung zur Cybersecurity
• Nichtkonformität der Benannten Stelle zu Security-Nachweisen unter MDR
• Neues vernetztes Produkt mit App- oder Cloud-Anbindung
• Kritische Schwachstelle in einer Drittkomponente mit Bewertungs- und Patchbedarf
• Aufbau eines Product Security Incident Response Team (PSIRT)
• Anpassung an die FDA-Guidance nach QMSR-Umstellung 2026

Was ein Cybersecurity-Experte für Medizinprodukte im Projekt leistet

Cybersecurity bei Medizinprodukten ist Produktsicherheit, nicht Unternehmens-IT. Es geht darum, dass ein Infusionssystem, ein Patientenmonitor, ein Implantat mit Funkschnittstelle oder eine Diagnose-App auch unter Angriffsbedingungen sicher funktioniert und vertrauliche Gesundheitsdaten geschützt bleiben. Die MDR fordert in Anhang I Abschnitt 17 ausdrücklich, dass Software und Geräte mit Software nach dem Stand der Technik unter Berücksichtigung der IT-Sicherheit entwickelt werden, einschließlich Schutz gegen unbefugten Zugriff.

Als Freelancer übernehmen Sie typischerweise die Rolle des Product Security Engineers oder Security-Architekten im Entwicklungsprojekt. Sie definieren Security-Anforderungen, führen Threat Modeling durch, bewerten Architekturen, begleiten Security-Tests und erstellen die regulatorische Dokumentation. Schnittstellen bestehen zur Software- und Hardwareentwicklung, zum Risikomanagement, zu Regulatory Affairs, zu V&V, zu externen Penetrationstestern und nach Markteinführung zu PMS und Vigilanz.

Eine besondere Herausforderung ist die Verbindung zwischen Security-Risiko und Sicherheitsrisiko im Sinne von ISO 14971. Eine ausgenutzte Schwachstelle kann zu einer Gefährdung für Patienten führen, muss aber methodisch anders bewertet werden, weil Eintrittswahrscheinlichkeiten von Angriffen sich nicht wie Ausfallraten schätzen lassen. Erfahrene Experten etablieren getrennte, aber verknüpfte Analysen – genau das erwarten Benannte Stellen und die FDA.

Typische Security-Projekte und Deliverables

Projekte reichen vom Aufbau eines Security-Prozesses bis zur Unterstützung einer konkreten Einreichung. Typische Deliverables sind:

• Secure Product Development Framework (SPDF): Prozessbeschreibung nach IEC 81001-5-1 mit Rollen, Aktivitäten je Phase, Security-Reviews und Freigabekriterien
• Threat Model: Systemdiagramm mit Vertrauensgrenzen, Datenflüssen, Angriffsflächen und identifizierten Bedrohungen
• Security-Risikoanalyse: Bewertung nach Ausnutzbarkeit und Auswirkung, etwa mit CVSS, Verknüpfung mit der Gefährdungsanalyse
• Security-Architektur und -Anforderungen: Authentisierung, Autorisierung, Verschlüsselung, sicheres Update, Logging, Härtung
• SBOM: maschinenlesbare Liste aller Softwarekomponenten mit Versionen, Supportstatus und bekannter Schwachstellenlage
• Security-Testplan und -Berichte: Penetrationstests, Fuzzing, statische und dynamische Analyse, Bewertung der Ergebnisse
• Begleitdokumentation: Security-Informationen für Betreiber, etwa nach dem MDS2-Formular, Hinweise zur Netzwerkintegration
• Postmarket-Plan: Schwachstellenüberwachung, Coordinated Vulnerability Disclosure, Patch-Prozess, Kommunikation mit Betreibern und Behörden

Bei bestehenden Produkten ist die nachträgliche Security-Bewertung häufig: Architektur und Software werden analysiert, ein Threat Model rekonstruiert und Maßnahmen priorisiert. Gerade Legacy-Geräte mit veralteten Betriebssystemen oder fest eingebauten Zugangsdaten erfordern pragmatische Lösungen, etwa kompensierende Maßnahmen auf Netzwerkebene und klare Betreiberhinweise.

Wo Einreichungen typischerweise hängen bleiben

• Das Threat Model beschreibt nur das Gerät, nicht aber App, Cloud-Backend, Service-Zugänge und Update-Infrastruktur.
• Die SBOM ist vorhanden, aber ohne Bewertung, ob bekannte Schwachstellen im konkreten Produktkontext ausnutzbar sind.
• Penetrationstests wurden durchgeführt, die Befunde sind aber nicht mit Risikobewertung und Maßnahmen verknüpft.
• Es fehlt ein belastbarer Plan, wie Patches nach Markteinführung bereitgestellt und validiert werden.

Solche Lücken führen bei der FDA zu Nachforderungen und bei Benannten Stellen zu Nichtkonformitäten. Ein strukturierter Abgleich gegen die Gliederung der FDA-Guidance und gegen MDCG 2019-16 vor der Einreichung spart erfahrungsgemäß deutlich Zeit.

Normen, Leitlinien und FDA-Anforderungen zur Cybersecurity

In der EU ist MDCG 2019-16 die zentrale Leitlinie zur Cybersecurity unter MDR und IVDR. Als Stand der Technik für den Security-Lebenszyklus gilt IEC 81001-5-1, die als EN IEC 81001-5-1 zur Harmonisierung unter der MDR vorgesehen ist. In den USA verlangt Section 524B des Federal Food, Drug, and Cosmetic Act für Cyber Devices unter anderem SBOM, einen Plan zur Schwachstellenbehandlung und ein Secure Product Development Framework. Die FDA hat ihre Premarket-Cybersecurity-Guidance im Juni 2025 final veröffentlicht und am 3. Februar 2026 an die QMSR angepasst, ohne neue technische Anforderungen einzuführen.

Der Cyber Resilience Act (EU) 2024/2847 nimmt Produkte, die unter die MDR oder IVDR fallen, aus seinem Anwendungsbereich aus. Er kann aber für Zubehör ohne Medizinproduktestatus oder für Wellness-Produkte desselben Herstellers relevant werden. Für KI-basierte Medizinprodukte verlangt zudem die KI-Verordnung Robustheit und Cybersecurity; die Pflichten für Hochrisiko-KI in Medizinprodukten gelten nach der Digital-Omnibus-Verordnung ab dem 2. August 2028.

Qualifikation und Erfahrung für Cybersecurity-Projekte

Auftraggeber suchen Fachleute, die tiefe Security-Kenntnisse mit Verständnis für regulierte Produktentwicklung verbinden. Typisch sind ein Studium in Informatik, IT-Sicherheit oder Elektrotechnik und mehrere Jahre Erfahrung in Produkt-Security. Erfahrung aus Automotive (ISO/SAE 21434), Industrieautomation (IEC 62443) oder Luftfahrt wird häufig anerkannt, weil Methodik und Denkweise ähnlich sind.

Häufig gefragt:

• Threat Modeling für vernetzte Systeme mit Gerät, App, Cloud und Krankenhausnetz
• Kenntnis von Embedded-Security wie Secure Boot, Code Signing, sicheren Updates und Schlüsselverwaltung
• Erfahrung mit SBOM-Werkzeugen und Schwachstellendatenbanken, Bewertung mit CVSS
• Fähigkeit, Ergebnisse von Penetrationstests zu bewerten und in Risiko und Maßnahmen zu übersetzen
• Regulatorisches Verständnis für MDR, MDCG 2019-16 und FDA-Anforderungen
• Kommunikationsstärke gegenüber Entwicklung, Management und Auditoren

Zertifizierungen wie CISSP, CSSLP, OSCP oder GICSP sind in diesem Feld verbreitet und werden gern gesehen. Sie ersetzen aber keine Erfahrung mit der Einreichung bei Benannten Stellen oder der FDA – diese ist für Auftraggeber oft das entscheidende Kriterium.

Stundensatz und Konditionen für Medical Device Security

Cybersecurity gehört zu den höher vergüteten Rollen in der Medizintechnik. Als Orientierung liegen Stundensätze erfahrener Freelancer zwischen 95 und 130 Euro netto pro Stunde ohne Reisekosten. Diese Spanne ist eine Einschätzung aus der Projektpraxis und keine Marktstatistik.

In den oberen Bereich führen Erfahrung mit FDA-Einreichungen von Cyber Devices, Architekturverantwortung für komplexe vernetzte Systeme, Embedded-Security-Kompetenz und kurzfristige Einsätze bei Nachforderungen oder kritischen Schwachstellen. In den unteren Bereich führen reine Dokumentationsaufgaben, standardisierte SBOM-Pflege oder lange Mandate mit voller Auslastung.

Bei Postmarket-Mandaten, etwa Bereitschaft für Schwachstellenmeldungen, sind Rahmenverträge mit festem Monatskontingent und definierter Reaktionszeit verbreitet. Klären Sie dann, wie Einsätze außerhalb der üblichen Arbeitszeiten vergütet werden.

Remote-Arbeit in Medical Device Cybersecurity

Die Rolle lässt sich überwiegend remote ausüben. Threat Modeling, Architekturbewertung, Dokumentation, SBOM-Pflege und die Bewertung von Testergebnissen erfolgen digital. Workshops mit Entwicklungsteams funktionieren gut per Video, wenn Architekturdiagramme vorab geteilt werden.

Präsenz ist sinnvoll für Kick-off-Workshops, für hardwarenahe Analysen wie die Prüfung von Debug-Schnittstellen oder Funkprotokollen und für Abstimmungen mit Betreibern. Manche Auftraggeber verlangen aus Vertraulichkeitsgründen, dass Quellcode und Architekturunterlagen nur in eigenen Umgebungen eingesehen werden. Rechnen Sie mit wenigen Präsenztagen pro Quartal, bei Embedded-Projekten mit etwas mehr.

Vertragsmodelle für Cybersecurity-Experten

Cybersecurity-Leistungen werden sowohl als laufende Unterstützung im Dienstvertrag als auch als klar abgegrenzte Pakete vergeben, etwa ein Threat Model mit Bericht, ein Security-Gap-Assessment oder die Erstellung der Einreichungsdokumentation. Für Pakete eignet sich eine direkte Beauftragung als Freiberufler oder über eine eigene GmbH; größere Hersteller beauftragen häufig über Personaldienstleister oder Security-Beratungen, für die Sie als Unterauftragnehmer tätig sind.

Bei Penetrationstests sind schriftliche Beauftragung, Testumfang und Haftungsregelungen besonders wichtig, weil Tests in Systeme eingreifen. Arbeitnehmerüberlassung ist in dieser Rolle eher selten. Eine Berufs- und Vermögensschadenhaftpflicht mit Deckung für IT-Security-Tätigkeiten ist für Freelancer sinnvoll. Diese Hinweise sind allgemeine Information und keine Rechtsberatung.

Abgrenzung zu IT-Security und Software-Entwicklung

Medical Device Cybersecurity unterscheidet sich von klassischer Unternehmens-IT-Security. Dort geht es um Netzwerke, Arbeitsplätze und Informationssicherheitsmanagement, etwa nach ISO 27001 oder NIS-2. Hier geht es um das Produkt selbst und seinen Lebenszyklus. Beides berührt sich, etwa wenn Cloud-Backends eines Herstellers betrieben werden, die Nachweise sind aber unterschiedlich.

Gegenüber dem Software-Entwickler nach IEC 62304 bringen Sie die Angreiferperspektive ein und verantworten Security-Anforderungen, Bedrohungsanalyse und Tests. Für Ihr Profil lohnt es sich, Produkttypen, Technologien (Embedded, Mobile, Cloud) und Ihre Erfahrung mit Einreichungen klar zu benennen. Das Feld ist jung, Auftraggeber schätzen konkrete Referenzen deutlich mehr als allgemeine Security-Zertifikate.

Projektbeispiele für Cybersecurity MedTech

Anonymisierte Projektanfragen, wie sie für diese Rolle und verwandte Profile regelmäßig vorkommen.

Häufige Fragen

Allgemeine Information, keine Rechts- oder Steuerberatung. Stundensätze sind Orientierungsspannen, kein Honorarspiegel. Stand: 10/2026.