Cyber Resilience Act (CRA) 2026–2027: wat we al weten, wat er nog ontbreekt en hoe je een product realistisch voorbereidt — voordat de geharmoniseerde normen verschijnen

Wat we vandaag zeker weten (en waarom dit geen “onderwerp voor 2027” is)

De Cyber Resilience Act kan overkomen als weer zo’n document “uit Brussel” dat je gerust tot later kunt laten liggen. Dat is een natuurlijke reactie, zeker als een bedrijf leeft op het ritme van projecten: prototype, implementatie, serieproductie, service. Regelgeving komt vaak binnen als een “eindvereiste” — iets wat je pas op de finish nog even afvinkt. CRA draait die logica om, omdat het niet alleen gaat over wat je op de verkoopdag aan het product kunt zien. Het gaat erom of de fabrikant de beveiliging van het product in de tijd kan borgen en kan aantonen dat dit bewust is gedaan, en niet toevallig.

Het belangrijkste feit is eenvoudig, maar heeft strategische gevolgen: CRA is productregelgeving, ingebed in de werking van de EU-markt (inclusief CE-markering). De Europese Commissie zegt expliciet dat producten een CE-markering moeten dragen als signaal van conformiteit met CRA, en dat de handhaving bij de markttoezichtautoriteiten ligt. Dit is dus geen “IT-standaard” die je kunt behandelen als een intern verbeterprogramma. Het is een kader dat bepaalt of je überhaupt mag verkopen.

Data die het denken ordenen

In de tekst van Verordening (EU) 2024/2847 zelf is te zien dat de toepassing gefaseerd is. CRA is van toepassing vanaf 11 december 2027, maar met duidelijke uitzonderingen. Artikel 14 (rapportage) geldt vanaf 11 september 2026, en het hoofdstuk over de notificatie van conformiteitsbeoordelingsinstanties (Chapter IV) vanaf 11 juni 2026. Dit zijn drie data die je het best als “mijlpalen” kunt behandelen, omdat ze overeenkomen met drie verschillende soorten gereedheid: operationeel, institutioneel en productmatig.

De Commissie communiceert het nog eenvoudiger: CRA is in werking getreden op 10 december 2024, de kernverplichtingen gelden vanaf 11 december 2027, en de rapportage vanaf 11 september 2026. Als iemand in het bedrijf zegt “we hebben tijd tot 2027”, bedoelt die meestal de ontwerpeisen en de conformiteitsbeoordeling. Maar rapportage komt eerder en gaat over gebeurtenissen die niet wachten op een planning.

Rapportage: een verplichting die een proces afdwingt (geen document)

De rapportageplicht is een goede lakmoesproef, omdat die laat zien hoe CRA “productcybersecurity” begrijpt. Het is geen intentieverklaring en geen “beleid”. Het is een proces dat moet werken onder druk: wanneer er een actief misbruikte kwetsbaarheid opduikt of een ernstig incident.

De Commissie beschrijft dit ondubbelzinnig: de fabrikant moet actief misbruikte kwetsbaarheden en severe incidents melden die de beveiliging van het product beïnvloeden. Er is een “early warning” vereist binnen 24 uur nadat men ervan op de hoogte is, een volledige melding binnen 72 uur, en een eindrapport: binnen 14 dagen nadat een herstelmaatregel beschikbaar is voor actief misbruikte kwetsbaarheden en binnen een maand voor severe incidents.

In de praktijk betekent dit dat een organisatie meer nodig heeft dan een checklist. Ze heeft een mechanisme nodig dat drie vragen beantwoordt: hoe komen we te weten dat het probleem bestaat; wie kwalificeert of het al “actief misbruikt” of “severe” is; en hoe organiseren we de informatievoorziening en de fix binnen een tijdsvenster dat geen ruimte laat voor improvisatie.

Als er tijdens trainingen chaos ontstaat, komt dat vaak doordat CRA precies in het gat tussen IT en het product valt. Voor IT is een “incident” vaak een gebeurtenis in de infrastructuur. Voor een fabrikant is een “incident” een gebeurtenis die het product bij de klant raakt: versie, configuratie, wijze van implementatie. CRA dwingt die werelden samen tot één verantwoordelijkheid.

Wat CRA omvat: het product als relatie met het netwerk, niet als “apparaat op tafel”

In de praktijk hebben we bij risicobeoordelingen van machines geleerd dat risico geen eigenschap van de machine zelf is — het ontstaat in de relatie mens–machine. In CRA verschuift het perspectief op een vergelijkbare manier: beveiliging zit niet “in het apparaat”, maar in de relatie van het product met de digitale omgeving, de manier van gebruik en het vermogen van de fabrikant om te reageren.

De Commissie wijst, in haar samenvatting van CRA, op de definitie van “producten met digitale elementen” en op het feit dat de rapportageverplichtingen gelden voor alle dergelijke producten die op de EU-markt beschikbaar worden gesteld — ook voor producten die vóór 11 december 2027 op de markt zijn gebracht. Dat is een cruciale verduidelijking, omdat het een hardnekkige mythe wegneemt: “voor oude producten maakt dit niet uit”. Rapportage — wel.

Wat er nog niet is (geharmoniseerde normen) en waarom dat niet verlammend hoeft te werken

W gesprekken over CRA duikt vaak de zin op: “er zijn nog geen geharmoniseerde normen, dus we kunnen niets doen”. Dat klinkt logisch, maar er zit een verborgen valkuil in. Geharmoniseerde normen zijn een hulpmiddel dat het aantonen van conformiteit vergemakkelijkt (vermoeden van conformiteit), maar ze zijn niet de enige route om echte productveiligheid te realiseren. En ze zijn ook geen voorwaarde om nu al op de juiste manier te beginnen met ontwerpen.

De Commissie stuurt het onderwerp standaarden expliciet aan via de pagina “CRA Standardisation” en meldt dat zij standardisation request M/606 heeft aangenomen, met een pakket van 41 standaarden ter ondersteuning van CRA — zowel horizontale als verticale (productspecifieke). Dat is belangrijk, omdat het laat zien dat de EU het marktprobleem begrijpt: zonder standaarden gaan bedrijven conformiteit ieder op hun eigen manier invullen, en wordt markttoezicht lastiger.

Horizontale en verticale standaarden: wat betekent dat voor de fabrikant

Kort gezegd:

• horizontale standaarden beschrijven “hoe” je productveiligheid opbouwt en onderhoudt, los van de categorie (processen, methoden, een risicogebaseerde aanpak),
• verticale standaarden preciseren de eisen voor specifieke productklassen (waar risico’s en architecturen typisch zijn).

Dit onderscheid heeft praktische gevolgen. Als je een industrieel product maakt waarin een deel van de omgeving “OT” is en de levenscyclus lang is, dan heb je standaarden nodig die niet geschreven zijn voor een SaaS-applicatie. Precies daarom zijn verticale standaarden relevant: ze helpen om van algemene principes af te dalen naar wat je in echte architecturen concreet moet beheersen.

Planning: standaarden komen gefaseerd, niet “als één pakket vóór 2027”

De Commissie laat in materialen over de implementatie van CRA zien dat CRA gefaseerd wordt ingevoerd, en dat standaarden dit proces in de tijd moeten ondersteunen. Feitelijk staat vandaag vast: we hebben een formeel aangenomen verordening en we hebben een in gang gezet standaardisatiemechanisme (M/606).

Voor de praktijk is vooral één zin cruciaal: zelfs als een standaard door normalisatieorganisaties is uitgewerkt, ontstaat het “vermoeden van conformiteit” in juridische zin pas wanneer de verwijzing naar die norm als geharmoniseerde norm is gepubliceerd in het Publicatieblad van de EU. Dat is de vaste systematiek binnen de EU-harmonisatieaanpak: standaarden vormen de brug tussen wetgeving en engineeringpraktijk, maar die brug moet door de EU formeel worden “erkend”.

Voor de fabrikant betekent dit dat 2026–2027 een periode wordt waarin een deel van de bedrijven werkt op basis van eigen methoden om conformiteit aan te tonen (risk-based + bewijs), terwijl een ander deel zich al gaat spiegelen aan de standaarden die gaandeweg beschikbaar komen. En dat is normaal.

“Geen normen” betekent niet “geen verplichting” — het betekent zwaarder leunen op bewijs

Hieruit volgt een belangrijke consequentie: als er geen normen zijn die de eenvoudigste route bieden om conformiteit aan te tonen, neemt het belang toe van wat in auditpraktijk uiteindelijk altijd doorslaggevend is: een consistente beslis- en onderbouwingstraceerbaarheid.

Welke risico’s hebben we beoordeeld? Welke scenario’s hebben we als realistisch aangenomen? Hoe hebben we beschermingsmaatregelen gekozen? Hoe beheren we kwetsbaarheden? Hoe lang ondersteunen we het product? Hoe informeren we de klant? CRA vraagt niet dat een fabrikant “toekomstige EN-normen gaat raden”. Het vraagt dat de fabrikant kan laten zien dat beslissingen niet willekeurig waren, maar gebaseerd op risico en state of the art.

Hoe je een product in de praktijk voorbereidt op CRA (roadmap voor fabrikant en integrator)

De grootste waarde van CRA is dat het volwassenheid afdwingt: cybersecurity is niet langer een extraatje bij het product, maar wordt een eigenschap van het product zelf. Alleen ontstaat volwassenheid niet uit verklaringen. Ze komt voort uit een proces dat precies genoeg is om in de praktijk te werken, en tegelijk eenvoudig genoeg zodat engineering het niet gaat omzeilen.

Bij risicobeoordeling van machines ontstaan de beste ontwerpkeuzes wanneer we stoppen met vragen “welke gevaren heeft de machine” en beginnen met vragen “bij welke taken en in welke toestanden wordt de mens blootgesteld”. Bij CRA is het vergelijkbaar: we stoppen met vragen “welke kwetsbaarheden heeft het product” en beginnen met vragen “onder welke omstandigheden wordt het product blootgesteld en wat kan de fabrikant dan doen”. Die verschuiving brengt structuur in het werk.

Stap 1: Definieer het product als een systeem (niet als een apparaat)

Begin met het definiëren wat in jouw geval een “product met digitale elementen” is. Niet alleen hardware en firmware, maar ook wat vaak wordt weggelaten omdat het niet in de doos past: componenten, bibliotheken, update-mechanismen, diensten zonder welke het product zijn functie niet vervult. In CRA is dit belangrijk, omdat de verantwoordelijkheid van de fabrikant betrekking heeft op wat als product op de markt komt — en niet alleen op wat de mechanische afdeling heeft gemaakt.

Dit is ook het eerste moment waarop integratoren eerlijk naar zichzelf moeten zijn: als je componenten integreert en ze zó configureert dat er in de ogen van de klant een “eindproduct” ontstaat, dan ben je niet alleen een “implementatiepartij”. Je bent mede-ontwerper van het risico en mede-drager van de verantwoordelijkheid.

Stap 2: Voer de CRA-risicobeoordeling zo uit dat het een beslisinstrument is

Het gaat niet om een “matrix” op slides. Het gaat om een risicobeoordeling die leidt tot ontwerpkeuzes en die reproduceerbaar is.

In de praktijk begint een goede aanpak van CRA met een eenvoudige vraag: wat zijn de reële misbruikscenario’s in de omgeving van de klant, en niet alleen in het lab? Wie heeft servicetoegang? Hoe ziet het netwerk eruit? Hoe vaak updaten we? Wat zijn de gevolgen van stilstand? In de industrie zijn dit ongemakkelijkere vragen dan in IT, omdat de antwoorden vaak luiden: “we kunnen niet elke week updaten” of “we hebben geen telemetrie”. En precies daarom moet je ze stellen. CRA is wetgeving, maar de impact ervan zit in het ontwerp.

Krok 3: Bouw “vulnerability handling” als een productieproces, niet als een crisisreactie

De rapportage-eisen die door de Commissie zijn beschreven (24h/72h/14 dagen/maand) zijn genadeloos voor een organisatie zonder proces. Als je klaar wilt zijn voor 11 september 2026, moet je “vulnerability handling” behandelen als onderdeel van de productlevenscyclus, en niet als “een taak van het securityteam”.

Dat betekent:

• één kanaal voor het ontvangen van meldingen (CVD policy + contact),
• triage met een eigenaar en duidelijke criteria,
• een mechanisme voor het bouwen en uitrollen van security updates,
• een communicatiemodel richting klanten dat niet op improvisatie berust,
• rapportagegereedheid (wie meldt, met welke gegevens, hoe snel).

Dit klinkt allemaal als “organisatorisch” werk. In de praktijk is het productwerk, omdat het gaat over versies, compatibiliteit, update-architectuur en supportstrategie.

Krok 4: Kies de support period als een zakelijke beslissing, niet als een minimumeis

Als je producten in de industrie 10–15 jaar meegaan, dan is de support period strategisch. CRA dwingt af dat support geen loze belofte is. Dat betekent dat de support period moet voortkomen uit een analyse: hoe lang het product gebruikt zal worden, hoe de toeleveringsketen van componenten eruitziet, en hoe lang je in staat zult zijn om patches te leveren. In de praktijk gaat de support period het hele ecosysteem “meetrekken”: contracten met leveranciers, beschikbaarheid van de build environment, onderhoud van toolchains, en zelfs beslissingen over de vraag of een product remote functies heeft of juist geïsoleerd is.

Als je de support period als een formaliteit behandelt, kom je uiterlijk in 2027 in een conflict terecht: de klant verwacht support, maar jij hebt de middelen en afhankelijkheden niet meer om die te leveren. CRA creëert dit probleem niet — CRA maakt het alleen zichtbaar.

Krok 5: Breng de toeleveringsketen op orde: het gesprek met leveranciers is onderdeel van compliance

In CRA zit geen “magie” die externe componenten ineens veilig maakt. Als je apparaat leunt op bibliotheken, communicatiemodules, een besturingssysteem, SDK of hardwarecomponenten, dan hangt jouw risico rechtstreeks af van de kwaliteit van de praktijken van de leverancier.

Daarom is het verstandig om nu al het gesprek te voeren over zaken die niet als marketing klinken, maar als engineering:

• kan de leverancier voorspelbaar informeren over kwetsbaarheden,
• wat is de responstijd,
• is er een proces voor het publiceren van patches,
• kan de leverancier de component onderhouden gedurende een periode die aansluit op jouw support period.

Hier raakt CRA het bedrijfsbelang echt: een leverancier die kwetsbaarheden niet kan afhandelen, is niet “goedkoper”. Het is een regulatoir risico.

Krok 6: Bouw documentatie op als een consistente trace: wet → risico → beslissing → bewijs

Bij compliance-audits wint consistentie altijd. Als uit de risicobeoordeling blijkt dat een bepaalde interface kritisch is, maar de documentatie niet beschrijft hoe je die beveiligt; als je verklaart dat updates veilig zijn, maar niet kunt laten zien hoe je de integriteit van pakketten borgt; als je zegt dat je een proces voor kwetsbaarheden hebt, maar niet kunt aantonen hoe je meldingen triageert — dan is dat geen “gebrek aan papier”. Dan ontbreekt het bewijs dat het proces werkt.

Binnen CRA, bij het ontbreken van geharmoniseerde normen, is deze trace extra belangrijk. Want die vormt de basis voor het gesprek met de markttoezichthouder, met een enterprise-klant en, in sommige productcategorieën, ook met de conformiteitsbeoordelingsinstantie. En minstens zo belangrijk: het is de basis voor interne stabiliteit. Het team weet waarom we iets doen, en niet alleen “dat het moet”.

Afsluiting: CRA als nieuwe ontwerpeis, niet als een “complianceproject”

Als ik één gedachte zou moeten meegeven die de drie delen samenbrengt: CRA is geen probleem dat je aan het einde oplost. Het is een kader dat de manier waarop je over het product denkt verandert. Net zoals ISO 12100 leert dat risico ontstaat in de relatie mens–machine, zo leert CRA dat cybersecurity ontstaat in de relatie product–omgeving–levenscyclus van de fabrikant.

Geharmoniseerde normen zullen komen en bepaalde trajecten vereenvoudigen. Maar hun afwezigheid is geen reden om stil te blijven staan. Het is een reden om je te richten op wat CRA altijd beoordeelt: beslissingen, bewijs en het vermogen om in de werkelijkheid te handelen — niet in een presentatie.