Wat is de Cyber Resilience Act?
De Cyber Resilience Act (CRA) is een EU-verordening die verplichte cyberbeveiligingseisen stelt aan alle producten met digitale elementen die op de Europese markt worden verkocht. De wet is van toepassing op hardware en software gedurende de gehele levenscyclus, van ontwerp tot einde ondersteuning. Fabrikanten moeten standaard beveiliging inbouwen, een materiaallijst voor software bijhouden, actief omgaan met kwetsbaarheden en incidenten binnen strikte termijnen melden. De verordening is in december 2024 in werking getreden en wordt volledig afdwingbaar op 11 december 2027.
De CRA vult een gat dat eerdere regelgeving open liet. NIS2 vertelt organisaties hoe ze zichzelf kunnen beschermen. DORA vertelt financiële instellingen hoe ze hun operationele veerkracht moeten beheren. De CRA vertelt fabrikanten hoe ze veilige producten moeten maken. Als je iets maakt dat verbinding maakt met een netwerk en je verkoopt het in de EU, dan is deze verordening op jou van toepassing.
Voor fabrikanten in de Europese middenmarkt is 2026 het jaar waarin de voorbereiding omslaat in operationele realiteit. De rapportageverplichtingen beginnen in september 2026. Aangemelde instanties voor conformiteitsbeoordelingen moeten er in juni 2026 zijn. Wachten tot 2027 betekent dat je moet opboksen tegen deadlines die je concurrenten al hebben gehaald.
Wat de CRA vraagt van fabrikanten
De verordening definieert 21 vereisten die zijn gegroepeerd in twee categorieën: productbeveiligingseigenschappen en kwetsbaarheidsprocessen.
Beveiliging door ontwerp en standaard. Producten moeten geleverd worden in een veilige standaardconfiguratie. Onnodige poorten, diensten en functies moeten standaard worden uitgeschakeld. Authenticatie en toegangscontrole moeten ingebouwd zijn, niet achteraf toegevoegd. Gegevens in doorvoer en in rust moeten versleuteld worden. Veilige updatemechanismen moeten vanaf dag één beschikbaar zijn.
Kwetsbaarheidsbeheer gedurende de hele levenscyclus van het product. Fabrikanten moeten een ondersteuningsperiode definiëren waarbinnen ze zich verbinden tot het patchen van kwetsbaarheden. Het algemene minimum is vijf jaar. Dit omvat regelmatige beveiligingstests, een gecoördineerd proces voor het bekendmaken van kwetsbaarheden (CVD) voor externe onderzoekers en het bijhouden van een software stuklijst (SBOM) voor elk product.
Rapportage van incidenten en kwetsbaarheden. Vanaf 11 september 2026 moeten fabrikanten actief misbruikte kwetsbaarheden melden aan ENISA en nationale CSIRT’s. De tijdschema’s zijn strak:
| Type rapport | Deadline | Inhoud |
|---|---|---|
| Vroegtijdige waarschuwing | Binnen 24 uur | Eerste melding van actief misbruikt kwetsbaar punt of ernstig incident |
| Formele kennisgeving | Binnen 72 uur | Technische analyse, effectbeschrijving, herstelstappen |
| Eindverslag | Binnen 14 dagen | Analyse van de oorzaak en bevestiging van de beschikbare oplossing |
Voor een fabrikant in het middensegment van de markt met een klein IT-team en geen 24/7 centrum voor beveiligingsactiviteiten, vereist het voldoen aan deze tijdlijnen voorbereiding. Je hebt een Product Security Incident Response Team (PSIRT) nodig met duidelijke rollen, geautomatiseerde waarschuwingen en vooraf opgestelde meldingssjablonen voordat de deadline van september 2026 aanbreekt. Organisaties die hun beveiliging via één beheerconsole regelen, hebben hier een structureel voordeel. Wanneer toegangslogs, netwerkgebeurtenissen en beleidswijzigingen zich op één plek bevinden, wordt het samenstellen van een vroegtijdig waarschuwingsrapport binnen 24 uur een proces in plaats van een gevecht. Het SASE-platform van Jimber, bijvoorbeeld, legt deze gegevenspunten centraal vast, wat betekent dat je PSIRT zijn tijd besteedt aan het analyseren van het incident in plaats van het correleren van logs uit vijf afzonderlijke tools.
Conformiteitsbeoordeling. Voordat een product op de markt wordt gebracht, moeten fabrikanten aantonen dat het product aan de eisen voldoet. De beoordelingsroute hangt af van de risicoclassificatie van het product.
Welke producten worden gedekt (en welke niet)
De CRA is van toepassing op elk “product met digitale elementen” (PDE), gedefinieerd als hardware of software waarvan het beoogde gebruik een directe of indirecte verbinding met een apparaat of netwerk inhoudt. Die definitie is opzettelijk breed.
De verordening deelt producten in vier risiconiveaus in:
| Categorie | Voorbeelden | Beoordelingsroute |
|---|---|---|
| Standaard (~90% van de producten) | Slimme thuisapparaten, aangesloten speelgoed, kantoorsoftware, Bluetooth-luidsprekers | Zelfbeoordeling (module A) |
| Belangrijke klasse I | VPN-software, wachtwoordbeheerders, routers, netwerkbeheersystemen | EU-typeonderzoek door aangemelde instantie (module B+C) |
| Belangrijke Klasse II | Firewalls, hypervisors, industriële robotbesturingen, sabotagebestendige microprocessoren | EU-typeonderzoek (module B+C) |
| Kritieke | Smart meter gateways, hardwarebeveiligingsmodules (HSM’s) | Volledige kwaliteitsborging of Europees certificeringsschema (module H) |
De juiste classificatie is belangrijk. Een fabrikant die een product van Klasse I zelf beoordeelt, riskeert opschorting van markttoegang en boetes. Als je iets produceert dat te maken heeft met netwerkbeveiliging, identiteitsbeheer of industriële besturing, controleer dan zorgvuldig de lijsten van Bijlage III en IV.
Wat buiten de CRA valt. Producten die al onder sectorspecifieke kaders vallen, zijn grotendeels uitgesloten: medische hulpmiddelen (MDR/IVDR), voertuigen (UNECE R155), luchtvaart en scheepsuitrusting. Open source software ontwikkeld buiten commerciële activiteiten is vrijgesteld, hoewel commerciële distributies van open source componenten dat niet zijn. Zuivere SaaS die volledig in de cloud wordt geleverd, valt buiten het toepassingsgebied, maar een downloadbare component of een on-premise element brengt het product weer binnen het toepassingsgebied.
Hoe de CRA past bij NIS2 en DORA
De CRA is de derde poot van het Europese regelgevingskader voor cyberbeveiliging. Elke verordening richt zich op een andere dimensie:
| CRA | NIS2 | DORA | |
|---|---|---|---|
| Focus | Productbeveiliging | Organisatiebeveiliging | Weerstand van de financiële sector |
| Voor wie | Fabrikanten, importeurs, distributeurs van digitale producten | Essentiële en belangrijke entiteiten in 18 sectoren | Banken, verzekeraars, beleggingsondernemingen, cryptoaanbieders |
| Wat het regelt | Hoe producten worden ontworpen, onderhouden en openbaar gemaakt | Hoe organisaties risico’s, toegang en incidenten beheren | Hoe financiële entiteiten ICT-risico’s van derden beheren |
| Uiterste datum | 11 sep 2026 (rapportage), 11 dec 2027 (volledig) | Actief in België sinds okt 2024 | Actief sinds jan 2025 |
| Boetes | Tot EUR 15M of 2,5% van de wereldwijde omzet | Tot EUR 10 miljoen of 2% van de wereldwijde omzet | Tot EUR 5M of 10% van de omzet voor providers |
Een fabrikant van industriële besturingen kan met alle drie te maken krijgen. De CRA is van toepassing op het product zelf. NIS2 is van toepassing als de fabrikant wordt geclassificeerd als een belangrijke entiteit. En DORA is indirect van toepassing: financiële instellingen die deze controllers gebruiken zullen producten eisen die voldoen aan de CRA als onderdeel van hun eigen DORA informatieregister.
Voor organisaties die al werken aan NIS2-compliance voor de middenmarkt is de overlap een voordeel. Risicobeoordelingsmethodologieën, inventarisaties van bedrijfsmiddelen en incidentresponsprocessen die zijn ontwikkeld voor NIS2 kunnen direct worden vertaald naar CRA-vereisten. Platforms zoals Jimber, die beveiligingscontroles consolideren in een enkel controleerbaar systeem, helpen organisaties door beide frameworks te navigeren zonder dubbel werk.
Waarom CRA-naleving begint op de fabrieksvloer
Dit is het gedeelte dat de meeste nalevingsgidsen over het hoofd zien. De CRA vereist dat je product veilig is. Maar een product dat gebouwd is in een gecompromitteerde productieomgeving is niet veilig, hoe goed je het ook ontworpen hebt.
Als een aanvaller toegang krijgt tot je build pipeline, firmware compilatieserver of infrastructuur voor softwaredistributie, kan hij kwaadaardige code in je product injecteren voordat het de fabriek verlaat. Dit is niet theoretisch. Supply chain aanvallen op SolarWinds, Kaseya en 3CX volgden precies dit patroon.
Voor fabrikanten van verbonden producten is het beveiligen van de productieomgeving niet alleen een goede gewoonte, maar ook een vereiste voor naleving van de CRA-richtlijnen. Je moet aantonen dat de integriteit van je product tijdens het hele productieproces is gehandhaafd.
Dit is waar de beveiliging van productienetwerken direct relevant wordt. Het SASE-platform van Jimber richt zich op de specifieke uitdagingen van fabrikanten:
Netwerksegmentatie tussen IT en OT. Het bedrijfsnetwerk waar e-mail en ERP draaien moet strikt worden gescheiden van de productieomgeving waar firmware wordt gecompileerd en geflashed. SD-WAN en FWaaS van Jimber dwingen deze scheiding af met identiteitsgebaseerde beleidsregels die vanaf één console worden beheerd. Een uitbraak van ransomware op kantoor mag nooit de gebouwde servers bereiken.
Zero Trust toegang tot productiesystemen. Alleen geautoriseerde technici zouden in staat moeten zijn om productfirmware of software te wijzigen. Zero Trust Network Access van Jimber verleent per toepassing toegang op basis van gebruikersidentiteit en apparaatstatus, niet op basis van netwerklocatie. Elke toegangsbeslissing wordt vastgelegd met een volledig controletraject.
Inline isolatie voor agentloze productieapparatuur. PLC’s, HMI’s en flashstations kunnen geen beveiligingsagenten uitvoeren. De NIAC-hardware van Jimber bevindt zich inline tussen deze apparaten en het netwerk en dwingt het communicatiebeleid per apparaat af zonder het apparaat zelf aan te raken. Een gecompromitteerde laptop op het IT-netwerk raakt een muur voordat hij productieapparatuur bereikt. De SASE voor productiehandleiding beschrijft de technische implementatie in detail.
Gecentraliseerde registratie voor auditbewijs. Conformiteitsbeoordelingen van CRA’s zullen vragen hoe u de integriteit van de productie waarborgt. Een enkele beheerconsole die elke toegangsbeslissing, beleidswijziging en apparaatcommunicatiestroom logt, levert het bewijspad dat auditors verwachten.
Vijf stappen om je voor te bereiden op CRA-naleving
Stap 1: evalueer de hiaten ten opzichte van bijlage I
Maak een lijst van alle producten in uw portefeuille die digitale elementen bevatten. Deel elk product in volgens de risicograad van het Bureau. Breng vervolgens uw huidige beveiligingspraktijken in kaart ten opzichte van de 21 vereisten in Bijlage I.
De CRACy-compliance tool van Jimber is speciaal voor dit doel ontwikkeld als onderdeel van een door de EU gesteund initiatief. De tool vertaalt de abstracte Annex I-vereisten naar concrete technische controles, identificeert hiaten en helpt bij het prioriteren van herstelmaatregelen. Voor KMO’s zonder een speciaal compliance-team vervangt deze gestructureerde aanpak maanden van handmatige interpretatie.
Stap 2: bouw en onderhoud je SBOM
Een materiaallijst voor software documenteert elke component in je product: bibliotheken, frameworks, open-source afhankelijkheden en hun versies. Gebruik gestandaardiseerde formaten zoals CycloneDX of SPDX. Werk de SBOM bij elke release bij.
De SBOM is niet alleen een nalevingsdocument. Het is uw waarschuwingssysteem. Wanneer er een nieuwe kwetsbaarheid opduikt in een veelgebruikte library (zoals met Log4j in 2021), vertelt een up-to-date SBOM je binnen enkele uren of je producten getroffen zijn.
Stap 3: de openbaarmaking van kwetsbaarheden en de reactie op incidenten instellen
Een gecoördineerd proces voor het melden van kwetsbaarheden opzetten vóór september 2026. Externe onderzoekers hebben een duidelijke, gedocumenteerde manier nodig om kwetsbaarheden te melden. Definieer intern je PSIRT met benoemde rollen, escalatiepaden en vooraf opgestelde meldingssjablonen die voldoen aan de 24/72/14-dagen rapportagevereisten.
De kwaliteit van uw incidentrespons hangt af van hoe snel u kunt bepalen wat er is gebeurd. Als je beveiligingsarchitectuur toegangsbeslissingen, evaluaties van de apparaatstatus en netwerkstromen in één tijdlijn registreert, wordt de analyse van de hoofdoorzaak aanzienlijk versneld. Dit is een van de praktische redenen waarom fabrikanten die consolideren op een uniform SASE-platform, zoals Jimber, de voorbereiding op incidentrespons gemakkelijker kunnen operationaliseren.
Stap 4: beveiligingstests uitvoeren
Regelmatige penetratietests en geautomatiseerde scans op kwetsbaarheden moeten zowel het product als de productieomgeving bestrijken. Update mechanismen testen om te bevestigen dat er niet mee geknoeid kan worden. Valideer dat standaardconfiguraties daadwerkelijk veilig zijn.
Stap 5: je conformiteitsdocumentatie voorbereiden
Voor producten in de standaardcategorie is interne documentatie volgens module A voldoende. Voor belangrijke producten van klasse I en II hebt u een aangemelde instantie nodig. Deze instanties worden gedurende heel 2026 aangewezen en de capaciteit zal beperkt zijn. Boek vroeg om vertragingen te voorkomen die uw markttoegang in 2027 zouden kunnen blokkeren.
Je technische dossier moet de risicobeoordeling, testresultaten, SBOM, procedures voor het omgaan met kwetsbaarheden en bewijs van security-by-design processen bevatten. De inspanning die nodig is om dit bewijs samen te stellen varieert enorm, afhankelijk van uw beveiligingsarchitectuur. Een fabrikant die vijf verschillende tools gebruikt, moet logs van elk tool verzamelen, correleren en vergelijken. De enkele beheerconsole van Jimber genereert een uniform auditspoor dat toegangscontrole, netwerksegmentatie en apparaatcommunicatiestromen omvat in één exporteerbare dataset. Dat verschil kan de voorbereiding van documentatie terugbrengen van maanden tot weken.
Belgische en Benelux-context
Het Centre for Cybersecurity Belgium (CCB) speelt een centrale rol bij de implementatie van de CRA. Als nationaal CSIRT ontvangt het CCB incidentmeldingen en houdt het toezicht op de certificeringsprocessen.
Het SECURE-project. De EU heeft financiering gelanceerd die specifiek bedoeld is om KMO’s te helpen bij de naleving van de CRA-normen. Belgische bedrijven kunnen subsidies aanvragen tot 30.000 euro, ter dekking van 50% van de kosten voor risicobeoordelingen, SBOM-ontwikkeling en beveiligingstests. Het eerste aanvraagvenster liep tot maart 2026, maar er worden extra oproepen verwacht.
CyberFundamentals (CyFun) overlap. Belgische fabrikanten die al bezig zijn met de zelfevaluatie van CyFun zullen een aanzienlijke overlap vinden met de vereisten van CRA. CyFun omvat veel van dezelfde technische controles, met name rond toegangsbeheer, incidentafhandeling en inventarisatie van bedrijfsmiddelen. CyFun-certificering staat niet gelijk aan CRA-conformiteit, maar het biedt een sterke basis. Organisaties die hun CyFun-bewijsverzameling uitvoeren via een geconsolideerd platform zoals Jimber, kunnen veel van die documentatie hergebruiken voor CRA-doeleinden. De toegangslogs, segmentatiepolicies en apparaatinventarissen die voldoen aan de Protect-functie van CyFun kunnen direct worden gekoppeld aan de controles van de productieomgeving die de CRA verwacht. De NIS2 compliance checklist brengt specifieke controles in kaart die van toepassing zijn op alle drie de raamwerken.
Straffen. Niet-naleving van de vereisten van Bijlage I kan boetes opleveren tot 15 miljoen euro of 2,5% van de wereldwijde jaaromzet. Voor het niet voldoen aan de rapportageverplichtingen geldt hetzelfde maximum. Regelgevers kunnen ook eisen dat producten worden teruggeroepen of uit de handel worden genomen, wat voor de meeste fabrikanten schadelijker is dan welke boete dan ook.
FAQ
Wanneer wordt de Cyber Resilience Act van kracht?
De CRA is op 10 december 2024 in werking getreden. Rapportageverplichtingen voor actief misbruikte kwetsbaarheden beginnen op 11 september 2026. De volledige handhaving, inclusief conformiteitsbeoordelingen en CE-markeringsvereisten, begint op 11 december 2027.
Is de CRA van toepassing op software?
Ja. De CRA heeft betrekking op zowel hardware- als softwareproducten met digitale elementen, inclusief standalone software die gedistribueerd wordt voor gebruik op eindgebruikersapparaten. Zuivere SaaS die volledig in de cloud wordt geleverd is uitgesloten, maar elk downloadbaar onderdeel of client-side element brengt het product binnen het toepassingsgebied.
Wat is een SBOM en waarom heeft het CRA er een nodig?
Een software bill of materials (SBOM) is een machineleesbare inventaris van elk onderdeel in je product, inclusief open-source bibliotheken, modules van derden en hun versies. De CRA heeft een SBOM nodig omdat moderne software meestal uit 75% of meer externe componenten bestaat. Een kwetsbaarheid in een van deze componenten heeft invloed op uw product. De SBOM maakt die toeleveringsketen transparant.
Hoe overlappen CRA en NIS2 elkaar?
De CRA regelt de beveiliging van producten die u maakt. NIS2 regelt de beveiliging van uw organisatie. Een fabrikant die is geclassificeerd als een belangrijke entiteit onder NIS2 moet aan beide voldoen. De praktische overlap is aanzienlijk: risicobeoordeling, reactie op incidenten, toegangscontrole en beheer van de toeleveringsketen komen in beide raamwerken voor. Het voltooien van CyFun of ISO 27001 voor NIS2 geeft u een voorsprong op de organisatorische vereisten van CRA.
Heeft de CRA invloed op mijn productieomgeving?
Ja. De CRA vereist van fabrikanten dat ze de integriteit van hun producten waarborgen gedurende de gehele levenscyclus, inclusief tijdens de productie. Een gecompromitteerde productieomgeving kan kwetsbaarheden injecteren in anders goed ontworpen producten. Het beveiligen van build pipelines, firmware servers en productienetwerken met Zero Trust controles en netwerksegmentatie is onderdeel van het aantonen van CRA-naleving. Voor productieapparatuur die geen beveiligingsagenten kan uitvoeren, kan inline isolatiehardware zoals NIAC van Jimber het communicatiebeleid per apparaat afdwingen zonder de activiteiten te verstoren.
Kan ik financiële steun krijgen voor naleving van de CRA-regels in België?
Het door de EU gefinancierde SECURE-project biedt Belgische kmo’s subsidies tot 30.000 euro, die 50% van de in aanmerking komende kosten voor activiteiten in verband met de naleving van de regelgeving inzake ratingbureaus dekken. Aanvullende nationale en regionale programma’s, waaronder de KMO-portefeuille, kunnen advieskosten in verband met cyberbeveiligingscertificering en -naleving dekken.
De Cyber Resilience Act verandert de basis voor elke fabrikant die connected producten verkoopt in Europa. Naleving is niet optioneel en de tijdlijnen zijn dichterbij dan ze lijken. Fabrikanten die nu investeren in veilige ontwikkelingspraktijken, beveiliging van de productieomgeving en gestructureerde nalevingsdocumentatie zullen de deadline van 2027 halen zonder in paniek te raken. Wie wacht riskeert vertragingen bij de markttoegang, boetes en de reputatieschade die onvoorbereidheid met zich meebrengt. Klaar om je productieomgeving te beveiligen voor CRA-compliance? Boek een demo en ontdek hoe het SASE-platform van Jimber de infrastructuur beschermt waar je producten worden gebouwd.
