Cyber Resilience Act krijgt handen en voeten

Bijna twee jaar voor het in werking treden van de Cyber Resilience Act (CRA) begint duidelijker te worden voor welke producten die in welke mate van toepassing is en hoe je de naleving ervan moet borgen. Ondertussen werken onder de vlag van CEN/CENELEC en ETSI tal van werkgroepen aan geharmoniseerde normen die het gemakkelijker maken om aan te tonen dat je met je producten aan de CRA voldoet. Romain Tesnière, Business Development Manager EMEA Solution Sales van Avnet Silica, presenteerde op de afgelopen Tech Day in Breda de laatste stand van zaken.

De Cyber Resilience Act (CRA) van de Europese Unie is een belangrijke stap voorwaarts op het gebied van cyberbeveiliging. Hierin worden strenge eisen gesteld aan de cybersecurity van hardware- en softwareproducten met digitale elementen, die bestemd zijn voor de EU-markt. Deze verordening is bedoeld om ervoor te zorgen dat producten vrij zijn van bekende kwetsbaarheden en dat ze gedurende hun hele levenscyclus beveiligd blijven. Belangrijk hierbij is dat fabrikanten verantwoordelijk blijven voor cybersecurity.

Grosso modo bevat de CRA de geharmoniseerde regels voor het op de markt brengen van de betreffende hard- en softwareproducten, de essentiële cybersecurity-eisen voor productontwerp en -ontwikkeling en de regels voor het handhaven van cybersecurity gedurende de volledige levenscyclus.

11 december 2027

De CRA is al vanaf 11 december 2024 van kracht, maar echt menens wordt het precies drie jaar daarna: op 11 december 2027. Vanaf die dag is compliance met de CRA verplicht. Niet-naleving kan leiden tot boetes, die kunnen oplopen tot 15 miljoen euro of 2,5% van de jaaromzet van de fabrikant.

Nieuw en oud

Goed om te weten is dat de CRA niet alleen van toepassing is op producten die na 11 december 2027 voor het eerst op de Europese markt worden gebracht. Ook oudere producten, die nog steeds worden geproduceerd (en in die hoedanigheid op ‘op de markt worden aangeboden’ in de vorm van distributie of verkoop aan eindklanten) moeten compliant zijn met de CRA als ze na die datum ‘een ingrijpende wijziging ondergaan, die gevolgen heeft voor de conformiteit met de essentiële cyberbeveiligingsvereisten’. Voor alle producten, ook de oudere die niet zijn gewijzigd, geldt sowieso de in artikel 14 van de verordening beschreven verplichting van rapportage van elke actief uitgebuite kwetsbaarheid.

Dat lijkt op het eerste gezicht nogal uitdagend. “Maar”, stelde Romain Tesnière tijdens de Avnet Silica Tech Day afgelopen december in Breda, “de CRA komt niet met nieuwe eisen op het gebied van cyberbeveiligingstechnologie. De regelgeving refereert aan ‘best practices’, die ieder bedrijf dat serieus werk maakt van cyberbeveiliging al lang toepast. En vergeet niet dat ook in andere verordeningen eisen zijn opgenomen of aangescherpt. Zo zijn vanaf 1 augustus 2025 nieuwe, strengere eisen op het gebied van cyberbeveiliging binnen de Radio Equipment Directive (RED) van kracht geworden voor draadloze apparaten, zoals IoT-apparatuur.”

Wat wel, en wat niet?

De producten die aan de CRA moeten voldoen zijn in vier categorieën ingedeeld. Op 28 november 2025 is de technische beschrijving van deze vier productclassificaties gepubliceerd. Samenvattend zijn dat:

• ‘Kritieke producten’. Dit zijn producten met een zeer hoog risico op negatieve gevolgen, die ook nog eens een zeer grote impact hebben. Dat zijn volgens bijlage IV van de CRA hardwareapparaten met beveiligingskastje, gateways voor slimme meters en andere apparaten voor geavanceerde beveiligingsdoeleinden (onder meer voor beveiligde cryptoverwerking) en smartcards of soortgelijke apparaten, met inbegrip van secure elements.
• ‘Belangrijke producten – klasse II’. Dit zijn producten met een hoog risico op negatieve gevolgen met een grote impact. Voorbeelden zijn hypervisors en container runtimesystemen die de gevirtualiseerde uitvoering van besturingssystemen en soortgelijke omgevingen ondersteunen, firewalls en manipulatiebestendige MCU’s en MPU’s.
• ‘Belangrijke producten – klasse I’. Dit zijn producten met een gemiddeld risico op negatieve gevolgen met een gemiddelde impact. Deze categorie telt veel meer producten dan de twee met hogere risico’s, met onder meer software en hardware voor identiteitsbeheersystemen, producten voor wachtwoordbeheer, VPN’s, PKI-diensten, besturingssystemen, routers, modems, beveiligde MCU’s en beveiligde MPU’s. Ook slimme thuisproducten met beveiligingsfuncties, zoals sloten, camera’s en alarmen vallen hieronder, evenals speelgoed dat met het internet is verbonden en persoonlijke wearables voor gezondheidsmonitoring. 
• ‘Standaard’. Deze classificatie geldt voor de circa 90% van alle producten met een digitaal element, namelijk de producten die geen specifieke beveiligingsfunctie hebben. Voorbeelden zijn fotobewerkingssoftware, slimme luidsprekers, videospelletjes en harde schijven. 

Belangrijk hierbij is te melden dat het altijd gaat om eindproducten vanuit het perspectief van de fabrikant. Dan kan het dus gaan om bijvoorbeeld microcontrollers van een elektronicafabrikant, maar ook om gateways van een apparatenbouwer, waarin microcontrollers en vele andere componenten zijn verwerkt. Een TPM (trusted platform module) is een kritiek product, maar een apparaat dat een TPM bevat kan zijn ingedeeld bij klasse II, klasse I of standaard.

Overal dezelfde eisen

Ongeacht de categorie waarin je product is ingedeeld zijn de cyberbeveiligingseisen, zoals opgesomd in bijlage I van de CRA, hetzelfde. Zo moeten fabrikanten uitgebreide details over hun producten registreren. Dit omvat het duidelijk definiëren van de software- en hardwarematige BoM. Verder moeten ze een gedetailleerde inventarisatie maken van alle geharmoniseerde EU-cybersecuritynormen waaraan het product voldoet en diepgaande risicobeoordelingen uitvoeren voor zowel de OEM als de eindgebruiker. Het is ook noodzakelijk dat de fabrikanten de aard van de gebruikte software bekendmaken –of deze nu open source of bedrijfseigen is– en zich gedurende de gehele levensduur van het product committeren aan een regime van voortdurende waakzaamheid, waarbij de markt proactief wordt geïnformeerd over eventuele beveiligingslekken.

De CRA schrijft fabrikanten ook voor om te voorzien in upgrades, via een een bekabelde of draadloze verbinding. De OEM is immers verantwoordelijk voor het in stand houden van de beveiliging van het product gedurende de gehele levenscyclus. In dat kader is het ook zaak om gedurende de levenscyclus de securityfuncties van het product te verbeteren. Het upgrademechanisme moet beveiligd zijn, waarbij de OEM de integriteit en vertrouwelijkheid van de firmware bewaakt.

Beoordeling conformiteit

Voor het beoordelen van de conformiteit met de CRA zijn de volgende vier procedures aangegeven:

• Module A: interne controle. Hierbij verzorgt de fabrikant een zelfbeoordeling op basis van technische documentatie en testrapportages. Er is geen externe partij (notified body) nodig.
• Module B: EU-type onderzoek. Hierbij zorgt de fabrikant voor de technische documentatie en testresultaten, maar wordt de beoordeling en certificering hiervan gedaan door een notified body. 
• Module C: op basis van interne productiecontrole. Hierbij beoordeelt de fabrikant zelf op basis van module B de productiekant van het product. Hij hoeft hier dus geen notified body voor in te schakelen. Module B en C vullen elkaar dus aan, maar het zijn wel procedures die voor ieder product moeten worden doorlopen.
• Module H: op basis van volledige kwaliteitsborging. De fabrikant laat door een notified body het hele proces certificeren, vanaf productontwerp en productie tot het in stand houden van de veiligheidsfuncties tot het einde van de levensduur van het product. Dit is een uitkomst voor bedrijven, die grote aantallen verschillende producten op de markt brengen. Elk nieuw product voldoet dan aan de CRA-normen omdat je voldoet aan Module H. Uiteraard vinden er regelmatig audits plaats om te bepalen of de certificering nog steeds terecht is.

Verschillen in beoordeling conformiteit

Het verschil tussen de vier productcategorieën zit hem in de procedures om de conformiteit met de CRA vast te stellen. 

• Bij ‘standaard’ volstaat een zelfbeoordeling (module A).
• Bij ‘belangrijke producten – klasse I’ kan je kiezen voor het toepassen van module A voor het uitvoeren van een zelfbeoordeling aan een op dit moment nog in ontwikkeling zijnde geharmoniseerde norm van het betreffende product. Of een notified body inschakelen voor module B+C of module H.
• Bij ‘belangrijke producten – klasse II’ moet je altijd langs een notified body (module B+C of module H).
• Bij ‘kritieke producten’ moet de certificering verlopen via de EUCC (European CC-based cybersecurity certification scheme), dat is gebaseerd op de Common Criteria (ISO/IEC 15408) standaard. Wanneer een specifiek EUCC-schema (nog) niet beschikbaar is voor een bepaald product, moet hiervoor een notified body worden ingeschakeld.

Open source software

Werkelijk gratis open source software (dus niet een betaald product dat is gemaakt met open source software) valt niet onder de CRA. Als er wel geld voor wordt gevraagd, dan moet deze wel voldoen aan de CRA en volstaat een zelfbeoordeling (module A).

Aan de slag

Bovenaan op het to-do lijstje dat Romain Tesnière in zijn presentatie liet zien staat het lezen van de CRA, die je hier kan downloaden. Op basis daarvan kan je de productcategorie(ën) en compliance strategie(ën) bepalen voor jouw producten. Het meeste werk gaat hem zitten in de documentatie: risicobeoordeling van cyberrisico’s gedurende de hele levenscyclus, de hard- en software BoM (een overzicht van alle componenten om kwetsbaarheden in de toeleveringsketen te beheren), hoe om te gaan met beveiligingsinbreuken (vulnerability management) en secure-by design: de documentatie die bewijst dat beveiliging vanaf de ontwerpfase is geïntegreerd. Daarbij komt ook de productiestrategie om de hoek kijken, inclusief secure provisioning.

Ondersteuning voor CRA-naleving

Afgezien van het lezen van de CRA, dat je toch zelf zal moeten doen, kan je voor het hele proces om met je product(en) aan de CRA te voldoen ondersteuning krijgen door bedrijven als Avnet Silica. Witeco, een dochterbedrijf van Avnet, kan worden ingeschakeld voor de risicobeoordelingen. De specialisten van Avnet Silica kunnen helpen bij onder meer het bepalen van de productclassificaties en het samenstellen van de BoM, met name secure elements (companion chips voor authenticatie, encryptie/decryptie en veilige opslag van sleutels en certificaten) en veilige MCU’s en MPU’s voor embedded security.

Secure provisioning

Belangrijk aspect hierin is de productiestrategie: hoe zorg je voor secure provisioning? Ook hierin voorziet Avnet Silica met diensten als het genereren van sleutels, injecteren van publieke sleutels, root-of-trust provisioning met apparaatcertificaten en het verzamelen van ID-chips. Het Avnet Silica Warehouse biedt nauwkeurige controle over het secure provisioning proces, waarbij apparaten kunnen worden vergrendeld waarna de OEM de firmware kan uploaden. Deze gecentraliseerde one-stop-shop benadering (componenten en services in één) van secure provisioning is een uitkomst voor veel scenario’s, maar vereist wel dat personalisatie gereed is op het moment van programmeren. 

Voor OEM’s die de secure provisioning liever direct op hun productielijn of via de EMS-productielijn uitvoeren, biedt Avnet Silica de tops plug&go-oplossing. Dit is een compacte Hardware Security Module (HSM) die is uitgerust met de benodigde sleutels en certificaten om in het product te laden. Deze methode biedt de OEM meer flexibiliteit, maar vereist wel dat de EMS een product van derden in zijn systeem integreert, waarvoor mogelijk internettoegang nodig is.

Wanneer personalisatie niet geïntegreerd is tijdens de productie, wordt een late personalisatiestrategie toegepast in het veld. Agent-software in het IoT-apparaat maakt na initialisatie verbinding met de juiste PKI-cloudservice (Public Key Infrastructure), waarbij gebruik wordt gemaakt van platforms zoals EdgeLock 2GO van NXP of vergelijkbare diensten van strategische partners zoals Keyfactor.