Leitlinien der FDA zur Cybersicherheit vor der Markteinführung für Betriebssysteme von Medizinprodukten: Was die FDA für Einreichungen empfiehlt

Die meisten OEMs denken bei „FDA-Cybersicherheit“ sofort an die SBOM. Das ist zwar ein Aspekt, aber nicht das ganze Bild.
Der umfassendere Rahmen ist der Leitfaden der FDA zur Cybersicherheit vor der Markteinführung – „Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions“ –, der die aktuellen Vorstellungen der FDA hinsichtlich der Konzeption der Cybersicherheit von Medizinprodukten, der Kennzeichnung sowie der von der FDA für Zulassungsanträge empfohlenen Dokumentation zur Cybersicherheit von Medizinprodukten beschreibt. Sie deckt Produkte mit Cybersicherheitsrisiken ab, nicht nur netzwerkverbundene Produkte.
Abschnitt 524B des FD&C Act ist die verbindliche Rechtsvorschrift, die der FDA die Befugnis erteilt, Cybersicherheitsinformationen für „Cyber-Produkte“ zu verlangen. Aber 524B ist die gesetzliche Mindestanforderung, nicht das vollständige Modell für die Cybersicherheitsdokumentation. Die Leitlinie beschreibt das umfassendere Nachweispaket, das Hersteller erstellen sollten – und es geht weit über eine SBOM hinaus.
Dies ist für die Auswahl des Betriebssystems von Bedeutung, da das Betriebssystem einen wesentlichen Teil der Angriffsfläche der Software ausmacht. Das Betriebssystem ist jedoch nicht das gesamte Gerät. Die Aufgabe des Betriebssystemanbieters besteht darin, strukturierte technische Nachweise auf der Plattformebene bereitzustellen. Der OEM ist für die Einreichung auf Geräteebene, das Risikomanagement, die Validierung und die Verpflichtungen nach dem Inverkehrbringen verantwortlich.

Empfehlungen der FDA für Zulassungsanträge

Die FDA hat die aktuelle endgültige Leitlinie am 3. Februar 2026 veröffentlicht, wodurch die Fassung vom 27. Juni 2025 ersetzt wird. Sie gleicht die Terminologie an die Verordnung über Qualitätsmanagementsysteme (QMSR) an, die am 2. Februar 2026 in Kraft getreten ist und die Norm ISO 13485:2016 durch Verweis in 21 CFR Part 820 aufnimmt.
Die FDA empfiehlt den Herstellern, Cybersicherheit als Teil des Sicherheits- und Qualitätsmanagements für Medizinprodukte zu behandeln. Die Leitlinie nennt ein „Secure Product Development Framework“ (SPDF) als einen empfohlenen Ansatz zur Bewältigung von Cybersicherheitsrisiken während des gesamten Produktlebenszyklus. Zu den gängigen Ansätzen zur Bedrohungsmodellierung gehören STRIDE, Angriffsbäume und auf MITRE basierende Methoden.
Für einen Antrag vor dem Inverkehrbringen empfiehlt die FDA im Allgemeinen:

Eingabefeld	Was die FDA empfiehlt
SPDF	Nachweis, dass das Thema Cybersicherheit im Rahmen des Qualitätsmanagementsystems behandelt wird. Die FDA nennt das SPDF als einen empfohlenen Ansatz
Bedrohungsmodell	Gerätespezifisches Bedrohungsmodell mit methodischer Begründung, ermittelten Risiken, Abhilfemaßnahmen und einer Restrisikoanalyse
Sicherheitsarchitektur	Architekturdiagramme, Datenflussdiagramme, Vertrauensgrenzen und Schnittstellenverzeichnis
SBOM	Bestandsaufnahme aller Softwarekomponenten mit Versionsangaben. § 524B schreibt dies für Cybergeräte vor
Sicherheitstests	Cybersicherheitsprüfungen, darunter Penetrationstests, statische/dynamische Analysen, Fuzz-Tests und Analysen der Angriffsfläche
CVD-Verfahren	Dokumentiertes Verfahren zur Entgegennahme, Bewertung und Weitergabe von Sicherheitslückenmeldungen
Plan für die Zeit nach der Markteinführung	Verfahren zur Überwachung von Sicherheitslücken, zur Bereitstellung von Patches und zur Kommunikation mit der FDA
Kennzeichnung im Bereich Cybersicherheit	Sicherheitsmerkmale und -verfahren, die für Endnutzer und Gesundheitseinrichtungen dokumentiert sind

Es gibt kein einziges Tool und keinen einzigen Anbieter, der all dies abdeckt. Die verschiedenen Aspekte werden von unterschiedlichen Bereichen des Unternehmens betreut.

524B im Vergleich zur vollständigen Anleitung

Abschnitt 524B gilt für „Cybergeräte“ – im Allgemeinen handelt es sich dabei um Geräte, die vom Hersteller validierte Software enthalten, mit dem Internet verbunden sind und technische Merkmale aufweisen, die für Cybersicherheitsbedrohungen anfällig sind. Bei Unklarheiten hinsichtlich der Einstufung sollten Hersteller behördlichen Rat einholen.

	§ 524B	Leitlinien der FDA zur Cybersicherheit vor der Markteinführung
Was ist das?	Verbindliches Gesetz	Leitlinien der FDA (aktuelle Standpunkte, die für sich genommen in der Regel nicht verbindlich sind)
Geltungsbereich	Nur Cyber-Geräte	Geräte, die ein Cybersicherheitsrisiko darstellen, einschließlich bestimmter nicht vernetzter Softwaregeräte
Umfang	Schwachstellenmanagement, Updates/Patches, SBOM, koordinierte Offenlegung	SPDF, Bedrohungsmodell, Sicherheitsarchitektur, Tests, SBOM, CVD, Plan für die Zeit nach der Markteinführung, Kennzeichnung
Durchsetzung	Die FDA kann die Annahme bestimmter Anträge verweigern, denen die erforderlichen Angaben zur Cybersicherheit fehlen	Die FDA empfiehlt diesen Rahmen für eine einheitliche, risikobasierte Prüfung

Der Leitfaden enthält Empfehlungen zur Cybersicherheit für Geräte, die ein Cybersicherheitsrisiko bergen, und zwar nicht nur für mit dem Internet verbundene Geräte. Wenn Ihr Gerät Software enthält und ein Cybersicherheitsrisiko aufweist, empfiehlt die FDA, in Ihrem Antrag auf die Cybersicherheit einzugehen – unabhängig davon, ob es mit dem Internet verbunden ist oder nicht. Eine SBOM allein reicht nicht aus. (Für Geräte, die auf dem EU-Markt in Verkehr gebracht werden, siehe auch „CRA Medical Device Compliance: What’s Really Exempt?“)

Was sich im Februar 2026 geändert hat: Warum Beweise auf Betriebssystemebene an Bedeutung gewonnen haben

Mit der Aktualisierung der Leitlinien der FDA im Februar 2026 wurde die Terminologie an die QMSR angepasst. Für OEMs bedeutet dies in der Praxis nicht, dass der Betriebssystemanbieter die Verantwortung für das Qualitätssicherungssystem übernimmt. Der OEM bleibt weiterhin verantwortlich für behördliche Einreichungen, die Umsetzung des Qualitätssicherungssystems, das Risikomanagement im Bereich Cybersicherheit, die Validierung sowie die Verpflichtungen nach dem Inverkehrbringen.
Die Rolle des Betriebssystemanbieters ist enger gefasst, aber wichtig: Er muss strukturierte technische Nachweise bereitstellen, die der OEM in seine eigene Dokumentation integrieren kann. Die Leitlinien der FDA besagen, dass bekannte Schwachstellen im Rahmen des Cybersicherheits-Risikomanagements als vernünftigerweise vorhersehbare Risiken bewertet werden sollten. Das aktualisierte Inspektionsprogramm der FDA verfolgt einen risikobasierten Ansatz. Der Dokumentation zur Cybersicherheit vor der Markteinführung wird große Aufmerksamkeit geschenkt. Die Leitlinien der FDA besagen, dass unzureichende Informationen zur Cybersicherheit die Prüfung beeinträchtigen können, und Abschnitt 524B schafft verbindliche Einreichungsanforderungen für Cyber-Geräte. Für OEMs ist der praktische Punkt einfach: Artefakte auf Betriebssystemebene sollten strukturiert, rückverfolgbar und im Nachweispaket auf Geräteebene verwendbar sein.
Für ein Betriebssystem für Medizinprodukte umfassen strukturierte Nachweise auf Betriebssystemebene:

• SBOM-Artefakte für Komponenten der Betriebssystemplattform
• Protokolle zur Schwachstellenüberwachung und -einstufung
• Verfügbarkeit von Patches und Aktualisierungsprotokolle
• Dokumentation zum sicheren Bootvorgang
• Dokumentation zum Mechanismus für sichere Updates
• Beiträge zur Sicherheitsarchitektur auf Betriebssystemebene

Genau darin sollte sich eine Betriebssystemplattform für medizinische Anwendungen von einer allgemeinen Linux-Basis unterscheiden: nicht dadurch, dass sie für sich allein die Einhaltung gesetzlicher Vorschriften beansprucht, sondern dadurch, dass sie nachvollziehbare, prüfungsreife Artefakte auf Betriebssystemebene liefert, die der OEM in seine Prozesse für Risikomanagement, Verifizierung, Validierung und Nachmarktüberwachung auf Geräteebene integrieren kann.

Was MediTUX OS auf der Plattformebene abdeckt

Erstellung von SBOMs. MediTUX OS ist darauf ausgelegt, SBOM-Artefakte zur Erstellungszeit für die im Build enthaltenen Betriebssystemkomponenten zu generieren – Kernel, Userspace, Bibliotheken und unterstützte Firmware-Komponenten, sofern verfügbar. Bei einer Embedded-Linux-Distribution kann dies je nach ausgewähltem Image-Profil und Hardware-Plattform Hunderte von Kernel-, Userspace-, Bibliotheks-, Laufzeit- und Firmware-bezogenen Komponenten umfassen. OEMs bleiben für die Komponenten auf Anwendungsebene, die gerätespezifischen Komponenten und die Cloud-Komponenten in der vollständigen Geräte-SBOM verantwortlich.
Überwachung von Sicherheitslücken. L4B betreibt MOON (MediTUX OS Operations Network), das zur Unterstützung der Überwachung von Sicherheitslücken auf Betriebssystemebene, der Triage, der Verfolgung der Patch-Verfügbarkeit und der Update-Unterstützung für MediTUX-OS-Komponenten entwickelt wurde. Gemäß den Cybersicherheitsrichtlinien von QMSR und der FDA können diese Überwachungsergebnisse die Qualitätssicherungsprozesse des OEM unterstützen, da bekannte Sicherheitslücken als vernünftigerweise vorhersehbare Risiken bewertet werden sollten. Die OEMs bleiben für die Bewertung auf Geräteebene, die Beurteilung der Auswirkungen auf die Sicherheit und die Entscheidungen zur Bereitstellung verantwortlich. Eine CVE-Übereinstimmung ist nicht automatisch ein Problem für die Gerätesicherheit. Der OEM benötigt weiterhin eine Ausnutzbarkeitsanalyse im Gerätekontext: ob die anfällige Komponente enthalten ist, ob der betroffene Codepfad erreichbar ist, ob Ausgleichskontrollen vorhanden sind und ob eine Ausnutzung die Sicherheit, Wirksamkeit oder Datenintegrität beeinträchtigen könnte.
Sicherer Systemstart. MediTUX OS ist darauf ausgelegt, Workflows für den sicheren Systemstart auf unterstützten Hardwareplattformen zu unterstützen, einschließlich kryptografischer Integritätsprüfungen in den Startphasen, abhängig von der Zielhardware und der Systemarchitektur.
Sichere Updates. MediTUX OS enthält sFOTA (Secure Firmware Over The Air), das zur Unterstützung sicherer Software-Update-Workflows entwickelt wurde, einschließlich kryptografischer Integritätsprüfungen und rollback-orientierter Update-Strategien, abhängig von der Zielhardware, der Systemarchitektur und der Kundenimplementierung.

Was der OEM separat regeln muss

Das Betriebssystem übernimmt die Plattformebene. Der Rest erfordert Fachwissen auf Geräteebene.

Element	Wer kümmert sich darum?
SBOM auf Betriebssystemebene, CVE-Überwachung, Secure Boot, OTA	Anbieter von Betriebssystemplattformen (MediTUX OS, MOON, sFOTA)
Bedrohungsmodell auf Geräteebene	OEM oder Beratung im Bereich Cybersicherheit
Penetrationstests	OEM oder unabhängiges Prüfunternehmen
CVD-Verfahren	OEM (Verpflichtung des Herstellers)
Umfassende Sicherheitsarchitektur	OEM, mit Eingaben zur Betriebssystemplattform
Kennzeichnung im Bereich Cybersicherheit	OEM
Integration von SPDF in das QMS	OEM mit Unterstützung für Prozesse auf Betriebssystemebene
Plan zur Überwachung nach dem Inverkehrbringen	OEM mit Unterstützung für Betriebssystemplattformen zur Überwachung auf Betriebssystemebene

Diese Grenze ist entscheidend. Ein seriöser Betriebssystemanbieter sollte die Dokumentation der Plattformebene vereinfachen, anstatt so zu tun, als gehöre ihm die gesamte Lösung.

Warum Allzweck-Linux dies erschwert

OEMs, die Ubuntu, Debian oder auf Yocto basierende Distributionen einsetzen, stehen vor denselben Aufgaben auf Geräteebene – Bedrohungsmodellierung, Penetrationstests, CVD –, tragen aber zusätzlich die gesamte Last auf Betriebssystemebene. (Eine ausführlichere Erläuterung der Gründe hierfür finden Sie im Artikel „Warum Allzweck-Linux für Medizinprodukte nicht ausreicht“.)

• Die Erstellung einer SBOM erfordert maßgeschneiderte Tools
• Die Überwachung von CVEs in Hunderten von Paketen ist eine dauerhafte Aufgabe
• Secure Boot muss erstellt und validiert werden
• Die OTA-Infrastruktur muss aufgebaut und gewartet werden
• Die Dokumentation der Sicherheitsarchitektur auf Betriebssystemebene beginnt bei Null
• Die langfristige Wartung des Kernels und der Pakete (über 10 Jahre) obliegt dem OEM
• Gemäß den QMSR-Vorschriften sollten relevante Cybersicherheitsprozesse auf Betriebssystemebene in die überprüfbare Dokumentation des Qualitätssicherungssystems integriert werden, sofern sie die Produktsicherheit, die Konstruktionskontrolle, das Risikomanagement oder die Überwachung nach dem Inverkehrbringen betreffen

Genau darin liegt der Sinn einer Betriebssystemplattform für medizinische Anwendungen: die Belastung auf Betriebssystemebene zu verringern, damit sich das OEM-Team auf die gerätespezifischen Risiken konzentrieren kann, die nur es selbst einschätzen kann.

Häufig gestellte Fragen

Verlangt die FDA einen bestimmten Cybersicherheitsstandard für Betriebssysteme? Nein. Die FDA schreibt keinen bestimmten Cybersicherheitsstandard für das Betriebssystem selbst vor. Der Leitfaden verweist auf die Norm IEC 81001-5-1 als anerkannten Konsensstandard, doch muss in den eingereichten Unterlagen dennoch dargelegt werden, wie das Cybersicherheitsrisiko für das jeweilige Gerät gemanagt wird.
Ist Abschnitt 524B die wichtigste Anforderung an die Cybersicherheit? Er ist die verbindliche Rechtsvorschrift für vernetzte Geräte. Doch er gibt nicht das vollständige Bild wieder. Der umfassendere Rahmen, den die FDA empfiehlt, ist die „Premarket Cybersecurity Guidance“, die Geräte mit Cybersicherheitsrisiken abdeckt – einschließlich solcher, die nicht mit dem Netzwerk verbunden sind.
Erfüllt MediTUX OS alle Cybersicherheitsanforderungen der FDA? Nein, und keine Betriebssystemplattform kann das. MediTUX OS unterstützt die Betriebssystemebene: SBOM-Generierung, Schwachstellenüberwachung durch MOON, Secure Boot für unterstützte Hardware und sichere Updates über sFOTA. Bedrohungsmodellierung, Penetrationstests, CVD, Sicherheitsarchitektur und Kennzeichnung erfordern Fachwissen auf Geräteebene, das der OEM direkt oder über einen spezialisierten Partner bereitstellt. (Siehe auch: Gewährleistung der Sicherheit medizinischer Geräte mit MediTUX OS.)
Was ist SPDF? Secure Product Development Framework. Die FDA identifiziert es als einen empfohlenen Weg, um Cybersicherheitsrisiken über den gesamten Produktlebenszyklus hinweg zu managen. Die Idee dahinter ist, dass Cybersicherheit von Anfang an in den Entwicklungsprozess integriert wird und nicht erst vor der Einreichung nachträglich hinzugefügt wird.
Wie wirkt sich QMSR auf die Cybersicherheit aus? QMSR bedeutet, dass cybersicherheitsbezogene Aktivitäten, die die Gerätesicherheit beeinflussen, Teil des Qualitätsmanagementsystems sein sollten und nicht als separate Maßnahme behandelt werden dürfen. Die Leitlinien der FDA besagen, dass bekannte Schwachstellen als vernünftigerweise vorhersehbare Risiken bewertet werden sollten. Für OEMs bedeutet dies, dass Artefakte auf Betriebssystemebene wie SBOMs, Schwachstellenaufzeichnungen und Update-Protokolle so organisiert werden sollten, dass sie in das QMS passen, und nicht in einem technischen Repository verbleiben, das von den Prozessen des Qualitätssystems abgekoppelt ist.
Erzeugt MediTUX OS SBOM-Artefakte für FDA-Zulassungsanträge? Ja, auf der Ebene der Betriebssystemplattform. MediTUX OS ist so konzipiert, dass es SBOM-Artefakte zur Erstellungszeit für die im Build enthaltenen Betriebssystemkomponenten generiert. Die vollständige Geräte-SBOM – einschließlich Komponenten auf Anwendungsebene, in der Cloud und anderer Nicht-Betriebssystemkomponenten – liegt weiterhin in der Verantwortung des OEM.

---

---

Haftungsausschluss: Dieser Inhalt dient ausschließlich allgemeinen Informations- und Marketingzwecken und stellt keine Beratung in Bezug auf rechtliche, regulatorische, cybersicherheitstechnische, klinische oder qualitätssicherungstechnische Aspekte dar. Die Leitlinien der FDA spiegeln im Allgemeinen die aktuelle Auffassung der FDA wider und sind nicht bindend, sofern sie nicht an gesetzliche oder regulatorische Anforderungen geknüpft sind. Die Hersteller von Medizinprodukten bleiben weiterhin dafür verantwortlich, die geltenden Anforderungen zu ermitteln, ihr Qualitätsmanagementsystem (QMS) zu implementieren, Cybersicherheitsrisiken auf Geräteebene zu managen, Zulassungsanträge vorzubereiten und ihren Verpflichtungen nach dem Inverkehrbringen nachzukommen. MediTUX OS, MOON und sFOTA unterstützen Cybersicherheitsmaßnahmen auf Betriebssystemebene, ersetzen jedoch nicht die Verantwortlichkeiten des Herstellers auf Geräteebene.