ENISA-advies over veilige updates van 4 november 2026: wat de Cyberweerbaarheidsverordening, de AI Act en de nieuwe productaansprakelijkheidsrichtlijn eisen van software- en modelupdates

Op 19 juli 2024 verspreidde CrowdStrike een configuratiebestand voor zijn beveiligingssoftware Falcon, intern Channel File 291. Binnen enkele uren liepen volgens een schatting van Microsoft ongeveer 8,5 miljoen Windows-computers vast, bij luchtvaartmaatschappijen, ziekenhuizen, banken en overheden. De oorzaak was een fout in een gewone inhoudsupdate. Het Europese agentschap voor cyberbeveiliging ENISA gebruikt dat incident als voorbeeld in zijn Technical Advisory on Secure Update Mechanisms van 4 november 2026. Het advies beschrijft hoe fabrikanten software-updates bouwen, ondertekenen, verspreiden en installeren, en het rekent uitdrukkelijk ook AI-modellen tot de dingen die via een updatekanaal binnenkomen.

Wat ENISA op 4 november 2026 publiceerde over veilige updates, en waarom AI-modellen meetellen

Het advies is bedoeld voor teams die updatemechanismen ontwerpen of beheren, met nadruk op micro-, kleine en middelgrote fabrikanten. ENISA volgt een update in zeven stappen: bouwen en ondertekenen, publiceren, zoeken naar updates, downloaden, verifiëren, installeren en de uitkomst vastleggen. Voor elke stap geeft het dreigingen met echte voorbeelden, van SolarWinds en de gekaapte updatefunctie van Notepad++ tot ASUS ShadowHammer. Daarna volgen beheersmaatregelen in vier groepen. Fabrikanten ondertekenen de metadata van een update en binden het bestand daaraan. Signeersleutels liggen in een HSM, met gescheiden rollen en, bij hogere zekerheid, drempelhandtekeningen waarbij meer dan één sleutelhouder moet tekenen. Clients behandelen CDN's en mirrors als onbetrouwbaar, weigeren verouderde metadata en accepteren geen oudere versie, ook als die geldig ondertekend is. Mislukt een installatie, dan valt het systeem terug op een bekende goede versie.

ENISA noemt bij de soorten updates naast softwareversies, patches, configuraties en firmware ook modellen. Een nieuwe versie van een classificatiemodel in een camera of van een taalmodel in een applicatie volgt dus dezelfde keten en dezelfde risico's. Daarnaast verwacht ENISA meer updates: AI-hulpmiddelen voor kwetsbaarheidsonderzoek vinden sneller lekken, en het Britse NCSC waarschuwde in mei 2026 al voor een 'patch wave'. Het advies is niet bindend. ENISA schrijft zelf dat het geen formele uitleg van de Cyberweerbaarheidsverordening geeft en geen vermoeden van conformiteit oplevert. De definitieve tekst volgt op een openbare consultatie in juni en juli 2026, met twaalf reacties.

Wat de Cyberweerbaarheidsverordening vanaf 11 december 2027 van beveiligingsupdates vraagt

ENISA koppelt het advies aan de essentiële eisen van de Cyberweerbaarheidsverordening (Verordening (EU) 2024/2847, de CRA), die grotendeels vanaf 11 december 2027 gelden. Bijlage I, deel I, punt 2, onder c, vraagt dat kwetsbaarheden met beveiligingsupdates te verhelpen zijn, waar passend automatisch en standaard ingeschakeld, met een duidelijke opt-out en de mogelijkheid om tijdelijk uit te stellen. Onder f moet het product de integriteit van programma's en configuraties beschermen tegen wijzigingen die de gebruiker niet heeft toegestaan. Deel II, punt 2, vraagt dat de fabrikant kwetsbaarheden onverwijld verhelpt en, waar dat technisch kan, beveiligingsupdates los van functionele updates levert. De punten 7 en 8 gaan over veilige verspreiding en het snel en kosteloos beschikbaar stellen van die updates.

Artikel 13 maakt daar een termijn van. Lid 8 verplicht de fabrikant een ondersteuningsperiode vast te stellen die de verwachte gebruiksduur weerspiegelt, in beginsel ten minste vijf jaar, en die keuze in de technische documentatie te verantwoorden. Lid 9 bepaalt dat elke beveiligingsupdate na afgifte ten minste tien jaar beschikbaar blijft, of langer als de ondersteuningsperiode langer loopt. De meldplicht voor actief misbruikte kwetsbaarheden van artikel 14 geldt al sinds 11 september 2026; die bespraken we bij de PHP-lekken van oktober. Het ENISA-advies vult het deel daarna in: hoe de oplossing veilig bij de gebruiker komt. Een fabrikant die de controles volgt, kan per stap laten zien welke maatregel welke eis uit bijlage I ondersteunt. Dat overzicht hoort bij het dossier dat een markttoezichthouder kan opvragen.

Wanneer een modelupdate onder de AI Act een nieuwe conformiteitsbeoordeling vraagt

Voor AI-systemen met een hoog risico heeft een update een tweede juridische laag. Artikel 3, punt 23, van de AI-verordening omschrijft een ingrijpende wijziging als een wijziging na het in de handel brengen die bij de eerste conformiteitsbeoordeling niet was voorzien en die de naleving raakt of het beoogde doel verandert. Volgens artikel 43, lid 4, vraagt zo'n wijziging een nieuwe conformiteitsbeoordeling. Voor systemen die na het in de handel brengen blijven leren, geldt een specifieke uitzondering: wijzigingen in het systeem en zijn prestaties die de aanbieder bij de eerste conformiteitsbeoordeling vooraf heeft bepaald en in de technische documentatie heeft opgenomen (bijlage IV, punt 2, onder f), zijn geen ingrijpende wijziging. Een andere partij die een ingrijpende wijziging aanbrengt in een AI-systeem met een hoog risico dat al in de handel is gebracht of in gebruik is gesteld, wordt op grond van artikel 25, lid 1, onder b, zelf aanbieder wanneer het systeem een hoog risico blijft houden. Artikel 17, lid 1, onder a, vraagt in het kwaliteitsbeheersysteem procedures voor het beheer van wijzigingen; de eerste geharmoniseerde norm daarvoor bespraken we bij EN 18286.

De ondertekende metadata die ENISA aanbeveelt, met versienummer, toepasbaarheid en hashes, beschrijven welke modelversie is gepubliceerd en voor welke apparaten zij bedoeld is. Antirollback voorkomt dat een oudere, eerder beoordeelde of juist afgekeurde versie terugkomt. Samen met installatieregistraties per apparaat en een aantoonbare koppeling aan de technische documentatie van de oorspronkelijke beoordeling kan die administratie ondersteunend bewijs leveren voor de vraag of een wijziging vooraf was bepaald. Artikel 15, lid 5, van de AI-verordening noemt vergiftiging van data en modellen als aanvallen waartegen een systeem met een hoog risico bestand moet zijn; een gekaapt updatekanaal is de kortste weg naar zo'n vergiftigd model. Artikel 12 CRA biedt een brug voor een AI-systeem met een hoog risico dat ook een product met digitale elementen onder de CRA is. Zo'n systeem wordt geacht te voldoen aan de cyberbeveiligingseisen van artikel 15 als het product aan deel I van bijlage I voldoet, de processen van de fabrikant aan deel II voldoen en de EU-conformiteitsverklaring aantoont dat het door artikel 15 vereiste beschermingsniveau is bereikt. De data liggen dicht bij elkaar. Na Verordening (EU) 2026/1744 gelden de eisen voor de hoog-risicosystemen van bijlage III vanaf 2 december 2027, negen dagen voordat de CRA grotendeels van toepassing wordt.

Waarom de nieuwe productaansprakelijkheidsrichtlijn vanaf 9 december 2026 ook een ontbrekende update dekt

De productaansprakelijkheidsrichtlijn (Richtlijn (EU) 2024/2853) moet uiterlijk op 9 december 2026 zijn omgezet en geldt voor producten die daarna in de handel komen. Software is er uitdrukkelijk een product. Een fabrikant kan zich normaal beroepen op het verweer dat een gebrek pas ontstond nadat het product in de handel kwam. Artikel 11, lid 2, schakelt dat verweer uit wanneer het gebrek te wijten is aan software, inclusief updates en upgrades, aan het ontbreken van software-updates die nodig zijn om de veiligheid te handhaven, of aan een ingrijpende wijziging, mits de betreffende oorzaak onder de zeggenschap van de fabrikant valt. De benadeelde moet nog steeds gebrek, schade en oorzakelijk verband aantonen; de bepaling neemt een verweer weg en schept geen automatische aansprakelijkheid. Overweging 35 voegt toe dat een nieuwe update op zichzelf niet bewijst dat de vorige versie gebrekkig was. Het aansprakelijkheidsrisico ligt daarmee bij de fabrikant die updates nalaat of zijn updatekanaal slecht beveiligt. Hoe dat zich verhoudt tot de schuldvraag in het Nederlandse recht, bespraken we bij de Californische wet AB 316 en artikel 6:77 BW.

Een gemeente met verkeerscamera's, een mkb-bedrijf met een kassasysteem of een huishouden met een slimme thermostaat ziet het updatekanaal nooit. Zij rekenen erop dat de fabrikant kwetsbaarheden verhelpt zolang de ondersteuningsperiode van artikel 13, lid 8, CRA loopt, dat uitgebrachte beveiligingsupdates volgens lid 9 beschikbaar blijven en dat een kapotte update het apparaat niet onbruikbaar maakt. Medische hulpmiddelen, zoals een insulinepomp, vallen buiten de CRA en volgen de eigen regels van de MDR en de IVDR. Voor de overige producten raken de drie regimes elk een ander deel van die verwachting: de CRA als producteis met toezicht, de AI-verordening voor de identiteit van het beoordeelde systeem en de richtlijn als aansprakelijkheid tegenover wie schade lijdt.

Wat inkopers, overheden en leveranciers in hun contracten over updates vastleggen

De wet regelt de verhouding tussen fabrikant, toezichthouder en benadeelde. Tussen leverancier en zakelijke afnemer blijft veel open. De volgende punten volgen de stappen uit het ENISA-advies:

• Ondersteuningsperiode met einddatum, afgestemd op de werkelijke gebruiksduur bij de afnemer, plus de toezegging dat beveiligingsupdates los van nieuwe functies en zonder meerprijs komen.
• Signering en sleutelbeheer: wie de signeersleutels beheert, of die in een HSM liggen, of releases met tweepersoonsgoedkeuring worden vrijgegeven en wat er gebeurt bij verdenking van sleutelcompromittering.
• Gefaseerde uitrol en terugval: een eerste kleine groep apparaten, monitoring van die groep en een gegarandeerde terugkeer naar de vorige werkende versie. CrowdStrike kondigde na Channel File 291 zo'n gefaseerde uitrol voor zijn inhoudsupdates aan.
• Modelupdates: welke wijzigingen bij de eerste conformiteitsbeoordeling vooraf zijn bepaald en gedocumenteerd, een termijn waarbinnen de leverancier vooraf meldt dat een nieuwe modelversie de prestaties of het beoogde doel raakt, en wie dan de conformiteit opnieuw beoordeelt.
• Logging van de updatestatus per apparaat, met toegang voor de afnemer, zodat die zijn eigen zorgplicht onder de Cyberbeveiligingswet kan aantonen.
• Continuïteit als de updatedienst stopt of de leverancier failliet gaat: wie de sleutels en de updateserver overneemt, zodat apparaten niet terugvallen op onbeveiligde bronnen.
• Regres en aansprakelijkheid: hoe de verplichtingen uit de CRA en de productaansprakelijkheidsrichtlijn doorwerken in de vrijwaringen en beperkingen van aansprakelijkheid in de keten.

Overheden die camera's, sensoren of netwerkapparatuur voor tien jaar of langer inkopen, kunnen die punten als gunningscriterium opnemen. Een leverancier die zijn updateketen volgens het ENISA-advies kan beschrijven, levert daarmee al bewijs voor de CRA, voor een AI-systeem met een hoog risico en voor een latere aansprakelijkheidsprocedure.

Wilt u weten hoe uw eigen leverancierscontract met updates, ondersteuningstermijnen en aansprakelijkheid omgaat? De AIRecht contractscan laat zien welke bepalingen er staan en welke ontbreken.

Bronnen

ENISA, ENISA Technical Advisory on Secure Update Mechanisms, versie 1.0, 4 november 2026; Verordening (EU) 2024/2847 (Cyberweerbaarheidsverordening), artikelen 12, 13 en 14 en bijlage I; Verordening (EU) 2024/1689 (AI-verordening), artikelen 3, 15, 17, 25 en 43 en bijlage IV; Verordening (EU) 2026/1744; Richtlijn (EU) 2024/2853 (productaansprakelijkheid), artikel 11 en overweging 35; CrowdStrike, External Technical Root Cause Analysis – Channel File 291, 6 augustus 2024; Microsoft, Helping our customers through the CrowdStrike outage, 20 juli 2024; The Record, British cyber agency warns of looming 'patch wave' as AI speeds flaw discovery, 1 mei 2026. Stand van zaken: 11 november 2026.