CRA-meldplicht 2026: checklist voor software-MKB
Bram SuurdTechnologie
De CRA-meldplicht start op 11 september 2026. Praktische checklist voor software-MKB: 24-uursmelding, productoverzicht, klantcommunicatie en incidentoefening.
In dit artikel
De CRA-meldplicht start op 11 september 2026. Zodra een fabrikant kennis krijgt van een vermoedelijk actief uitgebuite kwetsbaarheid of een ernstig beveiligingsincident, begint een korte meldklok. Dan moet u snel kunnen vastleggen welk product het betreft, wat u al weet, wie beslist en wie klanten informeert.
Voor veel software-MKB's is dat geen nieuw securityproject, maar wel een reden om het incidentproces eindelijk bruikbaar te maken. Een incident komt zelden op een handig moment. Als contactpersonen, productversies en beslisrechten dan alleen in iemands hoofd zitten, verliest u tijd die u niet heeft.
De Cyber Resilience Act, kortweg CRA, geldt niet automatisch voor iedere SaaS- of clouddienst. Een online dienst kan er wel onder vallen wanneer deze onder verantwoordelijkheid van de fabrikant is ontwikkeld en nodig is om een functie van een product met digitale elementen te laten werken. Losse websites en cloudservices zonder die functionele productrelatie vallen niet vanzelf onder de CRA. Ook uw rol telt: de rapportageplicht rust op de fabrikant en een importeur die een product onder eigen merk verkoopt, geldt als fabrikant. Laat grensgevallen juridisch beoordelen.
In het kort
- Vanaf 11 september 2026 moeten fabrikanten actief uitgebuite kwetsbaarheden en ernstige beveiligingsincidenten rapporteren.
- De eerste waarschuwing volgt binnen 24 uur. Daarna volgen een melding binnen 72 uur en een eindrapport met een eigen termijn.
- Toets per product en per rol in de keten of de CRA van toepassing is.
Wat verandert er op 11 september 2026?
De CRA is een EU-verordening voor producten met digitale elementen. De Rijksinspectie Digitale Infrastructuur noemt onder meer mobiele apps, videogames, besturingssystemen en softwarelibraries als voorbeelden. De brede productverplichtingen, waaronder security-by-design en kwetsbaarhedenbeheer, gelden vanaf 11 december 2027. De meldplicht begint eerder. Belangrijk: die meldplicht geldt vanaf 11 september 2026 ook voor producten die al vóór 11 december 2027 op de markt zijn gebracht, zolang zij binnen de reikwijdte van de CRA vallen.
Bij een vermoedelijk actief uitgebuite kwetsbaarheid of een ernstig incident meldt de fabrikant volgens de Europese Commissie in stappen, gerekend vanaf het moment van kennisname:
- een early warning binnen 24 uur;
- een melding binnen 72 uur;
- een eindrapport. Voor een actief uitgebuite kwetsbaarheid is dat uiterlijk 14 dagen nadat een corrigerende maatregel beschikbaar is. Voor een ernstig incident is dat binnen één maand.
Een bekende kwetsbaarheid of beschikbare patch is niet automatisch een actief uitgebuite kwetsbaarheid. Daarvoor moet er betrouwbaar bewijs zijn dat een kwaadwillende de kwetsbaarheid zonder toestemming heeft misbruikt. Leg daarom in uw besliskaart vast welke signalen escalatie starten, wie die beoordeling doet en wanneer u externe juridische of incidenthulp inschakelt.
In Nederland loopt de melding vanaf 11 september 2026 via het digitale meldloket van het NCSC, volgens de RDI. Regel vooraf wie toegang tot dat loket heeft en wie de vervanger is.
Begin met een productlijst die u ook echt bijhoudt
Veel bedrijven weten precies welke systemen ze zelf gebruiken, maar hebben geen goed overzicht van wat ze onder eigen naam op de markt brengen. Dat verschil telt. Een klantportaal, mobiele app, API, on-premises koppeling of softwarelibrary kan een andere rol en andere verantwoordelijkheden opleveren.
Maak voor uw belangrijkste producten een overzicht met:
- productnaam, versies en interne eigenaar;
- waar het product draait en welke componenten of diensten van derden erin zitten;
- welke klanten of beheerders zelf een update moeten uitvoeren;
- welke logs, monitoring en back-ups beschikbaar zijn;
- hoe lang u beveiligingsupdates belooft of feitelijk levert.
Kies eerst producten die bij veel klanten draaien, persoonsgegevens verwerken of toegang geven tot andere systemen. U wilt tijdens een incident niet hoeven zoeken naar versienummers, klantcontacten en afhankelijkheden. Dit is een praktische voorbereidingslijst, geen volledige opsomming van alle CRA-documentatieverplichtingen vanaf december 2027.
Maak van 24 uur een uitvoerbaar proces
Een meldtermijn is alleen haalbaar als de eerste uren voorspelbaar zijn. Leg een klein incidentteam vast: iemand voor de technische analyse, iemand die over een melding mag beslissen en iemand die klanten en partners mag informeren. In een kleiner bedrijf kan één persoon meerdere rollen hebben. Benoem dan een vervanger.
Zet bovenaan de besliskaart: T0 = moment van kennisname. Noteer daarbij tijdstip, bron en de persoon die het signaal ontving. Werk vervolgens terug vanaf T0 + 24 uur. Leg ook vast wie de melding via het NCSC-loket indient en hoe die persoon toegang krijgt wanneer de gewone omgeving niet beschikbaar is.
- Leg vast wanneer het signaal binnenkwam, om welk product het gaat en welke versies mogelijk zijn geraakt.
- Bewaar relevante logs en andere bewijzen. Zet systemen niet overhaast uit wanneer dat onderzoek of herstel belemmert.
- Controleer aanwijzingen voor actief misbruik, datalekken, uitval of een brede veiligheidsimpact.
- Roep de aangewezen beslisser erbij. Die beoordeelt of de drempel voor een CRA-melding waarschijnlijk is bereikt en start zo nodig het meldproces.
- Leg besluiten, tijden en onzekerheden vast. Dat vormt de basis voor de melding na 72 uur en voorkomt verschillende versies van hetzelfde incident.
Houd de kaart kort. Namen, telefoonnummers, beslismomenten en links naar de juiste systemen zijn tijdens een incident nuttiger dan een lange procedure.
Uw softwareketen bepaalt hoe snel u antwoord kunt geven
Een beveiligingsprobleem zit zelden netjes in één repository. Het kan in een open-sourcepackage, cloudconfiguratie, CI/CD-stap, mobiele app of integratie met een leverancier zitten. Als u pas tijdens een incident uitzoekt welke versie bij welke klant draait, bent u te laat voor een rustige beoordeling.
Breng daarom per product minimaal deze vragen in kaart:
- Welke componenten en diensten van derden maken deel uit van het product?
- Welke versie draait waar, en kunt u dat aantonen?
- Wie ontvangt beveiligingsmeldingen van leveranciers en open-sourceprojecten?
- Kunt u een patch gefaseerd uitrollen, terugdraaien en controleren?
- Welke klanten moeten zelf iets doen, bijvoorbeeld een update installeren of een API-sleutel vervangen?
Een software bill of materials kan helpen. Kies vooral een vorm die uw team actueel houdt en waarmee u per productversie snel afhankelijkheden, getroffen klanten en patchmogelijkheden kunt achterhalen. Koppel dit waar mogelijk aan de build of release, zodat het niet van iemands geheugen afhangt.
Klantcommunicatie is onderdeel van het herstel
Bij een ernstig incident moet de fabrikant getroffen gebruikers zonder onnodige vertraging informeren en, waar nodig, adviseren over corrigerende of risicobeperkende maatregelen. Dat staat los van de vraag hoe uitgebreid u de technische oorzaak al kent.
Klanten willen tijdens een incident weten of zij iets moeten doen, welke versies geraakt zijn en wanneer de volgende update komt. Gebruik een vooraf goedgekeurd sjabloon en neem alleen feiten op die u kunt staven:
- welk product en welke versies mogelijk zijn geraakt;
- wat u heeft vastgesteld en wat nog wordt onderzocht;
- welke tijdelijke maatregel of update beschikbaar is;
- wat de klant zelf moet doen;
- wanneer u opnieuw informatie geeft en hoe klanten u bereiken.
Zeg niet te vroeg dat er geen impact is, maar wacht ook niet tot elk detail zeker is. Geef een vast moment voor de volgende status. Een CRA-melding vervangt een eventuele AVG-datalekbeoordeling niet. Zijn persoonsgegevens mogelijk geraakt, beoordeel dan afzonderlijk de AVG-verplichtingen en betrek de privacyverantwoordelijke direct.
Oefen een incident voordat de klok loopt
Een korte tabletop-oefening laat snel zien waar uw proces hapert. Kies een geloofwaardig scenario, bijvoorbeeld een kwetsbaarheid in een veelgebruikte library waarvoor aanwijzingen voor actief misbruik verschijnen. Laat het team in 45 minuten doorlopen wat het doet.
- Wie beoordeelt de melding wanneer de technisch directeur niet bereikbaar is?
- Waar staat de contactlijst voor klanten en leveranciers, en is die ook buiten de getroffen omgeving bereikbaar?
- Kunnen we binnen een uur zien welke klanten een kwetsbare versie gebruiken?
- Wie kan een tijdelijke maatregel of patch daadwerkelijk uitrollen?
- Wie houdt de tijdlijn en het besluitlog bij?
Noteer na afloop maximaal vijf verbeterpunten en geef elk punt een eigenaar en datum. Herhaal de oefening na een grote architectuurwijziging of wanneer u een nieuw product uitbrengt.
Wat u deze maand kunt regelen
- Bespreek per product of en waarom de CRA mogelijk op u van toepassing is.
- Maak een product- en afhankelijkhedenoverzicht voor de belangrijkste producten.
- Wijs incidentrollen en vervangers aan, inclusief een beslisbevoegde voor meldingen.
- Schrijf een korte besliskaart voor de eerste 24 uur en een feitelijk klantsjabloon.
- Plan een tabletop-oefening en verwerk de uitkomsten in uw release- en incidentproces.
De CRA-meldplicht test of u binnen 24 uur de betrokken productversie, aanwijzingen voor misbruik, verantwoordelijke beslisser en meldroute kunt vastleggen. BLB Solutions helpt MKB-fabrikanten met een CRA-scopecheck, product- en afhankelijkhedenoverzicht en een oefenbaar incidentproces.
Laatst gecontroleerd: 15 juli 2026. Dit artikel is algemene informatie en geen juridisch advies.
