Eerste FAQ over de Cyber Resilience Act

De auteurs van deze blog nemen deel aan het door de EU gefinancierde project CRACY, dat KMO’s helpt de Cyber Resilience Act te begrijpen en na te leven.

Op 3 december 2025 heeft de Europese Commissie een document met veelgestelde vragen over de Cyber Resilience Act (CRA) vastgesteld, dat verdere verduidelijking en voorbeelden biedt over hoe fabrikanten de komende nalevingsverplichtingen voor hun producten met digitale elementen (PDE’s) moeten benaderen.

Voor een meer algemene bespreking van de inhoud en reikwijdte van de CRA verwijzen we naar onze eerdere blogpost over dit onderwerp.

Hoewel de FAQ een vele onderwerpen in de verordening behandelt, zijn de secties over fabrikantverplichtingen in hoofdstukken 4 en 5 bijzonder onthullend en eerlijk gezegd behoorlijk veeleisend. In tegenstelling tot een concreet beeld van de risicobeoordeling­sverplichtingen van de fabrikant, is het beeld dat naar voren komt er een waarin fabrikanten worden verwacht te functioneren als theoretische cybersecurity­experts, met bijzonder veeleisende verplichtingen wat betreft risicobeoordeling en componentintegratie. Het is opmerkelijk dat informatie ontbreekt over vrije en open-source software en oplossingen voor gegevensverwerking op afstand. Dit gebrek aan informatie kan te wijten zijn aan toekomstige richtsnoeren op grond van artikel 26 van de CRA die (hopelijk) later dit jaar of begin 2026 zouden uitkomen.

Deze blogpost onderzoekt drie kritieke gebieden waar de FAQ belangrijke verduidelijkingen biedt:

1. Vereisten voor risicobeoordeling
2. Essentiële vereisten voor producten met digitale elementen
3. Verplichtingen voor kwetsbaarheidsbeheer

De FAQ maakt duidelijk dat de risicobeoordeling­svereisten van de CRA uitgebreid en veeleisend zijn, maar zonder een bindend kader op te leggen. Fabrikanten moeten grondige beoordelingen uitvoeren die risicoïdentificatie, -analyse en -evaluatie omvatten, evenals risicobehandeling gedurende de gehele levenscyclus (van ontwerp en ontwikkeling tot productie, levering en onderhoud).

Er wordt geen pasklaar raamwerk geleverd. De FAQ benadrukt contextspecifieke threat modelling. Fabrikanten moeten hun risicobeoordelingen afstemmen op de specifieke situatie waarin hun product zal worden gebruikt. Een product bestemd voor kritieke infrastructuur en bediend door getraind personeel in een fabrieksomgeving vormt een heel ander risicoprofiel dan dezelfde technologie ingezet als consumentengoed in huizen. Deze contextgevoeligheid is in theorie verstandig, maar voegt in de praktijk gelaagde complexiteit toe.

Misschien wel het meest opvallende aspect van de risicobeoordeling­svereisten betreft het “beoogd doel” en “redelijkerwijs voorzienbaar gebruik of misbruik” van producten. Hoewel dit concepten zijn uit andere EU-harmonisatie­wetgeving, vormen ze bijzondere uitdagingen in de context van de CRA, waar de verordening van toepassing is op een grote verscheidenheid aan technologieën, variërend van de kleinste IT tot de grootste OT-systemen. In die context verzacht de FAQ hun toepassing niet, maar legt juist een bijzonder zware last op fabrikanten, vooral degenen die componenten produceren die mogelijk in andere producten kunnen worden geïntegreerd.

Fabrikanten moeten zowel downstream-integratie als eindgebruiks­scenario’s overwegen. Als uw product als component in het product van een andere fabrikant kan worden opgenomen, moet u nadenken over de relevante risico’s met betrekking tot verschillende soorten integratie. De FAQ vraagt component­fabrikanten in wezen om zich alle dingen voor te stellen waarvoor hun chip, module of component zou kunnen worden gebruikt. Dit legt de drempel van wat “redelijk” is vrij hoog. Het is een aanzienlijke analytische last die uitdagend kan zijn voor KMO’s, maar ook voor fabrikanten van veelzijdige componenten met brede potentiële toepassingen.

De FAQ gaat nog verder. Sommige gebruikers­aanpassingen worden gekarakteriseerd als “redelijkerwijs voorzienbaar gebruik”. Fabrikanten moeten risico’s die verband houden met gebruikers­aanpassingen expliciet identificeren, behandel­maatregelen implementeren en passende informatie en instructies aan gebruikers verstrekken over deze aanpassings­mogelijkheden.

De FAQ strekt zich zelfs uit tot redelijkerwijs voorzienbaar misbruik, met als voorbeeld ethisch hacken door gebruikers. Van fabrikanten wordt verwacht dat ze risico’s communiceren die verband houden met dergelijke scenario’s. De implicaties zijn enigszins verbijsterend: fabrikanten moeten mogelijk effectief risicobeoordelingen verstrekken voor scenario’s waarin gebruikers hun producten opzettelijk demonteren of onderzoeken. Dit vertegenwoordigt een aanzienlijke uitbreiding van traditioneel productvelligheids­denken.

Alsof de bestaande vereisten nog niet veeleisend genoeg waren, suggereert de FAQ dat fabrikanten redelijke projecties kunnen overwegen over veranderingen in het bedreigings­landschap en hoe deze de risicobeoordeling gedurende de levensduur van het product kunnen beïnvloeden. Deze toekomstgerichte verplichting vraagt fabrikanten niet alleen om huidige risico’s te beoordelen, maar om te anticiperen hoe cyberdreigingen zich kunnen ontwikkelen gedurende de jaren dat hun product in gebruik blijft. Het is onduidelijk hoe ver men moet gaan. Het zou mogelijk kunnen zijn te denken dat dit zou kunnen neerkomen op een standaard standaardzin die stelt dat quantum computing en AI elk onderdeel van cyberbeveiliging zoals we die kennen kunnen ontwrichten. Het werkelijk in de toekomst kijken bij risicobeoordelingen zal echter waarschijnlijk significant veeleisender zijn.

De FAQ benadrukt ook dat het gebruik van geharmoniseerde normen geen volledige naleving van risicobeoordeling­sverplichtingen garandeert. Hoewel geharmoniseerde normen wel een vermoeden van conformiteit bieden, behouden fabrikanten de uiteindelijke verantwoordelijkheid voor het waarborgen dat hun risicobeoordeling volledig en nauwkeurig is. Dit is nog een gebied waar de FAQ verduidelijkt dat fabrikanten niet simpelweg kunnen vertrouwen op gevestigde kaders, maar onafhankelijk oordeel en expertise moeten uitoefenen.

De FAQ biedt belangrijke verduidelijkingen over wanneer fabrikanten kwetsbaarheden in hun PDE’s moeten aanpakken.

Fabrikanten moeten PDE’s beschikbaar stellen zonder bekende exploiteerbare kwetsbaarheden. De FAQ biedt hier enige opluchting: kwetsbaarheden die alleen onder theoretische omstandigheden bestaan, zoals laboratorium­omgevingen of simulaties, of in situaties die niet zouden voorkomen in de werkelijke operationele omgeving van het product, activeren deze verplichting niet. Ze zijn niet “exploiteerbaar”. Dat gezegd hebbende, gezien de uitgebreide interpretatie van “redelijkerwijs voorzienbaar gebruik en misbruik” die hierboven is besproken, kan de operationele omgeving breder zijn dan fabrikanten aanvankelijk zouden kunnen aannemen.

De FAQ verduidelijkt ook dat fabrikanten niet verplicht zijn om nieuw ontdekte kwetsbaarheden te verhelpen in het tijdvenster tussen het op de markt brengen van een product en het bereiken van de eindgebruiker. Dit zou bijvoorbeeld het geval zijn wanneer een product in de schappen van een winkel ligt, voordat het wordt gekocht. Kwetsbaarheidsbeheer­sverplichtingen zijn echter wel van toepassing tijdens de ondersteunings­periode zodra het product in gebruik wordt genomen.

Een belangrijke verduidelijking betreft de “secure by default”-vereiste. Deze verplichting is alleen van toepassing op componenten die afzonderlijk op de markt worden gebracht, niet op hoe die componenten later worden geconfigureerd of ingezet door integrerende fabrikanten.

Dit creëert een interessante marktdynamiek. Het zal gemakkelijker zijn om producten te assembleren en componenten buiten de EU te integreren, en dan alleen het uiteindelijke PDE op de Europese markt te brengen. Onder deze aanpak hoeven individuele componenten niet aan de essentiële vereisten te voldoen, inclusief secure by default, zolang het eindproduct dat maar doet. De last wordt daarom verschoven naar de uiteindelijke integrator. Dit kan supply chain-strategieën beïnvloeden, om EU-regulering grotendeels te omzeilen.

Gerelateerd hieraan bevestigt de FAQ dat integrerende fabrikanten niet verplicht zijn ervoor te zorgen dat alle componenten die in hun producten worden gebruikt, onafhankelijk aan elke essentiële vereiste voldoen. De verantwoordelijkheid van de fabrikant treedt in werking wanneer ze het product op de markt brengen. Fabrikanten zullen een due diligence-beoordeling van de componenten moeten uitvoeren om ervoor te zorgen dat het uiteindelijke PDE voldoet aan de essentiële vereisten.

De FAQ hanteert een pragmatische, risicogebaseerde benadering van kwetsbaarheidsbeheer die welkom nieuws zal zijn voor veel fabrikanten.

De FAQ stelt dat fabrikanten niet verplicht zijn een patch te leveren voor alle ontdekte kwetsbaarheden. Afhankelijk van “exploiteerbaarheids”­niveaus, kan het niet nodig zijn om een afzonderlijke update te implementeren als er in de praktijk geen werkelijk risico bestaat dat de kwetsbaarheid wordt geëxploiteerd. Het stelt wel dat elke ontdekte kwetsbaarheid op de een of andere manier moet worden verholpen, maar dat een patch mogelijk niet altijd de meest geschikte oplossing is. In gevallen met zeer laag risico stelt de FAQ dat het documenteren van de kwetsbaarheid en het verstrekken van aanbevelingen aan gebruikers voldoende kan zijn in termen van herstel. Deze risicogebaseerde benadering van herstel is een welkom instrument voor fabrikanten.

In dezelfde trend moeten herroepingen van producten vanwege onherstelbare kwetsbaarheden uitzonderlijk zijn, alleen vereist wanneer de kwetsbaarheid een zeer significant risico op exploitatie vormt. Dit sluit aan bij het principe dat niet elke kwetsbaarheid de meest extreme reactie vereist.

Een bijzonder belangrijke verduidelijking betreft producten die componenten integreren die oorspronkelijk niet op de EU-markt zijn gebracht, of componenten die op de markt zijn gebracht voordat de CRA van toepassing werd. In deze gevallen is de integrerende fabrikant zelf belast met het aanpakken van de kwetsbaarheden in die componenten. De component­fabrikant heeft geen verplichting om te helpen, aangezien deze niet binnen de reikwijdte van de CRA valt. Hetzelfde principe geldt wanneer de ondersteunings­periode van een component is geëindigd, maar de ondersteunings­periode van het geïntegreerde product doorloopt.

Dit creëert een substantiële verantwoordelijkheid voor integrerende fabrikanten. Ze moeten due diligence uitvoeren bij het selecteren van componenten en bereid zijn om langetermijn­kwetsbaarheidsbeheer op zich te nemen voor componenten waarvan de oorspronkelijke fabrikanten ze mogelijk niet langer ondersteunen.

De FAQ verduidelijkt de meldings­vereisten wanneer kwetsbaarheden worden ontdekt in geïntegreerde componenten. Als er een actief geëxploiteerde kwetsbaarheid in een component is, moeten zowel de PDE-fabrikant als de component­fabrikant melding doen. Als er echter een kwetsbaarheid bestaat maar deze niet actief wordt geëxploiteerd, moet de integrerende fabrikant de component­fabrikant op de hoogte stellen, maar is deze niet verplicht om eindgebruikers op de hoogte te stellen.

Eén gebied waar de FAQ wel opluchting biedt: fabrikanten hebben geen plicht om continue monitoring van kwetsbaarheden uit te voeren of er actief naar te scannen. Hoewel fabrikanten kwetsbaarheden verantwoordelijk moeten afhandelen wanneer ze zich ervan bewust worden, is er geen verplichting om constant toezicht te houden op mogelijke beveiligings­problemen.

De FAQ maakt duidelijk dat fabrikanten gedurende de gehele product­levenscyclus substantiële verplichtingen hebben. De last is bijzonder zwaar tijdens de ontwerp- en ontwikkelings­fase, met zijn veeleisende risicobeoordeling­svereisten, maar zoals de FAQ benadrukt, zijn de verplichtingen tijdens de onderhouds- en ondersteunings­periode even significant.

Dit is slechts het begin van de begeleidings­inspanningen van de Commissie. Artikel 26 van de CRA schrijft aanvullende richtsnoeren voor over verschillende onderwerpen, waaronder de reikwijdte van de verordening met bijzondere nadruk op oplossingen voor gegevensverwerking op afstand en vrije en open-source software, de toepassing van ondersteunings­perioden voor bepaalde productcategorieën, richtsnoeren voor fabrikanten die onder zowel de CRA als andere EU-harmonisatie­wetgeving vallen, en het concept van substantiële wijziging.

Hoewel deze FAQ de wisselwerking met andere harmonisatie­wetgeving tot op zekere hoogte behandelt, blijven er hiaten bestaan. Fabrikanten die bijvoorbeeld onder zowel de Machinerichtlijn als de CRA werken, zouden baat hebben bij duidelijkere richtsnoeren over hoe technische documentatie en risicobeoordeling­svereisten over beide kaders moeten worden afgestemd.

Fabrikanten moeten nu beginnen met voorbereiden op deze veeleisende vereisten, vooral als ze componenten produceren die in andere producten kunnen worden geïntegreerd of als ze zelf componenten van derden integreren. De dagen van cyberbeveiliging als bijzaak zijn definitief voorbij onder het CRA-regime.

Auteurs

Wout Platteau en Pedro Demolder