SBOM, SOUP, COTS en OTS in software voor medische hulpmiddelen: De complete gids (2026)
| Interlynk
Moderne software voor medische hulpmiddelen is voor het grootste deel niet van u. Uit analyses van huidige FDA-indieningen blijkt consistent dat 75% of meer van de softwarestack van een gemiddeld hulpmiddel extern is — opensource-bibliotheken, commerciële tools van derden en vooraf gebouwde infrastructuur. De code die uw eigen team daadwerkelijk heeft geschreven, vormt vaak de minderheid van hetgeen wordt geleverd.
Zodra u niet kunt beantwoorden wat er in een hulpmiddel draait, heeft u een complianceprobleem. Daarnaast heeft u een probleem met de patiëntveiligheid.
Sinds maart 2023 vereist FDA Section 524B een Software Bill of Materials (SBOM) voor alle premarket-indieningen van cyberhulpmiddelen. Per 2 februari 2026 heeft de QMSR ISO 13485:2016 opgenomen in 21 CFR Part 820 als een bindende vereiste — wat betekent dat de inkoopcontroles, leveranciersevaluaties en ontwerplevenscyclusprocessen die bepalen hoe u softwarecomponenten van derden beheert, nu Amerikaanse wetgeving zijn, en niet langer slechts een internationale 'best practice'. Bovendien stelt de EU Cyber Resilience Act tegen december 2027 dezelfde SBOM-verwachting voor de Europese markten.
IEC 62304 vereist al jarenlang een gestructureerd beheer van SOUP (Software of Unknown Provenance). De meeste fabrikanten van medische hulpmiddelen hebben dit echter niet consistent genoeg gehandhaafd om stand te houden tijdens een serieuze audit.
Wat is een SBOM voor medische hulpmiddelen?
Een Software Bill of Materials is een machinaal leesbare inventaris van elk softwareonderdeel in een apparaat — open-source bibliotheken, commerciële SDK's, pakketten van besturingssystemen, firmware-afhankelijkheden, cloud-API's die uw apparaat tijdens runtime aanroept, en uw eigen propriëtaire code. Alles.
De analogie met een ingrediëntenlijst is hier zeer treffend: de inzet bij een ontbrekend element is de veiligheid van de patiënt, in plaats van een voedselallergie.
Wat dient een SBOM te bevatten?
De definitieve richtlijn van de FDA van juni 2025 verwijst naar de NTIA Minimum Elements als de basislijn. Elke vermelding van een component dient het volgende te bevatten:
Naam van de leverancier
Naam van de component
Versie
Unieke identificatiecode (CPE of PURL)
Afhankelijkheidsrelaties
Auteur van de SBOM
Tijdstempel (timestamp)
De FDA accepteert SPDX en CycloneDX als machineleesbare formaten. Een pdf-bestand met een lijst van softwareversies is niet toereikend.
Wat vereist FDA Sectie 524B?
Sectie 524B van de FD&C-wet, die op 29 maart 2023 van kracht is geworden, vereist dat fabrikanten van "cyberapparaten" een SBOM indienen die alle commerciële, open-source- en kant-en-klare componenten dekt. De FDA is op 1 oktober 2023 begonnen met het weigeren van niet-conforme indieningen. De definitieve richtlijn van juni 2025 verduidelijkte dat SBOM's voor cyberapparaten verplicht zijn; voor andere software-bevattende apparaten worden ze ten zeerste aanbevolen.
Een apparaat kwalificeert als een cyberapparaat als het:
software bevat die door de fabrikant is gevalideerd, geïnstalleerd of geautoriseerd;
verbinding kan maken met het internet of een ander apparaat; en
technologische kenmerken heeft die kunnen worden misbruikt.
Onder het QMSR moeten de QMS-processen achter die SBOM —
hoe u de softwarecomponenten daarin evalueert en kwalificeert,
hoe u leveranciers monitort,
hoe u ontwerpbeslissingen rondom software van derden documenteert
— nu voldoen aan de inkoopcontroles van ISO 13485:2016 §7.4 als een vereiste van Amerikaanse regelgeving, en niet langer enkel als een internationale certificeringspraktijk.
Praktijkvoorbeeld:
Een klasse II insulinepomp met
draadloze connectiviteit maakt gebruik van uw gepatenteerde doseringsalgoritme,
OpenSSL voor versleuteling,
Linux als besturingssysteem, en
een Bluetooth-stack van een derde partij.
Alle vier worden in de SBOM opgenomen met versienummers en CVE-blootstelling. Wanneer OpenSSL door een kritieke kwetsbaarheid wordt getroffen, beoordeelt u de impact nog diezelfde dag, in plaats van twee weken te besteden aan het reverse-engineeren van uw eigen product.
Wat is SOUP in medische hulpmiddelen? (IEC 62304)
SOUP — Software of Unknown Provenance — omvat alle software die niet specifiek voor uw apparaat is ontwikkeld, of waarvan geen toereikende ontwikkeldossiers over de levenscyclus bestaan. De definitie in IEC 62304 §3.1.7 is bewust ruim opgesteld: ze vangt open-source bibliotheken, commerciële software, legacy-drivers, voorgetrainde AI/ML-modellen en cloudcomponenten.
Bij uw eigen code is alles herleidbaar tot een ontwerpbeslissing. Bij SOUP is daar niets van waar. U hebt een bibliotheek die doet wat het label belooft — meestal — en een versienummer. U kunt niet auditen hoe ze is ontwikkeld, u kunt niet garanderen dat de auteur enige norm voor medische software heeft gevolgd, en u hebt geen invloed op óf en wanneer ze patches uitbrengen.
Dat is geen theoretische zorg. Het is de praktische situatie voor het merendeel van de software in de meeste apparaten.
IEC 62304 — SOUP-vereisten per veiligheidsklasse:
Klasse A (geen letsel mogelijk als de software faalt): identificeer het SOUP-item en de versie. Minimale aanvullende documentatie vereist.
Klasse B (niet-ernstig letsel mogelijk): de eisen van klasse A, plus gedocumenteerde functionele eisen voor de SOUP, gebruiksvoorwaarden en bekende anomalieën.
Klasse C (ernstig letsel of overlijden mogelijk): de eisen van klasse B, plus alle beschikbare informatie over de ontwikkelhistorie en het testen van de SOUP, met een geschiktheidsbeoordeling.
Onder het QMSR is ISO 13485 §7.3 (ontwerp en ontwikkeling) nu bepalend voor de wijze waarop SOUP in het apparaatontwerp wordt geïntegreerd. §7.4 regelt de evaluatie en monitoring van leveranciers voor SOUP-aanbieders. Beide onderdelen zijn nu toetsbaar onder de Amerikaanse wetgeving. Indien uw SOUP-register en de kwalificatiedossiers van uw leveranciers niet voldoen aan de ISO 13485-normen, heeft u een QMSR-tekortkoming — en niet louter een documentatieprobleem onder IEC 62304.
Praktijkvoorbeeld: Een ECG-monitor maakt gebruik van een populaire open-source bibliotheek voor golfvormweergave van GitHub — die al 18 maanden niet is bijgewerkt. Een nieuwe ontwikkelaar introduceert een regressie waardoor de golfvorm onder bepaalde weergaveomstandigheden onjuist wordt geschaald. Zonder versiebeheer (version pinning) en post-market surveillance op CVE's en release-feeds, ontdekt de fabrikant van het medische hulpmiddel het probleem pas wanneer een medicus melding maakt van afwijkende meetwaarden. Met een adequat SOUP-register activeert de nieuwe release een beoordeling voordat deze de apparatuur bereikt.
OTS en COTS: het cruciale onderscheid voor documentatie
OTS (Off-the-Shelf) software is alle kant-en-klare software die niet specifiek voor uw apparaat is ontworpen — ontwikkeld voor algemeen gebruik, geïntegreerd in uw product, waarbij de broncode doorgaans niet toegankelijk is voor wijzigingen. COTS (Commercial Off-the-Shelf) is de commercieel gelicentieerde subset: een leverancier verkoopt het, brengt kosten in rekening en bezit het intellectueel eigendom (IP). Dus alle COTS is OTS, maar niet alle OTS is COTS — open-source software is OTS zonder commercieel te zijn. Beide categorieën kwalificeren als SOUP onder IEC 62304, en beide moeten in uw SBOM worden opgenomen.
De implicaties voor de documentatie verschillen. Open-source OTS geeft u toegang tot de codebase en de ontwikkelingsgeschiedenis, zelfs als die geschiedenis niet is opgesteld onder normen voor medische software. Commerciële OTS biedt u doorgaans geen van beide — enkel een licentieovereenkomst en de testen die de leverancier op basis van eigen voorwaarden heeft uitgevoerd.
De OTS-richtlijnen van de FDA vereisen bewijs dat de OTS-software de prestaties of veiligheid van het apparaat niet nadelig beïnvloedt: een gedocumenteerde motivering voor de selectie ervan, testbewijs dat het correct functioneert in de specifieke context van uw apparaat, en een plan voor het beheer van levenscyclusgebeurtenissen van de leverancier. IEC 62304 vereist die validatie, zelfs als de software volledig ongewijzigd is. Testen door de leverancier gelden niet als uw eigen testen.
De blootstelling aan levenscyclusrisico's die vaak wordt onderschat: wanneer een COTS-leverancier het einde van de levensduur (end-of-life) aankondigt voor een component die in uw apparaat is geïntegreerd, zijn de opties beperkt. Het onderhandelen over verlengde ondersteuning is kostbaar. Het forken van de codebase is onder de licentie meestal onmogelijk. Herontwerpen rondom een vervangend product kan in een gereguleerde context leiden tot een nieuwe 510(k)-aanvraag. Onder QMSR vereist ISO 13485 §7.4 dat u dit levenscyclusrisico voorafgaand aan de selectie heeft geëvalueerd en dit gedurende de commerciële levensduur van het product monitort — en niet pas ontdekt na een EOL-aankondiging van de leverancier.
Aangepaste code | Open-Source (SOUP) | OTS/COTS (SOUP) | |
|---|---|---|---|
IEC 62304-klasse | A, B of C | B of C bij veiligheidskritisch | B of C bij veiligheidskritisch |
FDA 524B SBOM | Vereist | Vereist | Vereist |
Geaccepteerd SBOM-formaat | SPDX of CycloneDX (machineleesbaar) | ||
Risicoanalyse | ISO 14971 risicomanagement | SOUP-risicoanalyse Functionele + veiligheidsimpact | SOUP-risicoanalyse |
CVE-monitoring | Volledig in uw beheer | NVD + CISA KEV | NVD + adviezen van leverancier |
Toegang tot broncode | Volledige toegang | Meestal volledige toegang | Meestal gesloten |
Patchbeheer | U bepaalt het releasetijdstip | Forken of wachten op upstream | Afhankelijk van leverancier |
Licentietype | Eigendomsrechtelijk | MIT, Apache, GPL, BSD | Commerciële licentie vereist |
Praktijkvoorbeelden | UI-logica apparaat, Doseeralgoritme, Sensorfusie-code | OpenSSL, libcurl, Linux-kernel | Windows 10, VxWorks, Azure SDK |
Wanneer onbekende herkomst meer kost dan compliancepunten
In december 2021 trof de log4shell-kwetsbaarheid (CVE-2021-44228) Apache Log4j — een Java-loggingbibliotheek die is ingebed in een aanzienlijk deel van de enterprise-software wereldwijd. Een CVSS van 10.0. Uitvoering van code op afstand via één enkele kwaadaardige reeks in een logboekinvoer.
Fabrikanten van medische hulpmiddelen behoorden tot de partijen die direct in actie moesten komen. Het specifieke probleem: velen konden niet beantwoorden of hun hulpmiddelen überhaupt Log4j gebruikten, omdat zij niet beschikten over een betrouwbare inventarisatie van componenten. Sommigen draaiden het in backend-cloudsystemen die gegevens van hulpmiddelen verwerkten. Anderen hadden het ingebed in een component van derden dat jaren eerder was geïntegreerd. De FDA heeft in januari 2022 een veiligheidsmededeling uitgebracht die specifiek gericht was op Log4j in medische hulpmiddelen.
Organisaties met up-to-date SBOM's en SOUP-registers brachten hun blootstelling binnen enkele uren in kaart. Organisaties die hier niet over beschikten, hadden weken nodig — en sommigen konden geen volledige zekerheid verkrijgen.
Hetzelfde patroon herhaalde zich bij OpenSSL (CVE-2022-0778, CVE-2022-3786), bij kwetsbaarheden in de ingebedde Linux-kernel en bij aanvallen op de toeleveringsketen gericht tegen CI/CD-infrastructuur die wordt gebruikt bij de ontwikkeling van hulpmiddelen. Eind 2025 waarschuwde de FDA dat de FreeStyle Libre 3-sensoren van Abbott onjuiste, te lage glucosewaarden weergaven als gevolg van een firmwarefout — met zeven sterfgevallen en meer dan 700 gewonden tot gevolg. Softwarefouten in hulpmiddelen waarvan de stack niet volledig wordt begrepen en beheerst, hebben klinische gevolgen.
Een onbekende herkomst is een variabele voor de patiëntveiligheid.
Het regelgevingslandschap in 2026
Regelgeving | Wat het vereist | Status |
|---|---|---|
FDA §524B (FD&C Act) | Machineleesbare SBOM (SPDX of CycloneDX) die alle commerciële, open-source en OTS-componenten dekt | In werking getreden in maart 2023; gehandhaafd vanaf okt 2023 |
FDA juni 2025 definitieve richtlijn | Verduidelijkt de reikwijdte van §524B voor apparaatwijzigingen; voegt Sectie VII toe voor cyberapparaten | Actief |
FDA QMSR (21 CFR Part 820) | ISO 13485:2016 opgenomen door middel van verwijzing — inkoopcontroles (§7.4), ontwerpcontroles (§7.3) en leverancierstoezicht zijn nu vastgelegd in de Amerikaanse wetgeving | Van kracht vanaf 2 februari 2026 |
IEC 62304 | SOUP-beheer, risicoanalyse en versiedocumentatie voor klasse B- en C-software | Actieve internationale norm |
EU Cyber Resilience Act | SBOM vereist voor alle producten met digitale elementen die in de EU worden verkocht | In werking getreden in dec 2024; SBOM-naleving vereist per 11 dec 2027 |
ISO 14971 | Kader voor risicobeheer; SOUP-risico's moeten hierin worden opgenomen | Actieve internationale norm |
Executive Order 14028 | SBOM voor federale inkoop | Optioneel |
Een praktisch gevolg van de QMSR waar teams door overvallen worden: FDA-inspecteurs zullen uw QMS-registers voortaan toetsen aan de ISO 13485-vereisten, inclusief registers die vóór februari 2026 zijn opgesteld. Indien uw processen voor SOUP-beheer, kwalificatiedocumentatie van leveranciers en ontwerpcontroleregisters voor componenten van derden niet naadloos aansluiten op ISO 13485, zal deze tekortkoming tijdens een inspectie aan het licht komen — en niet enkel tijdens een audit door een aangemelde instantie (notified body).
Over de SBOM als levend document: Wijzigingen aan apparaten — zoals software-updates, leverancierswijzigingen of integraties van nieuwe componenten — kunnen een nieuwe premarket-aanvraag vereisen. Wanneer dit het geval is, is §524B onverkort van toepassing, wat een volledige en actuele SBOM vereist. De SBOM die bij de initiële goedkeuring is opgesteld, is niet het document dat u gedurende de gehele commerciële levensduur van het apparaat kunt blijven gebruiken.
10 best practices die het handhaven waard zijn in 2026
1. Genereer SBOM's vanuit de build, niet vanuit het geheugen. Handmatig samengestelde SBOM's zijn verouderd zodra een afhankelijkheid wijzigt. SCA-tools die rechtstreeks in uw CI/CD-pipeline zijn geïntegreerd, produceren SBOM's die zijn voorzien van een versie, zijn ondertekend en nauwkeurig aansluiten bij de build.
2. Dek de containerlaag af. Voor met de cloud verbonden apparaten moet de SBOM elke laag van de containerimage bevatten — basisbesturingssysteem, runtime, middleware — en niet alleen de applicatiecode. De component die de kwetsbaarheid introduceert, is vaak niet de component die u zelf hebt geschreven.
3. Scheid de SBOM van het SOUP-register. De SBOM vertelt u wat er aanwezig is. Het SOUP-register registreert de risicoanalyse, de versie waaraan u bent gebonden, bekende anomalieën en de ondersteuningstermijnen van de leverancier. Verschillende artefacten, verschillende eigenaren, beide zijn vereist.
4. Zet versies vast. Variabele afhankelijkheden betekenen dat de software van het apparaat verandert zonder dat hier een bewust besluit aan voorafgaat. Onder IEC 62304 is een versiewijziging van een SOUP-item een wijziging in de apparaatsoftware. Behandel deze dan ook als zodanig.
5. Monitor CVE-feeds continu voor elke SOUP-component. NVD, OSV en beveiligingsadviezen van leveranciers moeten allemaal binnen de scope vallen. Wanneer een nieuwe CVE betrekking heeft op iets in uw SBOM, moet u een gedocumenteerd responsproces klaar hebben liggen — niet een week aan triage om uit te zoeken wie de eigenaar is.
6. Classificeer SOUP op veiligheidsklasse voordat u het integreert. Een bibliotheek voor weergave-opmaak en een algoritme voor insulinedosering hebben volledig verschillende IEC 62304-documentatie-eisen. Maak die classificatiebeslissing expliciet en documenteer de argumentatie. Retroactieve classificatie onder druk van een audit is geen goed proces.
7. Voer uw eigen validatie uit op OTS/COTS-componenten. Testen van de leverancier tonen aan dat de software werkt in de omgeving van de leverancier. U heeft bewijs nodig dat het werkt in de uwe — met uw hardware, onder uw gebruiksomstandigheden en in de context van de veiligheidsklasse die u eraan heeft toegekend.
8. Leg levenscyclusverplichtingen van de leverancier vast in het SOUP-register. Wanneer deze leverancier van plan is de ondersteuning voor deze versie te beëindigen, is een risicofactor die uw ISO 13485 §7.4-proces bij de selectie had moeten vastleggen. Als dat niet het geval was, documenteer dan wat u nu weet en markeer de tekortkoming.
9. Behandel AI/ML-modellen als SOUP. Een vooraf getraind model van een derde partij, een verfijnd basismodel, een model dat is getraind op een pipeline die u niet volledig beheert — al deze modellen hebben een onbekende ontwikkelingsherkomst onder IEC 62304. Ze vereisen dezelfde risicoanalyse als elk ander SOUP-item, plus specifieke aandacht voor de integriteit van de trainingsdata en het beheer van modelversies.
10. Breid de SBOM-dekking uit naar cloudinfrastructuur. Voor met de cloud verbonden apparaten omvat de operationele afhankelijkheidsgrafiek virtual machine-images, containerregisters, cloud-native services en API's van derden. De SBOM die stopt bij de applicatiecode dekt niet de component af die wordt misbruikt.
Veelgestelde vragen
Is Windows een voorbeeld van SOUP?
Ja — en dat geldt ook voor Linux, Android en elk ander besturingssysteem dat u niet onder uw eigen kwaliteitsmanagementsysteem hebt ontwikkeld. Onder IEC 62304 §3.1.7 kwalificeert Windows als zodanig, omdat er geen adequate documenten van het ontwikkelingsproces conform de norm bestaan. De interne tests van Microsoft en uw IEC 62304 SOUP-validatie zijn twee verschillende zaken.
Is een SBOM door de FDA vereist voor alle medische hulpmiddelen?
De wettelijke verplichting onder §524B heeft specifiek betrekking op 'cyber devices' — hulpmiddelen met software die door de fabrikant is gevalideerd of geautoriseerd, plus de mogelijkheid om verbinding te maken met internet of een ander apparaat. Voor niet-cyber-apparaten die wel software bevatten, raadt de FDA een SBOM ten zeerste aan. De richtlijn van juni 2025 heeft die reikwijdte niet gewijzigd, maar verduidelijkte wel dat bepaalde wijzigingen aan bestaande hulpmiddelen leiden tot volledige naleving van §524B.
Welk SBOM-formaat accepteert de FDA?
SPDX (beheerd door de Linux Foundation) en CycloneDX (beheerd door OWASP) worden beide geaccepteerd. Een spreadsheet of PDF kwalificeert niet als machineleesbaar volgens de definitie van de FDA. Beide formaten ondersteunen de NTIA-minimumelementen waarnaar de FDA in haar richtlijn verwijst.
Wat is het verschil tussen COTS and OTS?
OTS is de bredere categorie — alle vooraf gebouwde software die niet specifiek voor uw hulpmiddel is ontworpen. COTS is commercieel gelicentieerde OTS: u betaalt ervoor, een leverancier is de eigenaar. Opensourcesoftware is wel OTS, maar geen COTS. In de praktijk zijn de nalevingsverplichtingen vergelijkbaar, maar de documentatietrajecten verschillen omdat COTS-leveranciers doorgaans de toegang tot de broncode en de timing van patches beheren op een manier die opensource-beheerders niet hanteren.
Telt opensourcesoftware als SOUP?
Ja. Opensourcecode is buiten uw kwaliteitsmanagementsysteem (QMS) ontwikkeld. Het feit dat een project goed gedocumenteerd of veelgebruikt is, verandert niets aan de IEC 62304-classificatie — adequate ontwikkelingsdocumenten conform de norm bestaan niet voor opensourceprojecten omdat de norm geen deel uitmaakte van de wijze waarop ze zijn gebouwd. Een risicoanalyse die passend is voor de door u toegewezen veiligheidsklasse is vereist.
Wat gebeurt er als een SOUP-component halverwege de levenscyclus het einde van de levensduur bereikt?
De fabrikant van het medische hulpmiddel (MDM) moet beoordelen of het hulpmiddel nog steeds in een cyberveilige staat kan worden gehouden. Als er geen beveiligingspatches beschikbaar zijn voor nieuw ontdekte kwetsbaarheden, dreigt het hulpmiddel "redelijkerwijs onvoldoende beschermd te kunnen worden tegen actuele cybersecurity-bedreigingen" — de drempel in de postmarket cybersecurity-richtlijn van de FDA die verplichtingen tot openbaarmaking en mogelijke sanering met zich meebrengt. Onder de QMSR had uw ISO 13485 §7.4 leveranciersbeoordelingsproces dit risico moeten signaleren voordat het zich voordeed.
Hoe Interlynk helpt
Het bijhouden van een nauwkeurige, actuele SBOM over een hele portfolio van hulpmiddelen — cloudcomponenten, opensource SOUP, COTS-afhankelijkheden, AI/ML-modellen — is een operationele uitdaging. Het vereist automatisering op build-niveau, continue monitoring van kwetsbaarheden gekoppeld aan de context van het hulpmiddel, gestructureerde SOUP-risicotracking en de mogelijkheid om op verzoek FDA-conforme documenten te genereren. De QMSR voegt hier de eis aan toe dat dit alles is ingebed in een QMS dat aansluit op ISO 13485.
Interlynk bouwt die infrastructuur: geautomatiseerde SBOM-generatie, SOUP-registerbeheer, leveranciersbeoordeling, CVE-tracking per hulpmiddel en de evaluatie van gereedheid voor post-quantumcryptografie.
Boek een demo of ontdek onze opensource-toolset.