Het CRA-draaiboek voor 11 september: kwetsbaarhedenregister, meldloket en ondersteuningsperiode inrichten

Op 12 september belt een onderzoeker over een lek in de app die jij hebt laten bouwen. De eerste vragen zijn niet juridisch maar administratief. In welke versie zit het? Welke afnemers draaien die versie? En waar staat vastgelegd dat je het om 14:10 hoorde?

Zonder die drie antwoorden loopt de klok van 24 uur al terwijl jij nog aan het zoeken bent. Dat is het echte probleem van 11 september 2026. Niet de wet, maar de administratie die de wet veronderstelt en die bij vrijwel geen enkele opdrachtgever bestaat.

Deze gids beantwoordt niet de vraag of jij fabrikant bent. Onder de Cyber Resilience Act is wie een product onder eigen naam of merk op de markt brengt de fabrikant, ook als een bureau elke regel code schreef. Deze gids gaat over wat je daarna inricht: het kwetsbaarhedenregister per product, het meldaccount en de escalatieroute, de ondersteuningsperiode met het updatebeleid eronder, en het bewijsspoor dat je eigen systemen moeten produceren.

Wat er op 11 september echt van je gevraagd wordt

Hier ontspoort het meeste voorbereidingswerk. Van de hele verordening treedt op 11 september 2026 precies één artikel in werking: artikel 14, de meldplicht. De rest volgt op 11 december 2027.

Dat verschil is groter dan het klinkt. In haar leidraad van 27 juli 2026 schrijft de Europese Commissie dat een fabrikant voor producten die vóór 11 december 2027 in de handel zijn gebracht niet hoeft te voldoen aan de eisen inzake kwetsbaarhedenbeheer uit bijlage I, terwijl de meldplicht daar wel onverkort op van toepassing is. Voor de app die je in 2024 liet opleveren betekent dat: geen verplichte softwarestuklijst, geen verplicht CVD-beleid, geen CE-markering. Wel een meldplicht met een klok van 24 uur. Dezelfde leidraad tekent aan dat die meldplicht doorloopt nadat een product niet langer ondersteund wordt.

En toch bouw je dat register nu. Niet omdat het op 11 september verplicht is, maar omdat je zonder register de melding niet kúnt doen. De vroegtijdige waarschuwing vraagt binnen 24 uur al om welk product het gaat en in welke lidstaten je het beschikbaar hebt gesteld; binnen 72 uur komen daar de aard van het misbruik en de maatregelen bij die je afnemers zelf kunnen nemen. Dat zijn geen vragen die je op een dinsdagmiddag uit je hoofd beantwoordt.

Een kwetsbaarhedenregister is de vastlegging per product van welke componenten erin zitten, welke kwetsbaarheden daarin bekend zijn, of die in jouw product daadwerkelijk uitbuitbaar zijn, en wat je erover besliste en wanneer. Het is geen beveiligingstool maar een bewijsstuk. Het maakt aantoonbaar wat je wanneer wist.

Wat je nodig hebt voordat je begint

Vijf dingen, en twee ervan hebben een levertijd van dagen tot weken.

Een lijst van je eigen producten. Niet je hele softwarelandschap, alleen wat je onder je eigen naam aan anderen levert: de mobiele app in de stores, de plug-in die klanten in hun webshop installeren, de koppeling die als dienst op de server van je klant draait, de desktopclient. Bij de meeste organisaties zijn dat er twee tot vijf, en op de eerste versie van die lijst ontbreekt bijna altijd de koppeling die ooit even bij één klant is neergezet.

Toegang tot de componentenlijst. Je hebt leestoegang tot de repository nodig, of een leverancier die per release een machineleesbare stuklijst oplevert. Zonder een van die twee kun je stap 2 niet afmaken, en dan is dit vooral een inkoopprobleem.

Een eHerkenningsmiddel op niveau EH2+ met machtiging. Om in te loggen op MijnNCSC heb je betrouwbaarheidsniveau EH2+ nodig plus een machtiging om namens je organisatie te handelen. Bij KPN kost zo'n middel vanaf 14 euro per jaar en heb je bij de aanvraag een KvK-uittreksel van maximaal veertien dagen oud en een kopie van een legitimatiebewijs nodig (prijzen augustus 2026). Vraag je het op 10 september aan, dan haal je de datum niet.

Een EU Login-account voor de persoon die gaat melden. Dat account maak je vandaag aan, gratis, en je hebt het nodig voordat het Europese meldplatform opengaat.

Eén persoon met naam en mandaat. Niet een functie, een naam. Het advocatenkantoor ICTRecht schreef er op 13 augustus 2026 het juiste over: de termijn van 24 uur is kort, dus zorg voor duidelijke escalatielijnen tussen productteams, security, legal en communicatie. Bij een organisatie van veertig man is die lijn één persoon met een vervanger, en dat is prima, zolang beiden weten dat zij het zijn.

Reken op een dag per product voor het register, plus een halve dag voor de accounts en de droogloop.

Het draaiboek in zes stappen

Het draaiboek bestaat uit zes stappen die je in ongeveer twee werkdagen doorloopt: producten inventariseren, het register in twee lagen opzetten, de componenten bij je bouwer vandaan halen, de meldaccounts aanmaken en testen, de ondersteuningsperiode vastleggen en het bewijsspoor aanzetten.

Werk ze in deze volgorde af, want elke stap levert de invoer voor de volgende.

1. Zet je producten op één lijst

Eén regel per product, met de velden die het meldformulier straks van je vraagt: de unieke productnaam, de versie die nu bij afnemers draait, de datum waarop je die in de handel bracht, en de lidstaten waar het product beschikbaar is. Dat laatste veld lijkt overbodig tot je het onder tijdsdruk moet invullen, want de vroegtijdige waarschuwing vraagt er expliciet naar.

Zet in dezelfde regel wie de fabrikant is en waarom. Twee gevallen leveren discussie op. De koppeling die je bouwer bij jouw klanten installeert valt onder de verordening zodra hij daar draait, ook als hij intern heet. Een klantportaal dat jij zelf host en dat niemand installeert, ligt aan de andere kant van de grens en hoort bij het NIS2-regime, waarvoor je eerst vaststelt of je een essentiële of belangrijke entiteit bent. Twijfel je, noteer de twijfel met een datum in plaats van de regel leeg te laten.

2. Bouw het register in twee lagen

De fout die ik het vaakst zie is één platte lijst van CVE-nummers. Dat werkt niet, want de wet vraagt twee verschillende dingen van je: wat zit er in mijn product, en wat wist ik wanneer.

Laag één, per product. De componenten met hun versies, de herkomst van die lijst, de datum van de laatste export, de einddatum van de ondersteuningsperiode, het meldadres waar onderzoekers terechtkunnen, en het kanaal waarmee je je afnemers binnen een dag bereikt. Die laatste twee staan er niet voor de sier. Vanaf december 2027 moet het product een centraal contactpunt voor kwetsbaarheidsmeldingen meeleveren, en artikel 14 verplicht je nu al om getroffen gebruikers zelf te informeren.

Laag twee, per bevinding. Hier zit het bewijs. Per melding leg je vast waar het signaal vandaan kwam, het tijdstip van binnenkomst, het tijdstip waarop je eerste beoordeling klaar was en wat die opleverde, het component en de versie, het CVE- en EUVD-nummer, of het jouw product raakt met de motivering, of er bewijs van actief misbruik is, wie de meldbeslissing nam, de tijdstippen van de verzonden meldingen, en wanneer je je afnemers informeerde.

Dat veld "raakt het jouw product" doet meer werk dan de rest bij elkaar. De Commissie is er duidelijk over: zit er een kwetsbaarheid in een component van derden die in jouw product niet uitbuitbaar is, bijvoorbeeld omdat de kwetsbare code niet bereikbaar is, dan is dat geen actief misbruikte kwetsbaarheid in jouw product en dus niet meldplichtig. Die redenering moet je wel kunnen laten zien. In de praktijk leg je hem vast als VEX-status naast je stuklijst, met één regel motivering per component.

3. Haal de componentenlijst bij je bouwer vandaan

De verordening beschrijft die lijst als een softwarestuklijst in een algemeen gebruikt en machineleesbaar formaat waarin ten minste de afhankelijkheden op het hoogste niveau staan. Die eis geldt pas vanaf december 2027, dus je mag hier praktisch zijn. Je begint er nu mee omdat je de lijst nodig hebt om binnen een dag te kunnen zeggen of een lek jou raakt.

Staat de code in GitHub, dan is dit een kwestie van minuten. Onder Insights, bij Dependency graph, staat een knop Export SBOM die de complete afhankelijkhedenboom in SPDX-formaat oplevert, inclusief versies, licenties en transitieve paden, ook voor private repositories en ook via de API. Werk je met containers of heb je alleen een build, dan genereer je hem met Syft of Trivy. Het technische deel daarvan staat in de gids over het beveiligen van je stack tegen aanvallen via je afhankelijkheden.

Heb je de code niet, dan is dit het gesprek dat je deze maand voert. Vraag om een stuklijst in CycloneDX of SPDX bij elke release, als opleverdocument, niet als gunst. Dat hoort in dezelfde securitybijlage waarin je de meldtermijn van je leverancier vastlegt op vier uur bij bekend of vermoed misbruik. Regel meteen wat er gebeurt als je bouwer verdwijnt, want de meldplicht verhuist niet mee. Dat is de reden dat broncode en documentatie in escrow van een nette wens een randvoorwaarde worden.

Bewaar elke export buiten de omgeving van je bouwer, met een datum in de bestandsnaam. Een stuklijst die alleen in de CI van iemand anders bestaat, is geen bewijs.

4. Maak de accounts aan en loop de route één keer droog

Er zijn twee ingangen, en dat verwart. Het NCSC schrijft dat de melding vanaf 11 september 2026 plaatsvindt bij het Nationaal Cyber Security Centrum via mijn.NCSC.nl. ENISA beschrijft tegelijk hoe fabrikanten zich aanmelden op het Europese meldplatform, en dat is een aparte route: de aangewezen vertegenwoordiger registreert zich met een EU Login-account, kiest zijn CSIRT uit een lijst en nodigt daarna een tweede persoon uit als back-up, met een uitnodiging die zeven dagen geldig blijft. ENISA tekent daarbij aan dat de validatie van je registratie geen voorwaarde is om aan de meldplicht te voldoen, dus je kunt melden terwijl die validatie loopt.

Op 16 augustus 2026 was het publieke adres van dat Europese platform nog niet gepubliceerd en dateerde de registratiehandleiding van 3 augustus. Praktisch betekent dat: zet vandaag het EU Login-account en de eHerkenning klaar, want dat zijn de delen met een levertijd, en houd de CRA-pagina van het NCSC in de gaten voor het Nederlandse ingangspunt. Je meldt via het meldpunt van de lidstaat waar de beslissingen over de beveiliging van je producten overwegend worden genomen. Voor een Nederlands bedrijf is dat Nederland.

Loop de route daarna één keer droog met een verzonnen geval. Wie krijgt de mail? Wie beoordeelt? Wie logt in? Waar staat het wachtwoord als die persoon op vakantie is? De registratie-achterstand bij de Cyberbeveiligingswet laat zien hoe dit afloopt als je het uitstelt: op de dag van inwerkingtreding stonden er 2.942 registraties tegenover minstens 8.000 plichtige organisaties.

De termijnen zelf zijn snel samengevat. Je meldt één keer via het gezamenlijke platform, met een vroegtijdige waarschuwing binnen 24 uur, een inhoudelijke melding binnen 72 uur en een eindverslag uiterlijk 14 dagen nadat een oplossing beschikbaar is. Bij een ernstig incident is dat eindverslag een maand na de melding van 72 uur. Voor de procedure zelf hoef je bij mij niet te zijn: het NCSC, ENISA en de RDI beschrijven hem uitputtend. De RDI houdt als markttoezichthouder het toezicht en publiceert de Gids Cyber Resilience Act.

Wat wél jouw werk is: bepalen wanneer de klok start. De Commissie hanteert het moment waarop je na een onmiddellijke eerste beoordeling een redelijke mate van zekerheid hebt dat de kwetsbaarheid actief wordt misbruikt, in lijn met hoe datzelfde begrip onder de AVG wordt uitgelegd. Niet het moment van de mail dus, en ook niet het moment waarop je jurist er iets van vindt. Dat maakt het tijdstempel op je eerste beoordeling het belangrijkste veld in je hele register.

5. Leg de ondersteuningsperiode en het updatebeleid vast

Dit is formeel een verplichting voor december 2027. Je legt hem in september vast omdat de termijn die je kiest bepaalt wat je de komende vijf jaar verschuldigd bent, en omdat je hem niet met terugwerkende kracht kunt inkorten zodra klanten hem eenmaal hebben gelezen.

De ondersteuningsperiode is minimaal vijf jaar, tenzij het product aantoonbaar korter in gebruik is, en langer wanneer je redelijkerwijs een langere levensduur mag verwachten. Vijf jaar is dus geen standaard maar een bodem. De einddatum maak je bij aankoop kenbaar, ten minste met maand en jaar, en zodra die periode verloopt toon je gebruikers een melding, waar dat technisch kan.

Voor software die je iteratief uitbrengt geeft de verordening één praktische ontsnapping die veel scheelt. Je mag kwetsbaarheden alleen in de laatst uitgebrachte versie verhelpen, mits gebruikers van oudere versies gratis kunnen upgraden zonder extra kosten. De Commissie legt die extra kosten eng uit: testen, configuratiewerk en het bijwerken van onderliggende afhankelijkheden tellen als normaal onderhoud en dus niet mee, verplichte aankoop van nieuwe hardware of een fundamentele wijziging van de omgeving wel.

Vertaal dat naar drie regels per product, en zet ze op de plek waar je klant ze bij aankoop ziet:

1. De einddatum, als maand en jaar, met de onderbouwing ernaast in je eigen documentatie. Waarom deze termijn? Vergelijkbare producten, de verwachte gebruiksduur, en de ondersteuning van de componenten die je erin gebruikt.
2. Welke versie je ondersteunt. "Alleen de laatst uitgebrachte versie, en upgraden is gratis en zonder aanvullende kosten" is een geldige keuze, mits die tweede helft ook echt waar is.
3. Hoe je een beveiligingsupdate herkenbaar maakt. Een advisory bij elke update die een kwetsbaarheid verhelpt, met de getroffen versies en de handeling die je afnemer moet verrichten.

Die derde regel wordt pas in december 2027 een harde eis, maar hij is nu al de goedkoopste manier om je bewijsspoor te vullen. Elke advisory is een gedateerd bewijs dat je iets hebt uitgebracht.

6. Zet het bewijsspoor aan

Bewijs ontstaat vooruit in de tijd, nooit achteraf. Vier dingen horen je eigen systemen automatisch te produceren, en alle vier kosten ze meer moeite als je ze pas na een incident probeert te reconstrueren.

Een tijdstempel op elk binnenkomend signaal. Laat je meldadres in een ticketsysteem of een gedeelde inbox landen die de binnenkomst vastlegt, niet in de persoonlijke mailbox van je ontwikkelaar.

Een gedateerde beoordeling. Eén veld met de uitkomst en het tijdstip. Dit is het veld waarop een toezichthouder terugrekent.

Een monitoringsignaal op je componenten. Naast wat je bouwer meldt wil je een tweede bron. De Europese kwetsbaarhedendatabank van ENISA, operationeel sinds 13 mei 2025 en met een apart dashboard voor uitgebuite kwetsbaarheden, is daarvoor de logische keuze, ook omdat de Commissie hem noemt als voorbeeld van een openbare databank waarmee een kwetsbaarheid als bekend geldt. Die databank heeft een open eindpunt voor uitgebuite kwetsbaarheden dat je periodiek kunt bevragen en tegen je stuklijst kunt leggen; toen ik het op 16 augustus 2026 opvroeg gaf het gewoon gestructureerde JSON terug.

Een archief van je stuklijsten en advisories. Per release, met datum, buiten de systemen van je leverancier.

Waar het in de praktijk misgaat

Je start de klok op het verkeerde moment. Wie de 24 uur laat lopen vanaf de binnenkomende mail, meldt te vroeg en te ongericht. Wie hem laat lopen vanaf het moment dat de directie akkoord is, meldt te laat. De mitigatie is klein: één veld, één tijdstip, één persoon die het invult, en de instructie dat de beoordeling meteen begint.

Je meldt elk CVE-nummer dat langskomt. Een kwetsbaarheid in een component die in jouw product niet bereikbaar of niet misbruikt is, is niet meldplichtig. Wel moet je hem aan de maker van dat component melden en in je register zetten. Leg per component een status vast met één regel motivering, in plaats van de afweging elke keer opnieuw te maken.

Het register woont bij je bouwer. Dan verdwijnt het met hem, precies op het moment dat je het nodig hebt. Zet de exports in jouw omgeving en geef je bouwer leestoegang, in plaats van andersom.

Niemand heeft eHerkenning. Dit is de saaiste valkuil, en tegelijk degene die het vaakst de datum kost. Vraag het middel aan zodra je deze gids uit hebt, niet in de week van 7 september.

Je verwart de melding met je klantcommunicatie. Een melding bij het meldloket informeert je afnemers niet. Doe je dat zelf niet op tijd, dan mag het ontvangende CSIRT jouw gebruikers rechtstreeks informeren. Zet naast de meldtaak dus een tweede taak in dezelfde procedure, met een kanaal dat je binnen een dag kunt gebruiken.

Je telt drie regimes bij elkaar op. De Cyberbeveiligingswet, de AVG en de CRA hebben verschillende drempels, ontvangers en termijnen. Ze sluiten elkaar niet uit: hetzelfde incident kan drie meldingen opleveren. Zet de drie routes naast elkaar in één procedure, met per route de trigger erboven.

Hoe zwaar tuig je het register op

De eerlijke ondergrens ligt lager dan leveranciers je vertellen. Heb je één product en breng je twee keer per jaar een release uit, dan is een spreadsheet met een gedateerde stuklijst-export ernaast volledig voldoende. Het register is een bewijsstuk, geen platform.

De drempel naar gereedschap ligt bij ongeveer drie producten of maandelijkse releases. Vanaf dat punt vergeet je exports, verouderen ze, en wordt het handmatig matchen van kwetsbaarheden tegen versies een terugkerende klus van uren.

Dependency-Track kwam op 9 juni 2026 uit in versie 5.0, met een herbouwde architectuur die horizontaal schaalt en als losse containers voor de API en de frontend draait. Het is gratis en open source onder de vlag van OWASP, het slikt CycloneDX-stuklijsten en het blijft je componenten volgen nadat je ze hebt geüpload. Voor twee tot tien producten is dat de scherpste verhouding tussen prijs en resultaat die er ligt, mits je iemand hebt die een container onderhoudt.

Kant-en-klaar wint hier van maatwerk, met één uitzondering. De koppeling tussen je stuklijsten, je kwetsbaarheidsbronnen en je meldprocedure is bij vrijwel iedereen maatwerk, simpelweg omdat niemand anders jouw producten, afnemers en releasekalender kent. Dat stukje is klein: een periodieke export, een match, een alert naar de juiste persoon, en een regel die in je register belandt.

Een doorgerekend voorbeeld

Neem een groothandel in bouwmaterialen met veertig medewerkers. Fictief, met realistische verhoudingen. Ze hebben drie stukken software laten bouwen: een bestel-app in de App Store en de Play Store, een klantportaal dat ze zelf hosten, en een koppeling die als Windows-dienst bij twaalf grotere klanten op de server draait. Geen programmeur in dienst.

De productlijst levert twee producten met digitale elementen op. De app en de koppeling worden bij iemand anders geïnstalleerd. Het portaal is een dienst die zij zelf draaien en dat ligt aan de NIS2-kant van de grens; die twijfel gaat met datum in het register.

Het register staat er in een halve dag. De bouwer geeft leestoegang tot de repositories, waarna de export in GitHub voor beide producten een SPDX-bestand oplevert. Die twee bestanden gaan met de datum in de bestandsnaam naar een map in hun eigen omgeving. Twee productregels, twee stuklijsten, twee ondersteuningsperiodes: januari 2031 voor de app, januari 2030 voor de koppeling.

De accounts kosten vier dagen doorlooptijd, waarvan drie wachten op eHerkenning. De operationeel manager wordt de meldverantwoordelijke, de eigenaar is de vervanger. Beiden hebben een EU Login-account.

Dan gebeurt het. Dinsdag 15 september, 14:10, komt er een mail binnen op het meldadres van de productpagina. Een onderzoeker beschrijft dat een endpoint van de koppeling gegevens teruggeeft zonder te controleren wie het opvraagt.

• 14:25 De operationeel manager pakt de mail op en zet hem in het register. Tijdstip van binnenkomst vastgelegd.
• 15:40 De bouwer heeft het gereproduceerd en vindt in de logging van twee klanten aanroepen vanaf onbekende adressen. Nu is er redelijke zekerheid van actief misbruik. Dit tijdstip is de kennisname en gaat als zodanig in het register. De klok loopt tot woensdag 15:40.
• 16:30 Het register beantwoordt de formuliervragen zonder zoekwerk: welke versie, sinds wanneer in de handel, beschikbaar in Nederland en België, en welke twaalf klanten die versie draaien.
• 18:00 De vroegtijdige waarschuwing gaat de deur uit, ruim binnen de 24 uur.
• 18:20 Diezelfde twaalf klanten krijgen een mail met de tijdelijke maatregel: het endpoint dichtzetten op de firewall tot de patch er is.
• Donderdag De patch is uit, met een advisory in de release notes. De inhoudelijke melding van 72 uur volgt met de details van de oplossing.
• Binnen 14 dagen na de patch gaat het eindverslag eruit, en daarmee is de zaak in het register gesloten.

Zonder register verloopt die dinsdag anders. De eerste twee uur verdwijnen in de vraag welke klant welke versie draait, de bouwer moet de landenvraag beantwoorden en zit in een andere tijdzone, en het moment van kennisname staat nergens. Waarschijnlijk meld je dan nog steeds binnen 24 uur. Alleen kun je het achteraf niet aantonen, en dat is precies wat een toezichthouder van je vraagt.

Tot slot

Wat op 11 september begint is geen inspectieronde. De boetes van maximaal 15 miljoen euro of 2,5 procent van de wereldwijde jaaromzet zijn echt, en micro- en kleine ondernemingen zijn alleen vrijgesteld van de boete op het missen van die eerste 24 uur, niet van de meldplicht zelf. De reden om dit deze maand te doen is praktischer.

Een register van twee pagina's verandert een chaotische dinsdag in een procedure van vier uur. Het is het goedkoopste stuk administratie dat je dit jaar inricht, en het enige waarvan je hoopt dat je het nooit hoeft te gebruiken.