FDA-SBOM-vereisten voor medische hulpmiddelen: de complete gids voor 2026
| Interlynk
FDA-SBOM-vereisten voor medische hulpmiddelen onder Section 524B: wat een cyber device is, refuse-to-accept, SBOM-inhoud en verplichtingen na markttoelating.
Overzicht
Wat Section 524B vereist, waarom indieningen worden geweigerd, wat een conforme SBOM moet bevatten, en de verplichtingen die na toelating beginnen.
Als je een medisch hulpmiddel maakt dat onder Section 524B kwalificeert als "cyber device", vereist de FDA een SBOM als onderdeel van de betreffende premarket-indiening. De SBOM is één onderdeel van een breder cybersecuritypakket dat de FDA tijdens de premarket-beoordeling evalueert.
Deze gids beschrijft wat de vereiste inhoudt, waar die vandaan komt, wat je SBOM moet bevatten en wat er na toelating gebeurt. De regels zijn inhoudelijk stabiel sinds 2023. De bijbehorende guidance is het afgelopen jaar twee keer herzien, en de versienummers zorgen voor verwarring. Deze gids benoemt de versie die nu geldt.
FDA-SBOM-vereisten in het kort
Section 524B van de Federal Food, Drug, and Cosmetic Act vereist dat fabrikanten van cyber devices een SBOM aanleveren in premarket-indieningen. De SBOM moet machineleesbaar zijn en commerciële, open-source- en off-the-shelf-componenten omvatten. De FDA had tot 1 oktober 2023 een specifiek cybersecurity-RTA-beleid; dat beleid is daarna verlopen. De onderliggende vereisten onder Section 524B zijn niet verlopen. De vereiste is in 2026 niet versoepeld. De guidance is aangepast aan de nieuwe kwaliteitsmanagement-terminologie, en de SBOM-verplichting blijft van kracht.
Juridische grondslag: Section 524B van de FD&C Act
De juridische grondslag is Section 524B, toegevoegd aan de FD&C Act door de omnibuswet van december 2022 en van kracht sinds 29 maart 2023. Die stelt vereisten vast voor "cyber devices", ofwel hulpmiddelen die software bevatten, verbinding met internet kunnen maken en technologische kenmerken hebben die kwetsbaar kunnen zijn voor cybersecuritydreigingen. De verbinding hoeft geen browser of een gebruikelijke internetinterface te zijn; wat telt, is of het hulpmiddel in staat is om verbinding met internet te maken, rechtstreeks of via een tussenliggend systeem.
Voor een cyber device vereist Section 524B dat de fabrikant een plan indient om kwetsbaarheden na markttoelating te monitoren en aan te pakken, het hulpmiddel zo ontwerpt en onderhoudt dat het geüpdatet en gepatcht kan worden, en een SBOM aanlevert. De SBOM is één pijler van een groter cybersecuritypakket en staat centraal in deze gids.
De verplichting ligt bij de indiener, ongeacht wie de code heeft geschreven. Contractfabrikanten, platformleveranciers en open-source-maintainers leveren allemaal componenten aan, maar de sponsor van de indiening is verantwoordelijk voor de SBOM. De code van een leverancier als buiten scope behandelen leidt vaak tot een onvolledige SBOM.
Opmerking over vereiste versus guidance: Section 524B stelt wettelijke cybersecurityvereisten vast voor cyber devices. De huidige guidance van de FDA licht de aanbevelingen van de instantie toe voor het aantonen van cybersecurity in premarket-indieningen. Niet elke aanbeveling in de guidance is zelf een wettelijke vereiste.
Refuse-to-Accept (RTA) en premarket-beoordeling
Refuse-to-accept, of RTA, is een administratieve drempel vóór de inhoudelijke beoordeling. Het specifieke cybersecurity-RTA-beleid van de FDA gold tot 1 oktober 2023 en is daarna verlopen. De onderliggende cybersecurityvereisten onder Section 524B zijn niet verlopen.
Voor een cyber device moeten sponsors nog steeds de cybersecurityinformatie aanleveren die Section 524B vereist en de aanbevelingen in de huidige FDA-cybersecurity-guidance opvolgen. Ontbrekende of ontoereikende informatie kan vertraging veroorzaken in het premarket-proces, ook al mag het verlopen cybersecurity-RTA-beleid van 2023 niet worden omschreven als een doorlopende RTA-regel.
Het praktische effect blijft een planningsprobleem: onvolledige cybersecuritydocumentatie kan leiden tot vragen, tekortkomingen of andere vertragingen voordat een indiening verder kan. Voor een product met een lanceringsdatum heeft die vertraging reële kosten.
Veelvoorkomende SBOM-problemen zijn een bestand dat niet machineleesbaar is, componenten zonder versies of bruikbare identificatoren, weggelaten code van derden, of een inventaris die het ingediende hulpmiddel niet accuraat beschrijft.
Vereiste inhoud van een conforme SBOM
De FDA schrijft geen enkel SBOM-bestandsformaat voor. De guidance vraagt om een machineleesbare SBOM en verwijst fabrikanten naar de NTIA Minimum Elements als basis. In de praktijk zijn CycloneDX en SPDX de twee dominante machineleesbare formaten die door SBOM-tools en organisaties worden gebruikt. Een uitgebreide vergelijking van de twee vind je in onze gids CycloneDX vs SPDX.
Naast het formaat moet een indieningsklare SBOM op vier punten standhouden.
Volledigheid. Elke softwarecomponent, niet alleen degene die je zelf hebt geschreven. Commerciële, open-source- en off-the-shelf-code horen allemaal in de inventaris. De herkomst van elke component telt hier, en juist daar wordt het onderscheid tussen SBOM, SOUP, COTS en OTS praktisch relevant. Die terminologie en hoe de FDA en IEC 62304 elke categorie behandelen, behandelen we in SBOM, SOUP, COTS en OTS in software voor medische hulpmiddelen.
Identiteit. Elke component heeft genoeg informatie nodig om te worden gevolgd en gematcht met kwetsbaarheidsdata: producent, naam en versie, met stabiele identificatoren zoals purl of CPE. Een component die alleen als vrije tekst zonder versie en zonder identificator is opgegeven, kan niet worden gematcht met een CVE-feed, wat het doel van het vermelden ervan tenietdoet.
Support-status. De FDA verwacht dat fabrikanten de onderhoudbaarheid van componenten adresseren, inclusief support-status en end-of-support-aspecten, zodat beoordelaars kunnen zien of softwarecomponenten nog worden onderhouden en of niet-ondersteunde componenten extra risico opleveren. Deze verwachting is concreet en wordt vaak over het hoofd gezien. We behandelden dit apart in De FDA wil het weten: wordt je software nog ondersteund?.
Actualiteit. De SBOM moet de software beschrijven die je indient, in de versie die je indient. Een SBOM uit een oude build, of uit de broncode terwijl je een binary hebt uitgeleverd, beschrijft een ander hulpmiddel. Versioneer hem per softwareversie van het hulpmiddel en houd hem opvraagbaar voor elke versie die nog klinisch in gebruik is.
Tijdlijn van de FDA-cybersecurity-guidance
SBOM-verwachtingen komen voor in meerdere FDA-documenten, en oudere artikelen verwijzen naar de versie die actueel was op het moment van schrijven. De onderstaande tabel plaatst elk document op zijn plek in de reeks.
Document | Datum | Betekenis |
|---|---|---|
Section 524B van kracht | Dec. 2022, werkzaam 29 maart 2023 | Creëerde de wettelijke cyber-device-categorie en de SBOM-verplichting |
Cybersecurity-RTA-beleid | Tot 1 okt. 2023 | Het specifieke cybersecurity-RTA-beleid van de FDA gold tot deze datum en verliep daarna |
Final guidance | Sep. 2023 | Eerste finale premarket-cybersecurity-guidance met Section-524B-aanbevelingen |
Final guidance | 27 juni 2025 | Verving de versie van 2023 en actualiseerde de premarket-cybersecurity-aanbevelingen |
Final guidance | 3 feb. 2026 | Huidige finale versie, afgestemd op het QMSR-kader |
De herziening van februari 2026 zorgt voor de meeste verwarring, dus precisie is hier op zijn plaats. Op 3 februari 2026 gaf de FDA een geactualiseerde final guidance uit: "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions". Die verving de versie van juni 2025. De herziening werd mede aangedreven door de Quality Management System Regulation, de QMSR, die op 2 februari 2026 van kracht werd en de eerdere Quality System Regulation onder 21 CFR Part 820 verving door een kader dat ISO 13485:2016 via verwijzing opneemt.
In de praktijk stemt de update van februari 2026 de cybersecurity-aanbevelingen af op het QMSR-kader. De SBOM-vereiste onder Section 524B is niet verwijderd of verzwakt. De update bevestigt dat cybersecurityprocessen thuishoren in het kwaliteitsmanagementsysteem van het hulpmiddel en geen losstaande technische activiteit zijn.
SBOM-verplichtingen na markttoelating
SBOM-verplichtingen eindigen niet bij de indiening. Voor cyber devices ondersteunt de SBOM een bredere reeks cybersecurityverplichtingen na markttoelating, die zich uitstrekken over de hele levenscyclus van het hulpmiddel.
Fabrikanten moeten monitoren op nieuwe kwetsbaarheden, een coordinated-vulnerability-disclosure-proces onderhouden en tijdig beveiligingsupdates en patches leveren, zoals de wet en de geldende FDA-verwachtingen vereisen. Tegen een statisch bestand werkt dat niet goed. Wanneer een nieuwe CVE een component van derden raakt, moet de fabrikant snel één vraag beantwoorden: welke hulpmiddelen en versies bevatten die? Een actuele, opvraagbare SBOM maakt die analyse veel sneller wanneer die gecorreleerd wordt met kwetsbaarheidsdata.
Onder de QMSR horen kwetsbaarheidsmonitoring en -respons in het kwaliteitsmanagementsysteem, in klachtenafhandeling en corrigerende maatregelen. SBOM-onderhoud is een doorlopende procesverplichting en geen eenmalig indieningsdocument.
Veelvoorkomende SBOM-compliancefouten
Deze foutpatronen komen bij indieningen steeds terug.
Een onderdelenlijst zonder onderhoud erachter. Een SBOM die één keer wordt ingediend, nooit wordt bijgewerkt en waaraan geen monitoringproces hangt. Die voldoet aan een premarket-vinkje en faalt bij de verplichting na markttoelating zodra er een CVE opduikt.
Code van leveranciers als buiten scope behandeld. De verplichting ligt bij de sponsor. Componenten van contractfabrikanten en platformleveranciers moeten in de SBOM staan, met echte identiteit en echte support-status in plaats van lege velden.
Een oppervlakkige inventaris. Alleen top-level-afhankelijkheden, zonder de transitieve boom. Een kwetsbaarheid in een transitieve afhankelijkheid moet nog steeds worden geïdentificeerd en beoordeeld.
Versiedrift. De ingediende SBOM beschrijft een andere build dan die op de markt komt. Genereer de SBOM uit de daadwerkelijke release en versioneer hem met de software.
Vrije-tekstcomponenten. Namen zonder versies en zonder identificatoren, die niet met een CVE-feed te matchen zijn en ruis in plaats van transparantie opleveren.
Elk van deze punten scheidt een SBOM die af lijkt van een die de beoordeling doorstaat en daarna bruikbaar blijft.
Praktische stappen voor FDA-SBOM-compliance
Voor een fabrikant van medische hulpmiddelen komt FDA-SBOM-compliance neer op drie gewoonten. Genereer de SBOM uit de daadwerkelijke build, zodat die het hulpmiddel beschrijft dat je uitlevert. Maak hem volledig en identificeerbaar, inclusief componenten van derden, open source en transitief, met bruikbare versies en identificatoren, en adresseer daarbij de onderhoudbaarheid van componenten. Houd hem actueel na toelating en correleer hem met kwetsbaarheidsdata, zodat je blootstellingsvragen kunt beantwoorden zodra er een nieuwe kwetsbaarheid opduikt.
De indiening is één mijlpaal in een lange levenscyclus van het hulpmiddel. Wanneer de SBOM wordt onderhouden als onderdeel van het bredere cybersecurityproces, wordt het voorbereiden ervan voor een indiening routinewerk in plaats van een race tegen de klok.
Interlynk helpt fabrikanten van medische hulpmiddelen om audit-klare SBOMs over builds heen te automatiseren, componentidentiteit en support-status in kaart te brengen en softwareblootstelling continu te bewaken tegen kwetsbaarheidsdata. Genereer in CycloneDX of SPDX, houd SBOMs actueel over de levenscyclus van het hulpmiddel, en beantwoord blootstellingsvragen na markttoelating sneller. Bekijk onze oplossing voor FDA-524B-compliance. Vertrouwd door security- en complianceteams bij meer dan 100 gereguleerde bedrijven.
Plan een demo · Gratis starten
Deze gids geeft de FDA-guidance weer zoals die gold bij de finale versie van 3 februari 2026 en is op het moment van publicatie op juistheid gecontroleerd. FDA-guidance evolueert. Controleer de vereisten voor elke indiening aan de hand van de actuele FDA-guidance en met je eigen regulatory-adviseur. Dit artikel is informatief en vormt geen juridisch of regulatory advies.