OTA-firmware-updates en de Cyber Resilience Act: patchen als serviceverplichting
OTA-updates zijn niet langer alleen een gemak—ze zijn een wettelijke plicht
Wanneer een Chinese robotfabrikant een manipulatorarm of een autonome mobiele robot naar de Europese Unie verscheept, is de firmware op dat apparaat nu onderworpen aan de Cyber Resilience Act (CRA). De verordening, gepubliceerd in het Publicatieblad van de EU als Verordening (EU) 2024/2847, verandert over-the-air (OTA) updates van een functie die klanten verrukt in een nalevingsverplichting die de markttoegang kan bepalen. Voor een servicenetwerk dat in Europa wordt opgezet, is de praktische consequentie duidelijk: patchen is geen incidentele reparatie, maar een continue service die moet worden gepland, gedocumenteerd en uitgevoerd met beveiliging in gedachten.
De CRA vereist niet alleen dat kwetsbaarheden worden verholpen; het vereist dat het updatemechanisme zelf veilig is. Bijlage I, Deel I, punt 2(d) van de verordening schrijft voor dat digitale elementen zo zijn ontworpen dat ze “aanvalsoppervlakken beperken” en “de impact van een incident minimaliseren”. Meer specifiek vereist punt 2(f) dat beveiligingsupdates tijdig worden geleverd en dat het updatemechanisme veilig is. Dit betekent dat een OTA-systeem dat niet-ondertekende firmware toestaat of dat kan worden onderbroken door een man-in-the-middle-aanval, niet compliant is, zelfs als de update-inhoud correct is.
Wat de CRA eist van updatemechanismen
De verordening stelt verschillende concrete beveiligingseisen aan OTA-updates. Onder Bijlage I, Deel I, punt 2(f), moeten fabrikanten ervoor zorgen dat updates worden “ondersteund door veilige mechanismen” die de installatie van ongeautoriseerde firmware voorkomen. Dit impliceert cryptografische ondertekening van updatepakketten, verificatie van de updatebron en integriteitscontroles vóór installatie. Bovendien mag het updateproces geen nieuwe kwetsbaarheden introduceren—bijvoorbeeld, het mag niet toestaan dat wordt teruggerold naar een versie met bekende kritieke kwetsbaarheden, tenzij expliciet geautoriseerd en gelogd.
Artikel 13(8) van de CRA voegt een extra laag toe: fabrikanten moeten ervoor zorgen dat kwetsbaarheden die kunnen worden uitgebuit “effectief worden beperkt” door beveiligingsupdates die gratis beschikbaar worden gesteld. De verordening specificeert geen vaste termijn, maar vereist dat updates “zonder onnodige vertraging” worden verstrekt nadat een kwetsbaarheid is ontdekt. Voor een servicenetwerk creëert dit een logistieke uitdaging: hoe push je een kritieke patch naar honderden robots in meerdere EU-lidstaten, elk met verschillende connectiviteit en onderhoudsschema’s?
Bovendien vereist Artikel 13(9) dat fabrikanten gebruikers documenteren en informeren over updates, inclusief hun beveiligingsimpact. Dit betekent dat elke OTA-update vergezeld moet gaan van release notes die uitleggen wat er is verholpen en waarom. Voor een externe serviceprovider wordt deze documentatie onderdeel van het servicerecord, dat kan worden gecontroleerd door nationale markttoezichtautoriteiten.
Het verzenden van kwetsbare firmware: wie is aansprakelijk?
De CRA verschuift de aansprakelijkheid aanzienlijk. Onder Artikel 13(1) moeten fabrikanten ervoor zorgen dat producten op de markt worden gebracht zonder bekende exploiteerbare kwetsbaarheden. Dit is een strikte verplichting: als een robot wordt verzonden met een firmwareversie die een bekende kritieke kwetsbaarheid heeft, is de fabrikant in gebreke, zelfs als de kwetsbaarheid na het ontwerp van het product is bekendgemaakt. Het enige verweer is dat de kwetsbaarheid op het moment van het op de markt brengen onbekend was, maar de bewijslast ligt bij de fabrikant.
Voor een servicenetwerk heeft deze aansprakelijkheid een rimpeleffect. Als een fabrikant vertrouwt op een lokale partner om updates uit te voeren, blijft de fabrikant verantwoordelijk voor de beveiliging van het product. De serviceprovider kan echter aansprakelijk worden gesteld onder algemeen contractenrecht als hij een update niet correct uitvoert, of als hij een update installeert die een nieuwe kwetsbaarheid introduceert. De CRA reguleert serviceproviders niet rechtstreeks, maar vereist wel dat fabrikanten ervoor zorgen dat “het product vergezeld gaat van de informatie en instructies” die nodig zijn voor veilige installatie en gebruik (Bijlage I, Deel I, punt 2(i)). Dit betekent dat een servicenetwerk toegang moet hebben tot gedetailleerde technische documentatie en de updateprocedures van de fabrikant tot in de puntjes moet volgen.
In de praktijk betekent dit dat een servicecontract duidelijk moet definiëren wie verantwoordelijk is voor het monitoren van kwetsbaarheidsmeldingen, wie beslist wanneer een update wordt gepusht, en wie de kosten van een mislukte update draagt. De CRA schrijft geen specifieke taakverdeling voor, maar vereist wel dat de fabrikant een proces heeft voor “gecoördineerde openbaarmaking” van kwetsbaarheden (Artikel 13(5)). Een servicenetwerk kan fungeren als de ogen en oren van de fabrikant ter plaatse, incidenten melden en verifiëren dat patches correct worden toegepast.
OTA versus fysieke service-update: een vergelijking
Hoewel OTA-updates vaak de meest efficiënte manier zijn om firmware te patchen, zijn ze niet altijd mogelijk. Sommige robots werken in geïsoleerde netwerken, sommige hebben veiligheidskritieke functies die fysieke interventie vereisen, en sommige hebben hardware die geen veilige OTA ondersteunt. De volgende tabel vergelijkt de twee benaderingen vanuit een service- en nalevingsperspectief.
| Aspect | OTA-update | Fysieke service-update |
|---|---|---|
| Snelheid van implementatie | Kan gelijktijdig naar veel apparaten worden gepusht, vaak binnen enkele uren | Vereist het plannen van een technicusbezoek; kan dagen of weken duren voor grote vloten |
| Beveiliging van het updatemechanisme | Moet cryptografische ondertekening, veilige kanalen en integriteitscontroles implementeren (CRA Bijlage I Deel I 2(f)) | Fysieke toegang vermindert het risico van externe onderschepping, maar vereist veilige behandeling van updatemedia en verificatie van de identiteit van de technicus |
| Documentatie en audittrail | Automatische logging van updatepogingen, succes/falen en apparaatstatus; gemakkelijker om bewijs van naleving te leveren | Vereist handmatige logging; risico op menselijke fouten of onvolledige gegevens |
| Kosten per update | Lage marginale kosten na initiële infrastructuurinvestering | Hoog: reistijd, arbeid en mogelijke stilstand |
| Geschiktheid voor veiligheidskritieke systemen | Kan extra validatie vereisen; sommige veiligheidsfuncties hebben mogelijk fysieke aanwezigheid nodig om te verifiëren | Voorkeur wanneer een technicus de robot visueel moet inspecteren of wanneer een fail-safe nodig is |
| Naleving van de CRA-vereiste voor gratis updates | Gemakkelijker om updates gratis te verstrekken, omdat er geen reiskosten zijn | Kan gratis zijn, maar de arbeidskosten moeten worden gedragen door de fabrikant of het servicecontract |
De keuze tussen OTA en fysieke updates is niet binair. Veel fabrikanten gebruiken een hybride aanpak: OTA voor niet-kritieke firmware, en fysieke bezoeken voor grote upgrades of veiligheidsgerelateerde patches. Voor een servicenetwerk betekent dit dat er capaciteiten op beide gebieden moeten worden opgebouwd, maar met een duidelijk begrip dat OTA de standaard is voor naleving omdat het sneller en beter controleerbaar is.
Praktische implicaties voor een servicenetwerk
Voor een lokaal servicenetwerk dat in Europa wordt opgezet, creëert de CRA een nieuwe inkomstenstroom: patchen als een service. Fabrikanten kunnen het monitoren van kwetsbaarheidsdatabases, het voorbereiden van updatepakketten en het verifiëren van succesvolle installatie uitbesteden. Dit vereist echter een niveau van technische expertise en juridisch bewustzijn dat verder gaat dan traditionele reparatie.
Ten eerste moet het netwerk toegang hebben tot het kwetsbaarheidsmeldingsproces van de fabrikant. De CRA vereist dat fabrikanten een “enig aanspreekpunt” onderhouden voor het melden van kwetsbaarheden (Artikel 13(5)), maar vereist niet dat ze dit met derden delen. Een servicecontract moet daarom bepalingen bevatten voor de fabrikant om de serviceprovider op de hoogte te stellen van relevante kwetsbaarheden en de nodige patches te verstrekken.
Ten tweede moet het netwerk kunnen verifiëren dat een update authentiek is en niet is gemanipuleerd. Dit betekent dat technici cryptografische handtekeningen moeten begrijpen en deze vóór installatie kunnen controleren. In de praktijk kan dit het gebruik van een secure bootloader inhouden die alleen ondertekende firmware accepteert, maar de technicus moet nog steeds bevestigen dat het updatepakket overeenkomt met de release notes van de fabrikant.
Ten derde moet het netwerk nauwkeurige gegevens bijhouden. Onder Artikel 13(9) moeten fabrikanten gebruikers informeren over updates, maar een serviceprovider moet mogelijk documenteren dat een update op een specifiek apparaat is toegepast, op welk tijdstip en met welk resultaat. Dit is niet alleen voor naleving, maar ook voor aansprakelijkheidsbescherming: als een robot faalt na een update, moet de serviceprovider kunnen bewijzen dat de update correct is uitgevoerd.
Ten slotte moet het netwerk voorbereid zijn op de mogelijkheid dat een fabrikant failliet gaat of stopt met de ondersteuning van een product. De CRA vereist dat fabrikanten beveiligingsupdates verstrekken voor de “verwachte levensduur” van het product (Artikel 13(8)), maar als de fabrikant verdwijnt, kan de verantwoordelijkheid op importeurs of distributeurs vallen. Een servicenetwerk kan inspringen om updates te verstrekken, maar moet daartoe het wettelijke recht hebben, wat opnieuw wijst op de noodzaak van duidelijke contracten.
Bronnen
- EUR-Lex — Verordening (EU) 2024/2847 — https://eur-lex.europa.eu/eli/reg/2024/2847/oj (geraadpleegd 2026-03-14)
- Europese Commissie — Cyber Resilience Act — https://digital-strategy.ec.europa.eu/ (geraadpleegd 2026-03-14)