FDA-SBOM-Anforderungen für Medizinprodukte: Der vollständige Leitfaden 2026

| Interlynk

Ein vernetztes Medizinprodukt mit EKG-Anzeige erzeugt seine Software Bill of Materials, eine SBOM mit grünen, gelben und roten Komponenten-Risikoindikatoren und einem FDA-Compliance-Häkchen, unter einem FDA-Section-524B-Label, Interlynk

FDA-SBOM-Anforderungen für Medizinprodukte nach Section 524B: Was ein Cyber Device ist, Refuse-to-Accept, SBOM-Inhalte und Pflichten nach dem Inverkehrbringen.

Übersicht

Was Section 524B verlangt, warum Einreichungen abgelehnt werden, was eine konforme SBOM enthalten muss und welche Pflichten nach der Zulassung beginnen.

Wenn Sie ein Medizinprodukt herstellen, das nach Section 524B als „Cyber Device" gilt, verlangt die FDA eine SBOM als Teil der jeweiligen Premarket-Einreichung. Die SBOM ist ein Bestandteil eines umfassenderen Cybersecurity-Pakets, das die FDA im Rahmen der Premarket-Prüfung bewertet.

Dieser Leitfaden legt dar, worin die Anforderung besteht, woher sie stammt, was Ihre SBOM enthalten muss und was nach der Zulassung geschieht. Die Regeln sind inhaltlich seit 2023 stabil. Die zugehörige Guidance wurde im vergangenen Jahr zweimal überarbeitet, und die Versionsnummern sorgen für Verwirrung. Dieser Leitfaden benennt die aktuell gültige Fassung.

FDA-SBOM-Anforderungen im Überblick

Section 524B des Federal Food, Drug, and Cosmetic Act verlangt von Herstellern von Cyber Devices, in Premarket-Einreichungen eine SBOM bereitzustellen. Die SBOM muss maschinenlesbar sein und kommerzielle, Open-Source- und Off-the-Shelf-Komponenten abdecken. Die FDA hatte bis zum 1. Oktober 2023 eine spezifische Cybersecurity-RTA-Richtlinie; diese Richtlinie ist danach ausgelaufen. Die zugrunde liegenden Anforderungen nach Section 524B sind nicht ausgelaufen. Die Anforderung wurde 2026 nicht gelockert. Die Guidance wurde an die neue Qualitätsmanagement-Terminologie angepasst, und die SBOM-Pflicht bleibt bestehen.

Rechtsgrundlage: Section 524B des FD&C Act

Die Rechtsgrundlage ist Section 524B, durch das Omnibus-Gesetz vom Dezember 2022 in den FD&C Act eingefügt und seit dem 29. März 2023 wirksam. Sie legt Anforderungen für „Cyber Devices" fest, also Produkte, die Software enthalten, sich mit dem Internet verbinden können und technologische Merkmale aufweisen, die für Cybersecurity-Bedrohungen anfällig sein könnten. Die Verbindung muss kein Browser und keine herkömmliche internetfähige Schnittstelle sein; entscheidend ist, ob das Produkt in der Lage ist, sich direkt oder über ein Zwischensystem mit dem Internet zu verbinden.

Für ein Cyber Device verlangt Section 524B vom Hersteller, einen Plan zur Überwachung und Behebung von Schwachstellen nach dem Inverkehrbringen vorzulegen, das Produkt so zu entwerfen und zu warten, dass es aktualisiert und gepatcht werden kann, und eine SBOM bereitzustellen. Die SBOM ist eine Säule eines größeren Cybersecurity-Pakets und steht im Mittelpunkt dieses Leitfadens.

Die Pflicht liegt beim Einreichenden, unabhängig davon, wer den Code geschrieben hat. Auftragsfertiger, Plattformanbieter und Open-Source-Maintainer steuern alle Komponenten bei, aber der Sponsor der Einreichung verantwortet die SBOM. Den Code eines Zulieferers als außerhalb des Geltungsbereichs zu behandeln, führt häufig zu einer unvollständigen SBOM.

Hinweis zu Anforderung und Guidance: Section 524B legt gesetzliche Cybersecurity-Anforderungen für Cyber Devices fest. Die aktuelle Guidance der FDA erläutert die Empfehlungen der Behörde für den Nachweis von Cybersecurity in Premarket-Einreichungen. Nicht jede Empfehlung in der Guidance ist selbst eine gesetzliche Anforderung.

Refuse-to-Accept (RTA) und Premarket-Prüfung

Refuse-to-Accept, oder RTA, ist eine administrative Hürde vor der inhaltlichen Prüfung. Die spezifische Cybersecurity-RTA-Richtlinie der FDA galt bis zum 1. Oktober 2023 und ist anschließend ausgelaufen. Die zugrunde liegenden Cybersecurity-Anforderungen nach Section 524B sind nicht ausgelaufen.

Für ein Cyber Device müssen Sponsoren weiterhin die nach Section 524B erforderlichen Cybersecurity-Informationen bereitstellen und die Empfehlungen der aktuellen FDA-Cybersecurity-Guidance berücksichtigen. Fehlende oder unzureichende Informationen können Verzögerungen im Premarket-Prozess verursachen, auch wenn die ausgelaufene Cybersecurity-RTA-Richtlinie von 2023 nicht als fortbestehende RTA-Regel bezeichnet werden sollte.

Der praktische Effekt bleibt ein Terminproblem: Unvollständige Cybersecurity-Dokumentation kann zu Rückfragen, Mängeln oder anderen Verzögerungen führen, bevor eine Einreichung weitergehen kann. Für ein Produkt mit festem Markteinführungstermin hat diese Verzögerung reale Kosten.

Häufige SBOM-Probleme sind eine Datei, die nicht maschinenlesbar ist, Komponenten ohne Versionen oder brauchbare Identifikatoren, ausgelassener Drittanbieter-Code oder ein Inventar, das das eingereichte Produkt nicht korrekt beschreibt.

Erforderliche Inhalte einer konformen SBOM

Die FDA schreibt kein einheitliches SBOM-Dateiformat vor. Die Guidance verlangt eine maschinenlesbare SBOM und verweist Hersteller auf die NTIA Minimum Elements als Basis. In der Praxis sind CycloneDX und SPDX die beiden dominierenden maschinenlesbaren Formate, die von SBOM-Tools und Organisationen genutzt werden. Einen ausführlichen Vergleich der beiden finden Sie in unserem Leitfaden CycloneDX vs SPDX.

Über das Format hinaus muss eine einreichungsfertige SBOM in vier Bereichen standhalten.

Vollständigkeit. Jede Softwarekomponente, nicht nur die selbst geschriebenen. Kommerzieller, Open-Source- und Off-the-Shelf-Code gehören alle ins Inventar. Die Herkunft jeder Komponente ist hier entscheidend, und genau hier wird die Unterscheidung zwischen SBOM, SOUP, COTS und OTS praktisch relevant. Diese Terminologie und wie FDA und IEC 62304 die einzelnen Kategorien behandeln, behandeln wir in SBOM, SOUP, COTS und OTS in Medizingerätesoftware.

Identität. Jede Komponente braucht genug Informationen, um nachverfolgt und mit Schwachstellendaten abgeglichen zu werden: Hersteller, Name und Version, mit stabilen Identifikatoren wie purl oder CPE. Eine Komponente, die nur als Freitext ohne Version und ohne Identifikator angegeben ist, lässt sich nicht mit einem CVE-Feed abgleichen, was den Zweck ihrer Auflistung zunichtemacht.

Support-Status. Die FDA erwartet von Herstellern, die Wartbarkeit von Komponenten zu adressieren, einschließlich Support-Status und End-of-Support-Aspekten, damit Prüfer nachvollziehen können, ob Softwarekomponenten weiterhin gepflegt werden und ob nicht mehr unterstützte Komponenten zusätzliche Risiken schaffen. Diese Erwartung ist konkret und wird oft übersehen. Wir haben sie gesondert behandelt in Die FDA will es wissen: Wird Ihre Software noch unterstützt?.

Aktualität. Die SBOM muss die Software beschreiben, die Sie einreichen, in genau der Version, die Sie einreichen. Eine SBOM aus einem alten Build oder aus dem Quellcode, während Sie ein Binary ausgeliefert haben, beschreibt ein anderes Produkt. Versionieren Sie sie pro Produkt-Softwareversion und halten Sie sie für jede noch klinisch eingesetzte Version abrufbar.

Zeitleiste der FDA-Cybersecurity-Guidance

SBOM-Erwartungen erscheinen in mehreren FDA-Dokumenten, und ältere Artikel beziehen sich jeweils auf die Fassung, die zum Zeitpunkt des Schreibens aktuell war. Die folgende Tabelle ordnet jedes Dokument seiner Stelle in der Abfolge zu.

Dokument

Datum

Bedeutung

Section 524B in Kraft

Dez. 2022, wirksam 29. März 2023

Schuf die gesetzliche Cyber-Device-Kategorie und die SBOM-Pflicht

Cybersecurity-RTA-Richtlinie

Bis 1. Okt. 2023

Die spezifische Cybersecurity-RTA-Richtlinie der FDA galt bis zu diesem Datum und lief dann aus

Final Guidance

Sep. 2023

Erste finale Premarket-Cybersecurity-Guidance mit Section-524B-Empfehlungen

Final Guidance

27. Juni 2025

Ersetzte die Fassung von 2023 und aktualisierte die Premarket-Cybersecurity-Empfehlungen

Final Guidance

3. Feb. 2026

Aktuelle finale Fassung, abgestimmt auf den QMSR-Rahmen

Die Überarbeitung vom Februar 2026 sorgt für die meiste Verwirrung, daher lohnt sich hier Präzision. Am 3. Februar 2026 gab die FDA eine aktualisierte Final Guidance heraus: „Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions". Sie ersetzte die Fassung vom Juni 2025. Die Überarbeitung wurde unter anderem durch die Quality Management System Regulation, die QMSR, angestoßen, die am 2. Februar 2026 in Kraft trat und die frühere Quality System Regulation nach 21 CFR Part 820 durch einen Rahmen ersetzte, der ISO 13485:2016 durch Verweis einbezieht.

In der Praxis stimmt das Update vom Februar 2026 die Cybersecurity-Empfehlungen auf den QMSR-Rahmen ab. Es hat die SBOM-Anforderung nach Section 524B nicht entfernt oder abgeschwächt. Es bekräftigt, dass Cybersecurity-Prozesse in das Qualitätsmanagementsystem des Produkts gehören und keine isolierte technische Tätigkeit sind.

SBOM-Pflichten nach dem Inverkehrbringen

SBOM-Pflichten enden nicht mit der Einreichung. Bei Cyber Devices unterstützt die SBOM eine breitere Reihe von Cybersecurity-Pflichten nach dem Inverkehrbringen, die sich über den gesamten Produktlebenszyklus erstrecken.

Hersteller müssen auf neue Schwachstellen überwachen, einen Coordinated-Vulnerability-Disclosure-Prozess unterhalten und zeitnah Sicherheitsupdates und Patches bereitstellen, wie es das Gesetz und die geltenden FDA-Erwartungen verlangen. Gegen eine statische Datei funktioniert das nicht gut. Wenn eine neue CVE eine Drittanbieter-Komponente betrifft, muss der Hersteller schnell eine Frage beantworten: Welche Produkte und Versionen enthalten sie? Eine aktuelle, abfragbare SBOM macht diese Analyse deutlich schneller, wenn sie mit Schwachstellendaten korreliert wird.

Unter der QMSR gehören Schwachstellenüberwachung und -reaktion in das Qualitätsmanagementsystem, in die Reklamationsbearbeitung und Korrekturmaßnahmen. Die SBOM-Pflege ist eine laufende Prozesspflicht und kein einmaliges Einreichungsdokument.

Häufige SBOM-Compliance-Fehler

Diese Fehlermuster treten bei Einreichungen immer wieder auf.

  • Eine Teileliste ohne Pflege dahinter. Eine einmal eingereichte, nie aktualisierte SBOM ohne angeschlossenen Überwachungsprozess. Sie erfüllt ein Premarket-Häkchen und versagt bei der Pflicht nach dem Inverkehrbringen, sobald eine CVE auftaucht.

  • Zulieferer-Code als außerhalb des Geltungsbereichs behandelt. Die Pflicht liegt beim Sponsor. Komponenten von Auftragsfertigern und Plattformanbietern müssen in der SBOM stehen, mit echter Identität und echtem Support-Status statt leerer Felder.

  • Ein oberflächliches Inventar. Nur Top-Level-Abhängigkeiten, ohne den transitiven Baum. Eine Schwachstelle in einer transitiven Abhängigkeit muss weiterhin identifiziert und bewertet werden.

  • Versionsdrift. Die eingereichte SBOM beschreibt einen anderen Build als den, der auf den Markt kommt. Erzeugen Sie die SBOM aus dem tatsächlichen Release und versionieren Sie sie mit der Software.

  • Freitext-Komponenten. Namen ohne Versionen und ohne Identifikatoren, die sich nicht mit einem CVE-Feed abgleichen lassen und Rauschen statt Transparenz erzeugen.

Jeder dieser Punkte trennt eine SBOM, die fertig aussieht, von einer, die die Prüfung übersteht und danach nützlich bleibt.

Praktische Schritte zur FDA-SBOM-Compliance

Für einen Medizinproduktehersteller läuft die FDA-SBOM-Compliance auf drei Gewohnheiten hinaus. Erzeugen Sie die SBOM aus dem tatsächlichen Build, damit sie das Produkt beschreibt, das Sie ausliefern. Machen Sie sie vollständig und identifizierbar, einschließlich Drittanbieter-, Open-Source- und transitiver Komponenten mit brauchbaren Versionen und Identifikatoren, und adressieren Sie dabei die Wartbarkeit der Komponenten. Halten Sie sie nach der Zulassung aktuell und korrelieren Sie sie mit Schwachstellendaten, damit Sie Expositionsfragen beantworten können, sobald eine neue Schwachstelle auftaucht.

Die Einreichung ist ein einzelner Meilenstein in einem langen Produktlebenszyklus. Wenn die SBOM als Teil des umfassenderen Cybersecurity-Prozesses gepflegt wird, wird ihre Vorbereitung für eine Einreichung zur Routinearbeit statt zum Kraftakt.

Interlynk unterstützt Medizinproduktehersteller dabei, audit-fähige SBOMs über Builds hinweg zu automatisieren, Komponentenidentität und Support-Status zuzuordnen und die Software-Exposition kontinuierlich gegen Schwachstellendaten zu überwachen. Erzeugen Sie in CycloneDX oder SPDX, halten Sie SBOMs über den Produktlebenszyklus aktuell und beantworten Sie Expositionsfragen nach dem Inverkehrbringen schneller. Siehe unsere Lösung für FDA-524B-Compliance. Vertraut von Sicherheits- und Compliance-Teams in über 100 regulierten Unternehmen.

Demo buchen · Kostenlos starten

Dieser Leitfaden gibt den Stand der FDA-Guidance zur finalen Fassung vom 3. Februar 2026 wieder und wurde zum Zeitpunkt der Veröffentlichung auf Richtigkeit geprüft. FDA-Guidance entwickelt sich weiter. Prüfen Sie die Anforderungen für jede Einreichung anhand der aktuellen FDA-Guidance und mit Ihrer eigenen Regulatory-Beratung. Dieser Artikel dient der Information und stellt keine Rechts- oder Regulatory-Beratung dar.

Vertraut von Sicherheits- und Compliance-Teams in 100+ regulierten Unternehmen

Sehen Sie sich Ihr richtig erstelltes SBOM an

Interlynk automatisiert SBOMs, verwaltet Open-Source-Risiken, überwacht Lieferanten und bereitet Sie auf die Post-Quanten-Ära vor – alles auf einer vertrauenswürdigen Plattform.

Vertraut von Sicherheits- und Compliance-Teams in 100+ regulierten Unternehmen

Interlynk automatisiert SBOMs, verwaltet Open-Source-Risiken, überwacht Lieferanten und bereitet Sie auf das Post-Quanten-Zeitalter vor – alles auf einer vertrauenswürdigen Plattform.

Audit-bereite SBOM. Bei jedem Build.

Vertraut von Sicherheits- und Compliance-Teams in 100+ regulierten Unternehmen

Interlynk automatisiert SBOMs, verwaltet Open-Source-Risiken, überwacht Lieferanten und bereitet Sie auf das Post-Quanten-Zeitalter vor – alles auf einer vertrauenswürdigen Plattform.

Audit-bereite SBOM. Bei jedem Build.