De CRA is een probleem voor 2026, niet voor 2027

Vraag een productteam wanneer de Cyber Resilience Act (CRA) hen raakt, en de meeste zullen december 2027 zeggen. Dat is de datum waarop de essentiële vereisten, de conformiteitsbeoordeling en de CE-markering van toepassing worden, en het is de datum waarop elke roadmap-presentatie zich richt. Het is echter de verkeerde datum om je planning op te baseren.

De CRA trad in werking op 10 december 2024, en Artikel 71 introduceert een gefaseerde klok, geen enkele deadline. De bepalingen over het melden van conformiteitsbeoordelingsinstanties (Hoofdstuk IV, Artikelen 35 tot en met 51) zijn van toepassing vanaf 11 juni 2026. De meldplichten in Artikel 14 gelden vanaf 11 september 2026. Alleen het hoofdgedeelte van de verordening, de essentiële vereisten in Bijlage I en de conformiteitsroute naar een CE-markering, wacht tot 11 december 2027 (Verordening (EU) 2024/2847, Artikel 71; Europese Commissie, "The Cyber Resilience Act: Summary of the legislative text"). Dus de eerste harde verplichting voor een fabrikant die onder de reikwijdte valt, treedt al ongeveer vijftien maanden eerder in werking dan de datum waarop iedereen zijn planning op baseert.

Dit is geen pleidooi om vroeg te beginnen. Het is een constatering over de juiste volgorde. Het team dat zijn CRA-werkzaamheden achterwaarts plant vanuit de CE-markering in 2027, heeft de meldplicht als laatste gezet, terwijl zowel de kalender als de operationele afhankelijkheden deze als eerste plaatsen.

Wat precies in werking treedt in 2026

Artikel 14 is geen administratieve verplichting die je aan het einde kunt toevoegen. Vanaf 11 september 2026 moet een fabrikant van een product met digitale elementen elke actief uitgebuite kwetsbaarheid in dat product, en elk ernstig incident dat de beveiliging beïnvloedt, melden aan de CSIRT die is aangewezen als coördinator voor de relevante lidstaat en aan ENISA, via een enkel meldplatform. De klok is onverbiddelijk: een vroege waarschuwing binnen 24 uur na het moment van bekend worden, een vollediger melding binnen 72 uur, en een eindrapport binnen 14 dagen na de beschikbaarheid van een corrigerende maatregel voor een kwetsbaarheid, of binnen een maand voor een ernstig incident (Verordening (EU) 2024/2847, Artikel 14).

Lees de trigger zorgvuldig. Een "actief uitgebuite kwetsbaarheid" is een kwetsbaarheid waarvoor betrouwbaar bewijs bestaat dat de uitvoering van kwaadaardige code heeft plaatsgevonden door een actor op een systeem zonder toestemming van de systeemeigenaar (Verordening (EU) 2024/2847, Artikel 3). Dit is geen hypothetisch scenario dat je op je gemak kunt afhandelen. Het is een actueel, gedateerd voorval dat een 24-uurs timer start op het moment dat je ervan op de hoogte wordt, en deze verplichting is al meer dan een jaar van kracht voordat de essentiële vereisten die je in staat zouden stellen om het op te merken, van toepassing worden.

De kennisplicht komt vóór de verwerkingsplicht

Hier is de omkering die de planning vanuit 2027 over het hoofd ziet. Een verplichting om binnen 24 uur te melden zodra je op de hoogte bent, is in de praktijk een verplichting om in staat te zijn om op de hoogte te raken. Je kunt geen vroege waarschuwing indienen over een actief uitgebuite kwetsbaarheid in je product als je geen kanaal hebt waardoor exploitatie bij jou terechtkomt, geen inventaris die je vertelt welke verzonden versies de getroffen component bevatten, en geen triage-regel die beslist of een incident "ernstig" is voordat het 72-uursvenster sluit.

Elk van deze mogelijkheden wordt beschreven in Bijlage I, Deel II van dezelfde verordening: het onderhouden van een software bill of materials (SBOM) die ten minste de top-level afhankelijkheden in een machinaal leesbaar formaat omvat, het opereren van een beleid voor gecoördineerde kwetsbaarheidsdisclosure met een contactpunt voor meldingen, en het zonder uitstel verhelpen van kwetsbaarheden via beveiligingsupdates (Verordening (EU) 2024/2847, Bijlage I, Deel II). Deze vereisten zijn wettelijk van toepassing vanaf 11 december 2027. Maar de meldplicht die wettelijk bindt vanaf 11 september 2026 is moeilijk betrouwbaar te vervullen zonder deze operationele ruggengraat. De wet laat je toe om het verwerkingsproces uit te stellen tot 2027; het laat je niet toe om de gevolgen uit te stellen zodra je op de hoogte bent.

Dus het praktische effect van Artikel 14, voor iedereen die daadwerkelijk onder de reikwijdte valt, is dat het de noodzaak vervroegt voor delen van het operationele model van Bijlage I, Deel II met vijftien maanden. Niet omdat de essentiële vereisten eerder van toepassing zijn, maar omdat de meldplicht moeilijk betrouwbaar te vervullen is zonder de operationele ruggengraat die deze vereisten beschrijven.

Het bezwaar, en waarom het niet standhoudt

Een zorgvuldige professional zal hiertegen inbrengen, en dit bezwaar is serieus te nemen. Artikel 14 is beperkt. Het treedt alleen in werking bij actief uitgebuite kwetsbaarheden en ernstige incidenten, niet bij de routinematige backlog van bevindingen met lage ernst. Een goed beheerd product kan lang zonder een meldbaar voorval. Waarom dan niet een dun proces voor meldingen opzetten vanaf september 2026, de echte opbouw van het kwetsbaarheidsbeheer uitstellen tot 2027, en het kleine risico van een vroege trigger accepteren?

Drie redenen waarom de dunne versie een valkuil is.

Ten eerste: het zeldzame-gebeurtenis-framewerk draait het risico om. De verplichting is niet belastend omdat deze vaak optreedt. Het is gevaarlijk omdat deze onvoorspelbaar optreedt en een 24-uurs klok start die je niet kunt pauzeren om capaciteit op te bouwen. De week waarin je een actief uitgebuite kwetsbaarheid hebt, is precies de week waarin je geen SBOM kunt samenstellen om uit te zoeken welke klanten zijn getroffen.

Ten tweede: de aansprakelijkheidsvorm verschilt van een conformiteitsgat en is erger. Een onvolledige houding ten opzichte van Bijlage I komt naar voren tijdens een beoordeling, in een ruimte, met een kans om dit te herstellen. Een gemiste melding binnen 24 uur is een afzonderlijk, gedateerd, extern te bewijzen falen. Het creëert een dossier dat later van belang kan zijn in toezichts- of handhavingsgesprekken, en het meldtraject dat je vanaf september 2026 opbouwt, maakt deel uit van dat dossier. Een dun proces is geen kleinere versie van compliance; het is een gedocumenteerd spoor van de momenten waarop je niet klaar was.

Ten derde: een meldproces zonder een verwerkingsproces erachter is toneelspel. Binnen 24 uur een formulier naar ENISA kunnen sturen, is waardeloos als je de daadwerkelijke vragen van het formulier niet kunt beantwoorden: welke versies zijn getroffen, wat is de corrigerende maatregel, wanneer wordt deze uitgerold. De meldplicht en de verwerkingsvereisten vormen één systeem dat op twee momenten wordt waargenomen. Je kunt het waarneembare deel kopen en het machinegedeelte overslaan.

Plan achterwaarts vanaf september 2026

De praktische correctie is niet "doe alles nu". Het is om de minimale subset van de essentiële vereisten voor 2027 te identificeren die Artikel 14 in 2026 draaglijk maakt, en deze subset te plannen tegen de datum van september in plaats van die van december 2027.

Deze minimale meldklaarheid bestaat uit:

• Een actuele software bill of materials (SBOM) voor elk verzonden product, ten minste voor de top-level afhankelijkheden, zodat je op de dag van een uitgebuite kwetsbaarheid de impact binnen uren in kaart kunt brengen, niet weken.
• Een gemonitord innamekanaal en een beleid voor gecoördineerde kwetsbaarheidsdisclosure, zodat exploitatie en meldingen van derden daadwerkelijk bij jou terechtkomen en de klok starten waar je verantwoordelijk voor bent.
• Een geschreven triage-regel voor ernst en incidenten die een voorval binnen het 72-uursvenster als meldbaar kan classificeren, zonder dat er een comité moet worden bijeengeroepen.
• Een aangewezen eigenaar en een geoefend indienerstraject naar de coördinerende CSIRT en ENISA, getest op het meldplatform voordat je het daadwerkelijk nodig hebt.

Geen van deze zaken vereist de geharmoniseerde normen of de conformiteitsroute die nog worden afgerond voor 2027. Alles hiervan is nu op te bouwen, en alles is een voorschot op de verplichtingen voor 2027 in plaats van weggegooid werk. Fabrikanten van belangrijke producten in Bijlage III Klasse II hebben nog een tweede reden om niet te wachten: hun conformiteitsroute vereist doorgaans een aangewezen instantie, en deze instanties kunnen pas worden aangewezen zodra de mechanismen van Hoofdstuk IV van toepassing worden vanaf 11 juni 2026. De beoordelingscapaciteit is beperkt, en rijen vormen zich bij deadlines, niet ervoor.

De regel die de moeite waard is om te onthouden

Wanneer een verordening gefaseerd van toepassing wordt, is de hoofddatum meestal de laatste, en de laatste datum is het minst nuttige onderdeel ervan voor planning. Lees de gefaseerde klok in plaats daarvan, en vraag welke verplichting de andere verplichtingen afhankelijk maakt. Voor de CRA komt de meldplicht in Artikel 14 als eerste in de kalender en als eerste in het afhankelijkheidsdiagram: je kunt niet melden wat je niet kunt detecteren, en je kunt niet detecteren zonder de operationele ruggengraat die de vereisten voor 2027 beschrijven. Plan het werk achterwaarts vanaf 11 september 2026, niet voorwaarts naar 11 december 2027, en de juiste volgorde valt vanzelf op zijn plaats.

Als je huidige taak is om uit te zoeken welke van je producten onder de CRA vallen en wat de meldplicht van september 2026 precies van elk product vereist, dan is deze scoping en kruisverwijzing het soort werk waarvoor ISMS Copilot is gebouwd om het te versnellen. Voor veel teams is het werk voor de CE-markering een poort in 2027; de gereedheid voor Artikel 14 is een poort in 2026. Plan eerst voor de eerdere poort.

Dit is praktische compliance-analyse, geen juridisch advies. Bevestig de reikwijdte en verplichtingen van je product aan de hand van de verordening zelf en, waar nodig, met je bevoegde autoriteit of juridisch adviseur.