Een distributeur mailt met de vraag om uw conformiteitsverklaring. Die belandt bij sales, die hem doorstuurt naar de productmanager, die hem doorstuurt naar engineering, waar hij blijft liggen. Het apparaat wordt al vier jaar geleverd. De firmware bouwt op de machine van één engineer. Niemand heeft een inventaris van wat erin zit, het updatemechanisme is uit v1 geschrapt om een lanceerdatum te halen, en degene die de bootloader schreef vertrok in 2023.
Niets daarvan was nalatig. Het was normaal, en het ging prima tot het moment waarop iemand in de waardeketen een antwoord op schrift nodig had.
De EU Cyber Resilience Act heeft dat veranderd. Het is een verordening over markttoegang, geen gids met best practices voor beveiliging: producten met digitale elementen die in de EU worden verkocht moeten aan de eisen voldoen, en de verplichtingen liggen bij de fabrikant gedurende de hele levensduur van het product, niet bij een eenmalig afgegeven certificaat.
Dit artikel gaat over de engineeringgevolgen — wat CRA-compliance werkelijk verandert aan de manier waarop firmware wordt gebouwd, bijgewerkt en gedocumenteerd, en hoe u beoordeelt of uw eigen team dat naast de roadmap aankan. Bent u nog eerder in het traject en zoekt u nog uit hoe de software zelf gebouwd wordt, begin dan met de gids voor embedded softwareontwikkeling.
- De Cyber Resilience Act maakt van updatecapaciteit en kwetsbaarhedenbeheer geen engineeringvoorkeuren meer maar voorwaarden om in de EU te verkopen, waardoor ze van de backlog naar de architectuur verhuizen.
- Drie data bepalen de planning: de verordening trad op 10 december 2024 in werking, de meldplicht gaat in op 11 september 2026, en de hoofdverplichtingen gelden vanaf 11 december 2027.
- De verplichtingen hechten zich aan de levenscyclus van het product — planning, ontwerp, ontwikkeling en onderhoud — niet aan een document dat aan het eind wordt gemaakt, en daarom is achteraf inbouwen de dure route.
- Het engineeringwerk dat dit oplevert is concreet: een ondertekend en herstelbaar updatepad, een dependency-inventaris die u opnieuw kunt genereren, en een kwetsbaarhedenproces dat draait zolang het product wordt verkocht.
- De vraag zelf bouwen of inkopen gaat niet over of uw engineers dit kunnen. Ze gaat over of ze het kunnen terwijl ze ook de roadmap leveren, en voor producten die al in het veld staan naast het volgende.
- Niemand die vandaag op deze verordening rankt schrijft vanuit de positie van apparaatsoftware-engineering, en dat zegt hoeveel van de beschikbare gidsen juridisch is in plaats van praktisch.
Wat CRA-compliance werkelijk betekent voor een apparatenfabrikant
De Europese Commissie beschrijft een verordening voor verbindbare hardware en software — haar eigen voorbeelden lopen van babyfoons en smartwatches tot apps en computerprogramma’s — en legt de verplichting bij fabrikanten om cyberbeveiliging te adresseren in de planning, het ontwerp, de ontwikkeling en het onderhoud van het product, en om kwetsbaarheden gedurende de hele levenscyclus af te handelen. Producten dragen een CE-markering om conformiteit aan te tonen, en categorieën met een hoger risico vereisen vóór verkoop een beoordeling door een aangemelde instantie.
Lees dat als engineer in plaats van als jurist en er volgen drie dingen uit.
Het hecht zich aan het proces, niet aan de release. “Planning, ontwerp, ontwikkeling en onderhoud” is de volledige levenscyclus. Een conformiteitsoefening in de laatste sprint vóór de lancering kan een proces beschrijven; ze kan er met terugwerkende kracht geen creëren.
Het loopt door na levering. Kwetsbaarheden afhandelen over de hele levenscyclus betekent dat de verplichting nog steeds geldt voor een product dat u drie jaar geleden verkocht. Dat is de eis die het vaakst wordt onderschat, omdat ze eenmalige projectkosten omzet in vaste operationele kosten.
Het geldt voor wat u verkoopt, inclusief wat u niet zelf hebt geschreven. Een apparaat bestaat grotendeels uit code van anderen — een RTOS, een TCP/IP-stack, een cryptobibliotheek, een BSP van de leverancier, een tiental opensourcecomponenten die de build binnenhaalt. De verplichting om kwetsbaarheden af te handelen maakt geen onderscheid tussen de code die u schreef en de code die u leverde.
De drie data die uw planning bepalen
De middelste datum is degene waar teams door verrast worden. De meldplicht komt ruim een jaar vóór de hoofdverplichtingen, en melden is geen documentatietaak — u kunt een actief misbruikte kwetsbaarheid in uw product niet melden tenzij er iets naar uitkijkt, iemand eigenaar is van de beslissing, en er een weg is om de fix uit te rollen. In de praktijk vraagt de septemberdatum om de machinerie die de datum in december 2027 formeel eist.
Terugrekenend vanaf een product met een hardwarecyclus van twee jaar worden de architectuurbeslissingen die dit betaalbaar maken nu genomen, in het ontwerp van wat u dit jaar begonnen bent.
Wat de septemberklok werkelijk vereist
De meldplicht is niet open-eind. De Europese Commissie publiceert de deadlines, en die zijn kort genoeg dat geen enkel team ze op de dag zelf improviseert.
Lees dat als een monitoringspecificatie in plaats van een meldspecificatie. De klok van 24 uur begint op het moment dat iemand er kennis van neemt, dus alles stroomopwaarts van dat moment — het volgen van dependencies, triage en een bij naam genoemde eigenaar die kan beslissen — bepaalt of de deadline überhaupt haalbaar is. Bron: de CRA-meldpagina van de Europese Commissie, stand per 31 augustus 2026.
De eisen van de Cyber Resilience Act die uw firmware veranderen
Vier dingen verschuiven van “dat zouden we moeten” naar “dat moeten we”, en elk daarvan is een architectuurbeslissing en geen feature.
Een ondertekend updatepad dat veilig kan falen
Een verplichting om kwetsbaarheden gedurende de levensduur van een product af te handelen is een verplichting om een fix te kunnen uitrollen, wat betekent dat het firmware-over-the-air-updatemechanisme niet langer optioneel is. De engineeringinhoud is specifiek: secure boot zodat het apparaat alleen firmware draait die u hebt ondertekend, integriteitsvalidatie op het image, en rollbackbescherming zodat een half toegepaste update op een apparaat in de kelder van een klant een werkend product achterlaat en geen baksteen. Producten die al in het veld staan zonder dit zijn het lastige geval, want het updatemechanisme zelf moet aankomen via een kanaal dat nog niet bestaat.
Een inventaris van wat u werkelijk levert
Kwetsbaarheden afhandelen in componenten die u niet zelf hebt geschreven vereist dat u weet welke componenten u hebt geleverd, in welke versie, in welk firmware-image, op welke units. De meeste teams kunnen dit met een week werk reconstrueren en kunnen het niet op afroep opnieuw genereren — en dat is het verschil dat telt, want een kwetsbaarheidsmelding in een veelgebruikte bibliotheek is een vraag die u in uren beantwoordt, herhaaldelijk, jarenlang. De praktische toets is of uw build die inventaris automatisch produceert of dat een mens hem samenstelt.
Kwetsbaarhedenbeheer als doorlopend proces
Iemand moet disclosurefeeds volgen tegen uw componentenlijst, beoordelen wat op uw product van toepassing is en besluiten wat wanneer wordt uitgerold. Dit is de verplichting die de vorm van een engineeringteam het sterkst verandert, want ze is doorlopend en concurreert rechtstreeks met roadmapwerk. Het is ook degene waar het eerlijke antwoord voor veel productbedrijven is dat zo’n proces vandaag niet bestaat.
Documentatie die de mensen die haar schreven overleeft
Conformiteit berust op het kunnen aantonen hoe het product is ontworpen, wat is beoordeeld en wat is besloten. Dat is een ander artefact dan een eenmalig getekend architectuurdiagram — het is documentatie die naast de code actueel wordt gehouden, en dat is een discipline en geen deliverable. Embedded software beveiligingswerk heeft de neiging in de hoofden van twee mensen te leven; deze eis is wat het daaruit dwingt.
Welke producten binnen de reikwijdte vallen, en wie de verplichting draagt
De reikwijdte is breder dan de meeste hardwareteams bij eerste lezing aannemen. Ze is niet beperkt tot producten die als beveiligingsapparaten in de markt staan, en niet tot consumentengoederen — de toets is of het product digitale elementen heeft en verbinding kan maken, en dat dekt het meeste van wat een industriële, medische of consumentenapparatenfabrikant vandaag levert.
De verplichting ligt bij de fabrikant. Dat is van belang voor twee situaties die voortdurend terugkomen:
- U hebt de firmware door iemand anders laten bouwen. De verplichting blijft de uwe. Een ontwikkelcontract dat bij oplevering eindigt laat u achter met een levenscyclusplicht zonder bijbehorende engineeringcapaciteit, en dat is een scopevraag die u vóór het contract regelt, niet erna.
- U verkoopt via een distributeur in de EU. Aan de eisen moet in de hele waardeketen worden voldaan, dus het verzoek belandt uiteindelijk bij uw engineeringteam, ongeacht wie de unit verkocht.
Voor productcategorieën met een hoger risico is vóór verkoop een beoordeling door een aangemelde instantie vereist, wat een externe afhankelijkheid met een eigen doorlooptijd toevoegt aan een planning waar al hardware in zit.
Kan uw team dit intern opvangen?
Dit is de echte vraag, en het is geen vraag over competentie. De meeste embedded teams kunnen secure boot en een updatepad bouwen; velen hebben beide al gebouwd. De vraag is capaciteit en continuïteit, en die valt uiteen in vier eerlijke checks.
Kunt u uw componenteninventaris vandaag, op afroep, opnieuw genereren? Komt in het antwoord een mens met een spreadsheet voor, dan is het gat tooling, en tooling is het goedkoopste van de vier gaten om te dichten.
Heeft een product in het veld een werkend updatepad? Zo niet, dan is het werk geen compliancewerk — het is een firmwareproject met een bootloaderwijziging, een ondertekeningsinfrastructuur en een uitrolplan, en het moet als zodanig worden ingepland.
Wie is verantwoordelijk als er op een vrijdag een melding binnenkomt? Een bij naam genoemde persoon met de bevoegdheid om uit te rollen, of niemand. Dit is een vraag over het operating model die engineeringleiding niet alleen kan beantwoorden.
Wat gaat er van de roadmap af? Het werk is reîel en het is terugkerend. Een plan dat ervan uitgaat dat het wordt opgevangen zonder iets te verdringen, is een plan dat stilletjes niet zal gebeuren.
Waar teams ervoor kiezen hulp binnen te halen, is dat meestal voor de tweede en de derde: een afgebakend project om het update- en ondertekeningspad in een bestaand product te bouwen, en een proces dat iemand anders draait tot het routine is. Is het antwoord breder werven of samenwerken, dan vergelijkt de overzicht van toonaangevende bedrijven voor embedded softwareontwikkeling elf bedrijven op de capaciteit die elk daadwerkelijk publiceert, inclusief welke van hen secure boot, OTA en langetermijnonderhoud als hun eigen werk benoemen in plaats van als het probleem van de klant.
Wat dit kost, en waar de kosten werkelijk terechtkomen
Er is geen enkel getal, en de bandbreedtes die in leveranciersmarketing circuleren zijn niet goed genoeg onderbouwd om te herhalen. Wat wel voorspelbaar is, is waar de kosten zich concentreren, en dat is bruikbaarder als u een business case opbouwt.
Retrofit is met afstand de dure categorie. Een ondertekend updatepad toevoegen aan een product dat er niet voor is ontworpen raakt de bootloader, de memory map, het productieproces en de uitrol in het veld. Het nu in een product inbouwen kost daar een fractie van.
De terugkerende kosten zijn degene die over het hoofd worden gezien. Monitoring, triage en patchreleases lopen door zolang het product wordt verkocht en ondersteund. Een business case die alleen het eerste project beprijst onderschat de verplichting, en het is de terugkerende post die bepaalt of dit wordt opgevangen of bemand.
Fragmentatie van de vloot vermenigvuldigt alles. Vier hardwarerevisies en drie firmwarebranches betekent dat elke fix vier of meer releases is. Varianten consolideren is vaak het nuttigste wat een team kan doen voordat de verplichtingen gaan bijten, en het is een pure engineeringoefening zonder enige regelgevende inhoud.
Documentatie is goedkoop als ze doorlopend is en duur als ze archeologisch is. Naast de code bijgehouden is ze een kleine belasting per wijziging. Achteraf gereconstrueerd, op een codebase waarvan de auteurs vertrokken zijn, is ze een project.
Waar Crunch-IS past
Onze firmwareontwikkelingsdiensten bouwen bootloaders en veldupdatemechanismen met secure-bootverificatie, rollbackbescherming en integriteitsvalidatie als standaard, en nemen hardening — versleutelde communicatie, veilige opslag, toegangscontrole, verkleining van het aanvalsoppervlak — al vanaf de architectuurfase mee in plaats van nadat het product werkt. Dat is dezelfde reeks beslissingen die deze verordening nu niet-optioneel maakt, en daarom is het werk vaker een firmwareproject dan een complianceproject.
De andere helft is releasediscipline, want een verplichting om fixes betrouwbaar uit te rollen is een verplichting om een releaseproces te hebben dat zelf geen dingen stukmaakt.
Conclusie
De Cyber Resilience Act vraagt apparatenfabrikanten niets wat de betere embedded teams niet al bepleitten. Wat verandert is dat updatecapaciteit, zicht op dependencies en een draaiend kwetsbaarhedenproces nu voorwaarden zijn om te mogen verkopen in plaats van zaken om volgend jaar te financieren — en dat de producten die al in het veld staan er samen met het volgende product onder vallen.
De twee beslissingen die het waard zijn nu te nemen zijn architectureel: ontwerp het updatepad in wat u dit jaar begint, en maak van uw componenteninventaris iets wat de build produceert in plaats van iets wat een mens samenstelt. Beide zijn nu goedkoper dan op enig later moment, en voor geen van beide hoeft de verordening volledig uitgekristalliseerd te zijn voordat u handelt.
