--- title: "De meldplicht van de Cyber Resilience Act is live. Bij de meeste fabrikanten is het proces nog theater. | Guardian360" description: "De meldplicht van de Cyber Resilience Act ging live op 11 september 2026: fabrikanten moeten actief misbruikte kwetsbaarheden en ernstige incidenten binnen 24 uur melden. Onderzoeksdata laat veel bewustzijn zien, maar zwakke voorbereiding. Wat je moet melden, voor wie het geldt, en hoe echt voorbereid zijn er in de praktijk uitziet." url: https://guardian360.net/nl/blog/cra-reporting-duty-is-live/ locale: nl source: guardian360.net --- [← Alle posts](https://guardian360.net/nl/blog/) Opinie # De meldplicht van de Cyber Resilience Act is live. Bij de meeste fabrikanten is het proces nog theater. Door Jan Martijn Broekhof · 11 september 2026 Vandaag, 11 september 2026, treedt de meldplicht van de Cyber Resilience Act in werking in de hele Europese Unie. Niet in december 2027, wanneer de essentiële producteisen van kracht worden en iedereen te horen heeft gekregen dat dan de echte afrekening komt. Vandaag. Als je een product met digitale elementen maakt en dat in de EU verkoopt, begint de klok voor je eerste melding vanaf nu te lopen, of je organisatie de datum nu had aangestreept of niet. Ik schreef in juli dat de Cyber Resilience Act de regelgeving was waar niemand scherp genoeg naar keek, degene die een product uit de markt kan halen in plaats van alleen het bedrijf erachter te beboeten. Dat stuk richtte zich op het grote compliance-plaatje: reikwijdte, categorisering, de relatie met NIS2. Dit stuk gaat over de veel smallere, veel scherpere verplichting die zojuist live is gegaan, en over de ongemakkelijke kloof tussen hoeveel fabrikanten zeggen ervan te weten en hoeveel er daadwerkelijk naar kunnen handelen binnen de uren die de wet geeft. ## De datum waar niemand naar keek De meeste berichtgeving over de CRA cirkelt nog steeds rond december 2027, en dat is begrijpelijk, want dat is het moment waarop de essentiële cyberbeveiligingseisen en de verplichtingen voor conformiteitsbeoordeling volledig van toepassing worden. Maar artikel 14 van de verordening reserveerde een aparte, eerdere datum specifiek voor het melden: vanaf 11 september 2026 moeten fabrikanten actief misbruikte kwetsbaarheden en ernstige incidenten die hun producten raken melden, en die plicht geldt voor producten die al op de markt zijn, niet alleen voor nieuwe introducties. De Europese Commissie publiceerde haar praktische richtsnoeren hierover op 27 juli 2026, slechts enkele weken voordat de datum inging. Dat is een smal venster voor een verplichting met een eerste deadline van 24 uur eraan vast. De essentiële eisen in december 2027 geven fabrikanten vanaf nu ongeveer vijftien maanden aanloop. De meldplicht gaf veel minder. ## Wat moet je precies melden? Dit is de vraag waar mensen over struikelen, en het is de moeite waard om die precies te beantwoorden in plaats van in algemene termen. Je meldt een actief misbruikte kwetsbaarheid, wat betekent dat er geloofwaardig bewijs is dat iemand die op dit moment tegen jouw product inzet. Je meldt een ernstig incident, wat betekent iets dat de beveiliging van je product daadwerkelijk in gevaar brengt, niet slechts een theoretische zwakte. Wat je niet meldt is elke CVE die aan je codebase wordt toegewezen, elke bevinding uit je eigen penetratietest, of elke inzending via je responsible disclosure-programma of bug bounty, tenzij er bewijs is dat die daadwerkelijk is misbruikt. Het webinar dat het ministerie van Economische Zaken en Klimaat en het Nationaal Cyber Security Centrum (NCSC) op 27 augustus organiseerden was hier onomwonden over, en met goede reden: zonder dat onderscheid zouden fabrikanten hun nationale CSIRT verzuipen in ruis of, erger, aannemen dat elke kwetsbaarheidsmelding dezelfde urgentie van 24 uur nodig heeft en het team opbranden dat juist de meldingen die er toe doen moet afhandelen. Je kunt de gevallen met lagere ernst nog steeds vrijwillig melden, en er zijn goede redenen om die gewoonte op te bouwen. Maar de wettelijke plicht rust specifiek op actief misbruik en ernstige incidenten, en weten waar die grens ligt is het eerste wat je incident response-proces goed moet hebben. ## De klok pauzeert niet voor je incident response-overleg Zodra je het weet, is de tijdlijn gefaseerd en meedogenloos. Een vroege waarschuwing gaat uit binnen 24 uur nadat je op de hoogte bent. Een uitgebreidere melding volgt binnen 72 uur, over wat je op dat moment weet over de aard, impact en mitigerende maatregelen. Een eindrapport sluit het af: veertien dagen nadat een corrigerende maatregel beschikbaar komt voor een kwetsbaarheid, of één maand voor een ernstig incident, volgens de richtsnoeren van de Europese Commissie. De analyse van Freshfields over de nieuwe verplichting maakt een punt dat het waard is om even bij stil te staan: de meldtermijnen beginnen op het moment dat je op de hoogte bent, en de klok stopt niet in het weekend of op feestdagen. Er is geen respijt voor het feit dat je security lead op een congres zat, of dat het incident op een vrijdagavond plaatsvond. Als je organisatie nog geen vastgelegd proces heeft voor wie een melding beoordeelt, wie beslist of die de drempel haalt en wie hem indient, dan bouw je dat proces voor het eerst onder een live deadline van 24 uur, wat precies het verkeerde moment is om ook maar iets te bouwen. Het melden zelf verloopt via je nationale CSIRT, in Nederland het NCSC, en het EU-brede Single Reporting Platform dat door ENISA wordt beheerd, dus een fabrikant in België, Duitsland of waar dan ook in de EU volgt dezelfde gefaseerde tijdlijn via het eigen nationale contactpunt. De mechaniek verschilt licht per lidstaat; de verplichting en de deadlines niet. ## Waarom zijn de cijfers over voorbereiding zo slecht? Hier moet de stelling dat het proces bij de meeste fabrikanten theater is zich bewijzen, en de onderzoeksdata onderbouwt die scherper dan ik had verwacht. Het SME Cyber Resilience Maturity Assessment Model van ENISA, gepubliceerd op 13 juli 2026 en gebaseerd op veldwerk bij 194 organisaties in 31 landen, vond veel bewustzijn van de CRA maar consequent zwakke praktische voorbereiding, waarbij incident response en productlevenscyclusbeheer als de twee zwakste domeinen scoorden. Weten dat een wet bestaat is niet hetzelfde als een proces hebben dat binnen een venster van 24 uur kan handelen. Het CRA-onderzoek van de Linux Foundation en OpenSSF uit 2026, gebaseerd op 843 respondenten, vertelt een vergelijkbaar verhaal vanuit een andere hoek. Zesenzestig procent wist nog steeds niet wat ze daadwerkelijk moesten doen om te voldoen, een cijfer dat nauwelijks was bewogen ten opzichte van 62 procent het jaar ervoor. Slechts 41 procent van de fabrikanten verwachtte volledige compliance te bereiken tegen de deadline van december 2027, en slechts 34 procent wees die datum überhaupt correct aan. Onder respondenten die zich sowieso bewust waren van de CRA kon 54 procent nog steeds geen helder onderscheid maken tussen de verplichtingen van een fabrikant en die van een steward. Niets daarvan is een verwijt aan welk individueel complianceteam dan ook. Het weerspiegelt een regelgeving die sneller van abstract naar operationeel bewoog dan de meeste organisatieprocessen konden bijhouden. Maar het betekent wel dat een aanzienlijk deel van de fabrikanten die dit lezen de grens van 11 september overstak zonder een getest proces erachter, wat precies het scenario is dat de meldplicht bedoeld was te betrappen. ## Wie moet er eigenlijk melden? Onder de CRA rust de meldverplichting bij de fabrikant, de entiteit die een product met digitale elementen onder eigen naam of merk op de EU-markt brengt, en de omvang van de organisatie ontslaat je er niet van. Een importeur of distributeur draagt over het algemeen geen zelfstandige meldplicht, tenzij hij onder eigen merk verkoopt of het product substantieel wijzigt, in welk geval hij voor dat product feitelijk de fabrikant wordt. Stewards van opensourcesoftware hebben te maken met een lichtere variant van dezelfde plicht, wat de andere relatie weerspiegelt die zij hebben met de producten die ze onderhouden. Kleine en micro-ondernemingen vallen er volledig onder; de enige tegemoetkoming die het Nederlandse NCSC heeft bevestigd is dat er in die categorie geen sanctie staat op het missen van het strikte venster van 24 uur, wat een verzachting is, geen uitzondering. Eén detail is het benoemen waard omdat het voor echte verwarring zorgt: de CRA zelf vereist geen voorafgaande registratie voordat je kunt melden. Je hebt geen account of login nodig om een melding in te dienen. Dat is een bewuste ontwerpkeuze, los van de registratieplicht die bestaat onder de Cyberbeveiligingswet (de Nederlandse implementatie van NIS2) voor organisaties die ook onder die wet vallen. De twee verplichtingen lopen parallel, niet als één gecombineerd proces, en ze door elkaar halen is een makkelijk te maken fout. ## Hoe ziet “voorbereid” er eigenlijk uit? Je voorbereiden op de meldplicht van de CRA is in principe niet ingewikkeld. Het is veeleisend in de praktijk, wat een ander probleem is. Begin met een eerlijke inventarisatie van wat er daadwerkelijk in je producten zit, idealiter via een Software Bill of Materials (SBOM), want je kunt niet beoordelen of een gemelde kwetsbaarheid jou raakt als je niet weet welke componenten je meelevert. Stel vooraf je eigen interne drempels op voor wat als actief misbruik of een ernstig incident telt, zodat die afweging niet voor het eerst onder druk wordt gemaakt. Bouw een escalatiepad met benoemde rollen: wie signaleert, wie beslist, wie indient. Stel nu templates op voor de vroege waarschuwing, de melding na 72 uur en het eindrapport, terwijl niemand onder een deadline staat. En stem dit af op waar je verder al onder meldt, want een behoorlijk aantal fabrikanten die dit lezen valt ook onder de Cyberbeveiligingswet of de AVG, en drie ongecoördineerde meldprocessen draaien is een risico op zichzelf. Dit is, niet toevallig, dezelfde discipline waar ik in juli voor pleitte toen ik schreef over de bredere compliance-eisen van de CRA: weet wat je hebt, categoriseer het eerlijk, en bouw de papierwinkel voordat de toezichthouder erom vraagt. De meldplicht heeft dat argument simpelweg verplaatst van “uiteindelijk” naar “nu”. Als een klant je vanochtend vertelde dat iemand actief een kwetsbaarheid in jouw product misbruikte, zou je organisatie dan binnen 24 uur precies weten wie die melding oppakt? Als het eerlijke antwoord “dat komen we wel uit” is, dan is de meldplicht vandaag niet voor niets live gegaan. ## Bronnen - European Commission, Cyber Resilience Act, Reporting obligations, Shaping Europe’s Digital Future: [digital-strategy.ec.europa.eu/en/policies/cra-reporting](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting) - ENISA, SME Cyber Resilience Maturity Assessment Model, published 13 July 2026. - Linux Foundation Research, Linux Foundation Europe, and OpenSSF, “The CRA Readiness Reality: What Changed (and What Didn’t) Between 2025 and 2026?”, June 2026: [linuxfoundation.org](https://www.linuxfoundation.org/blog/the-cra-readiness-reality-what-changed-and-what-didnt-between-2025-and-2026) - Freshfields, “Cyber Resilience Act reporting obligations take effect on 11 September 2026”: [freshfields.com](https://www.freshfields.com/en/our-thinking/blogs/technology-quotient/cyber-resilience-act-reporting-obligations-take-effect-on-11-september-2026-102nzmk) - Ministry of Economic Affairs and Climate Policy and National Cyber Security Centre (NCSC), Cyber Resilience Act, Themasessie Meldplicht (webinar), 27 August 2026.