Cybersecurity van medische hulpmiddelen in 2026: het MITRE-rapport ontcijferd
Interlynk
In april 2026 publiceerde MITRE een rapport dat meer aandacht verdient dan het in de meeste compliance-discussies krijgt: Cybersecurity Risk Analysis for Medical Devices in the Era of Evolving Technologies (cybersecurity-risicoanalyse voor medische apparaten in een tijdperk van veranderende technologieën). Het rapport is opgesteld voor de Amerikaanse overheid en gebaseerd op interviews met fabrikanten van medische apparaten (MDM's), zorginstellingen (HDO's), cybersecurityleveranciers en regelgevingsadviseurs. Het zet drie technologiedomeinen — cloudcomputing, AI/ML en post-quantumcryptografie — af tegen de cybersecurityrealiteit waarmee fabrikanten van medische apparaten vandaag te maken hebben.
Het rapport is geen checklist. Het is een risicolandschap. En wie het zorgvuldig leest, ziet één thema steeds terugkeren, ook waar de auteurs het niet met zoveel woorden zeggen: de toeleveringsketen van medische apparaten ís nu het aanvalsoppervlak.
Dit artikel ontleedt wat het rapport werkelijk zegt, waar het MDM's tot actie aanzet, en waarom de organisaties die hun software bill of materials behandelen als een levend beveiligingsinstrument — en niet als een nalevingsdocument — het best zijn voorbereid op wat komen gaat.
De centrale verschuiving: gedeelde verantwoordelijkheid in het hele ecosysteem
Decennialang was het cybersecuritymodel voor medische hulpmiddelen relatief overzichtelijk. Een MDM bouwde en verkocht het apparaat; een HDO gebruikte het op een netwerk dat zij zelf beheerde. De verantwoordelijkheden waren afgebakend.
Dat model bestaat niet meer.
Het rapport van MITRE documenteert wat de praktijk al ondervindt: het moderne medische hulpmiddelen is steeds vaker een gedistribueerd systeem. Essentiële functionaliteit kan afhangen van cloudinfrastructuur die door een derde partij wordt beheerd, van AI/ML-modellen die zijn getraind op datapijplijnen die de MDM niet volledig in handen heeft, en van cryptografische beveiliging die binnen tien jaar achterhaald zal zijn. Bovendien draait het apparaat zelf misschien helemaal niet meer in het ziekenhuis — maar bij de patiënt thuis, beheerd door iemand zonder beveiligingsexpertise.
Het rapport stelt het onomwonden: het cybersecurity-risicobeheer van medische hulpmiddelen is altijd al een gedeelde verantwoordelijkheid geweest tussen MDM's en HDO's, maar bij het bepalen van rollen en verantwoordelijkheden zijn nu ook aanvullende derde partijen onderdeel van de vergelijking.
Wat dit in de praktijk betekent: het aanvalsoppervlak is niet langer het apparaat. Het is het ecosysteem waarvan het apparaat afhankelijk is.
Cloud in medische hulpmiddelen: risicocategorieën
De adoptie van cloud in het ontwerp van medische apparaten is versneld — deels door de rekenkracht die AI/ML vereist, deels door de economie van SaaS-levering. Het rapport van MITRE is eerlijk over de risico's die dit met zich meebrengt.
Wanneer de essentiële functionaliteit van een medisch apparaat in de cloud draait — of de MDM nu IaaS, PaaS of SaaS afneemt van een externe provider — kan de MDM de beveiligingspositie van die infrastructuur niet volledig in eigen hand houden. Cloudproviders vallen niet onder dezelfde kaders die voor medische apparaten gelden. Hun storingen, hun misconfiguraties en hun blootstelling aan datalekken worden allemaal het patiëntveiligheidsprobleem van de MDM.
De ransomware-aanval op Elekta wordt in het rapport rechtstreeks aangehaald als bewijs: één verstoring van een clouddienst trof gelijktijdig de kankerbehandeling in meer dan 170 instellingen. Dit is het 'blast radius'-probleem (de reikwijdte van de schade) dat on-premise-architecturen zelden op die schaal veroorzaakten.
Het rapport benoemt drie categorieën van maatregelen tegen cloudrisico's:
Beleid en processen. Service Level Agreements (SLA's) tussen MDM's en cloudproviders moeten beveiligingsverwachtingen specifiek vastleggen — niet alleen uptime-SLA's. De inkoopbeheersmaatregelen uit ISO 13485:2016 (clausules 7.4.1–7.4.3) bieden een kader om van leveranciers, inclusief cloudproviders, te eisen dat zij toereikende continuïteitsplannen onderhouden.
Veerkrachtige architectuur en ontwerp. Hier wordt het gesprek over de SBOM onvermijdelijk. Het rapport van MITRE stelt rechtstreeks dat SBOM's voor cloudgebaseerde medische apparaten álle cloudcomponenten moeten omvatten — virtuele machines, containers en elke laag van de container-image, machine-images en cloud-native services. Een SBOM die ophoudt bij de grens van de applicatiecode is onvolledig voor een cloudverbonden apparaat. Hij vertelt u wat u hebt uitgeleverd. Hij vertelt u niet waarvan uw apparaat tijdens runtime afhankelijk is.
Voorbereiding en respons. Multiregio-implementatie, lokale caching als fallback-architectuur, en back-upstrategieën die rekening houden met cyberaanvalscenario's in plaats van alleen met hardwarestoringen.
De operationele consequentie: MDM's moeten met dezelfde precisie weten wat er in hun cloudstack zit als waarmee zij hun hardwarecomponenten documenteren. De meeste doen dat vandaag nog niet.
AI/ML in medische hulpmiddelen: de black box als patiëntveiligheidsprobleem
Per september 2025 was de FDA-database met AI-gestuurde medische apparaten gegroeid tot 1.357 vermeldingen — de overgrote meerderheid geconcentreerd in radiologie (76%) en cardiovasculaire toepassingen (9,5%). Dit zijn geen experimentele technologieën meer. Ze doorlopen toelatingstrajecten en bereiken patiënten.
Het rapport van MITRE is opvallend genuanceerd over het enthousiasme voor AI/ML in medische contexten. Uit de interviews bleek dat het voor MDM's en HDO's doorgaans niet duidelijk is waar AI/ML voordelen zou bieden die opwegen tegen de risico's die het kan introduceren. Dat is een opmerkelijke uitspraak van een onderzoeksorganisatie, en het weerspiegelt wat clinici al jaren zeggen: het vertrouwenstekort is reëel.
De cybersecuritydimensies van dat vertrouwenstekort worden in detail beschreven.
Integriteit van trainingsdata is een probleem in de toeleveringsketen. Als een aanvaller de data in welke fase van de AI/ML-levenscyclus dan ook kan vergiftigen — ruwe verzameling, labeling, training, validatie — draagt het resulterende model die corruptie mee de productie in. Dit is functioneel identiek aan een aanval op de softwaretoeleveringsketen. U levert de compromittering mee met het product. Met membership inference-aanvallen kan zelfs informatie over de personen achter de trainingsdata worden achterhaald, wat naast het veiligheidsrisico ook HIPAA-blootstelling creëert.
Het blackbox-probleem doorbreekt traditionele beveiligingszekerheid. Beveiligingsanalyse van software steunt op traceerbaarheid: u kunt door code stappen, variabelestatussen waarnemen, een stacktrace volgen, een fout reproduceren. Bij AI/ML is het onderliggende gedrag doorgaans een black box waarin de resultaten per uitvoering kunnen variëren. Dit is geen probleem dat met de huidige tooling op te lossen is — het is een inherente eigenschap van de technologie. MITRE is direct: er kan geen volledige zekerheid bestaan dat een oplossing 100% van de tijd zal werken.
Adaptieve modus creëert continue blootstelling. MDM's die kiezen voor adaptieve AI/ML-modellen — waarbij het model in productie blijft leren — erven een permanent aanvalsoppervlak: de datapijplijn. Vergiftigde invoer kan de modelprestaties na verloop van tijd aantasten op manieren die niet meteen detecteerbaar zijn, zeker als de aanvaller geduldig is.
Vergrendelde modus creëert duidelijkheid in versiebeheer, maar ook starheid. Statische, geversioneerde modellen bieden voorspelbaarder beveiligingseigenschappen en duidelijker auditeerbaarheid. De afweging is dat updates bewuste hertrainingscycli vereisen, die kunnen achterlopen op de klinische realiteit die het model moet weerspiegelen.
De aanbevolen maatregelen in het rapport — beveiligde leeromgevingen, guardrails met tests op adversariële robuustheid, threat modeling die AI/ML-componenten expliciet meeneemt, een least privilege-architectuur voor AI-subsystemen — zijn allemaal verstandig. Maar ze vereisen dat AI/ML-componenten worden behandeld als volwaardige software-artefacten met hun eigen herkomst, versiebeheer en dependency-tracking. Wat, opnieuw, een SBOM-vraagstuk is.
Post-quantumcryptografie: de dreiging met een deadline
Van de drie technologiegebieden die het rapport behandelt, is post-quantumcryptografie (PQC) het gebied met het meest uitgestippelde regelgevingstraject en de minste urgentie in de sector — een combinatie die historisch tot slechte uitkomsten leidt.
De situatie is als volgt, zonder omhaal. Quantumcomputers die het algoritme van Shor op schaal kunnen uitvoeren — wat NIST een Cryptanalytically Relevant Quantum Computer (CRQC) noemt — zouden RSA, Diffie-Hellman en Elliptic Curve Cryptography (ECC) wiskundig breken. Elk medisch apparaat dat vandaag met die algoritmen wordt beveiligd, zou kwetsbaar worden voor ontsleuteling.
De 'harvest now, decrypt later'-aanval (nu verzamelen, later ontsleutelen) is op statelijk niveau al gaande. Aanvallers hebben vandaag geen CRQC nodig. Ze hoeven alleen versleuteld verkeer op te vangen en op te slaan — apparaatcommunicatie, patiëntgegevens, bedrijfseigen telemetrie — totdat de quantumrekenkracht het inhaalt. Voor medische apparaten met een levensduur van 10 à 15 jaar in het veld kunnen gegevens die vandaag worden verzonden, binnen de operationele levensduur van het apparaat ontsleutelbaar worden.
NIST publiceerde in augustus 2024 zijn eerste definitieve post-quantumstandaarden (FIPS 203, 204 en 205). NIST heeft aangekondigd alle CRQC-kwetsbare asymmetrische algoritmen tegen 2035 als "Disallowed" (niet toegestaan) te classificeren. De NSA heeft als doel gesteld om beveiligingstoepassingen voor de nationale veiligheid vóór 31 december 2031 over te zetten naar CNSA 2.0 (een volledig post-quantum algoritmesuite).
Het probleem van de sector medische apparaten is structureel. Zoals het rapport van MITRE opmerkt: als een implanteerbaar medisch apparaat niet kan worden geherprogrammeerd zonder fysieke toegang tot de patiënt, zou cryptografische migratie een medische ingreep vereisen. Dat is geen software-patch. Dat is een klinische beslissing, wat betekent dat de migratietermijn voor sommige apparaatcategorieën niet in sprints maar in apparaatgeneraties wordt gemeten.
Praktische acties die het rapport aanbeveelt:
Voer een cryptografische inventarisatie uit over alle apparaten en systemen, en stel vast welke quantumkwetsbare asymmetrische cryptografie gebruiken
Prioriteer apparaten op risicoprofiel en blootstelling in de tijd
Bouw crypto-agility in nieuwe apparaatontwerpen — het vermogen om cryptografische implementaties te vervangen zonder het apparaat te herontwerpen
Stem de planning van de PQC-migratie af met HDO-partners, aangezien legacy-interoperabiliteit een blijvend risico vormt, zelfs nadat nieuwe apparaten zijn bijgewerkt
Het rapport merkt op dat er tools bestaan voor geautomatiseerde cryptografische detectie en inventarisatie (ACDI), maar dat die gericht zijn op algemene enterprise-IT — ze zijn niet gevalideerd voor gespecialiseerde omgevingen met medische apparaten. MDM's kunnen niet zomaar een enterprise-scantool draaien en het werk als gedaan beschouwen.
Wat het rapport van uw SBOM-praktijk verwacht
MITRE noemt SBOM's expliciet en specifiek. De formulering is het waard in context te worden weergegeven: SBOM's voor cloudgebaseerde medische apparaten zouden alle cloudcomponenten omvatten, zoals virtuele machines, containers en alle lagen in de container-image, de machine-image, en de cloud-native services.
Dat is een wezenlijk andere verwachting dan wat de meeste MDM's momenteel produceren. De bestaande SBOM-richtlijn van de FDA richt zich op de softwarecomponenten in het apparaat zelf. MITRE beschrijft een SBOM die de volledige operationele afhankelijkheidsgraaf vastlegt — inclusief runtime-infrastructuur die door een derde partij kan worden beheerd en die kan veranderen zonder directe actie van de MDM.
Voor AI/ML-gestuurde apparaten reikt de implicatie nog verder. Een volledige SBOM voor een AI/ML-medisch apparaat zou de herkomst van trainingsdata, modelversiebeheer, inferentie-infrastructuur en de componenten van de datapijplijn waarlangs nieuwe trainingsdata stroomt, moeten omvatten. Niets hiervan past netjes in de huidige SBOM-formaatspecificaties, die zijn ontworpen voor softwarepakketten — niet voor data-assets of modelgewichten.
Dit is geen kritiek op het huidige SBOM-ecosysteem. Het is een beschrijving van waar het werk naartoe moet.
10 best practices ontleed uit het rapport
Het MITRE-rapport is een risicoanalyse, geen voorschrift. Maar de inhoud wijst duidelijk naar specifieke operationele praktijken. Deze zijn niet aspirationeel — het zijn de praktijken die de risicobevindingen van het rapport vereisen.
Breng uw cloudafhankelijkheidsgraaf in kaart, niet alleen uw code-afhankelijkheden. Identificeer elke clouddienst die uw apparaat tijdens gebruik raakt, inclusief diensten die alleen in ontwikkelpijplijnen worden gebruikt (CI/CD-infrastructuur, trainingsomgevingen voor modellen). Een aanval op de toeleveringsketen van uw trainingspijplijn is een probleem voor de integriteit van het apparaat.
Breid uw SBOM uit met containerlagen en cloud-native componenten. Een container-image is geen enkel artefact — het is een stapel lagen, elk met zijn eigen CVE-blootstelling. Uw SBOM moet die structuur weerspiegelen.
Voer contractuele beveiligingsbeoordelingen uit van elke relatie met een cloudprovider. Cloudproviders worden niet gereguleerd als leveranciers in de toeleveringsketen van medische apparaten, maar functioneel opereren ze wel zo. Uw inkoopbeheersmaatregelen onder ISO 13485 moeten ook hen bereiken.
Bouw en test uw offline-degradatiemodus. Wat gebeurt er met de patiënt als uw cloudafhankelijkheid onbeschikbaar wordt? Ontwerpen voor gracieuze degradatie is niet optioneel voor apparaten die essentiële klinische functionaliteit leveren.
Behandel AI/ML-modelversies zoals u softwarereleases behandelt. Modelgewichten zijn code. Trainingshyperparameters zijn configuratie. Dataherkomst is herkomst binnen de toeleveringsketen. Versioneer, onderteken en audit ze dienovereenkomstig.
Scheid uw trainings- en testdatasets met dezelfde striktheid als die u toepast op toegangscontroles voor productiedata. Datacontaminatie (waarbij trainingsdata in validatiesets lekt, of omgekeerd) is zowel een kwaliteitsfout van het model als een mogelijke beveiligingsindicator.
Pas threat modeling expliciet toe op AI/ML-componenten. MITRE ATLAS — de Adversarial Threat Landscape for Artificial-Intelligence Systems — biedt voor AI hetzelfde aanvalsraamwerk dat ATT&CK biedt voor traditionele software. Gebruik het.
Inventariseer elke asymmetrische cryptografische beheersmaatregel in uw apparaatportfolio. RSA, Diffie-Hellman, ECC — documenteer waar ze voorkomen, in welke context, en wat het migratiepad is. Doe dit vóór 2027, niet als reactie op een regelgevingseis in 2034.
Ontwerp nieuwe apparaten vanaf het begin op crypto-agility. De apparaten die u vandaag bouwt, zullen nog klinisch in gebruik zijn wanneer de "Disallowed"-deadline van NIST in 2035 aanbreekt. Als de cryptografische implementatie niet kan worden bijgewerkt zonder hardwarevervanging, bouwt u een toekomstig terugroepprobleem (recall).
Stel uw PQC-migratieroadmap op in afstemming met uw HDO-klanten. Een apparaat met PQC-beheersmaatregelen dat samenwerkt met HDO-legacy-infrastructuur zónder die maatregelen, draagt nog steeds quantumrisico. Migratie is een probleem op systeemniveau, niet op apparaatniveau.
Hoe de sector ervoor staat
Het MITRE-rapport is opvallend om wat het niet beweert. Het zegt niet dat MDM's deze uitdagingen onder controle hebben. Het documenteert waar ze mee te maken hebben en hoe goede praktijk eruitziet. De kloof tussen die twee is het werkelijke verhaal.
Cloudverbonden medische apparaten worden vandaag ontworpen en toegelaten door organisaties die geen volledig beeld hebben van hun cloudafhankelijkheidsgrafen. AI/ML-componenten komen in productie zonder formele threat models die rekening houden met adversariële invoer of vergiftiging van trainingsdata. Cryptografische inventarisaties die 18 maanden in beslag zouden nemen, zijn nog niet begonnen.
Niets hiervan komt doordat MDM's nalatig zijn. Het komt doordat dit werkelijk moeilijke problemen zijn, de regelgevingskaders achterlopen op de technologie, en de tooling die naleving haalbaar zou maken nog niet bestaat voor de specifieke context van medische apparaten.
Dat laatste punt is waar het echte werk plaatsvindt. De organisaties die die tooling bouwen — en de MDM's die er vroeg mee samenwerken — zullen degenen zijn met schone migratiepaden wanneer de regelgevingsdeadlines vaste vorm krijgen.
Het MITRE-rapport is een kaart. De vraag is of u die gebruikt om te plannen, of wacht tot het terrein u dwingt.
Interlynk bouwt beveiligingsinfrastructuur voor de softwaretoeleveringsketen voor teams die SBOM serieus nemen als operationele discipline, niet als nalevingsvinkje. Werkt u uit hoe volledige SBOM-dekking eruitziet voor cloudverbonden of AI-gestuurde medische apparaten? Dan gaan we graag in gesprek.