Cyber Resilience Act: wat moet een softwarefabrikant nu kunnen melden?
De meldplicht uit de Cyber Resilience Act geldt sinds 11 september 2026 voor fabrikanten van producten met digitale elementen. Dat vraagt niet alleen om een meldformulier, maar om een proces dat kwetsbaarheden herkent en opvolgt.
Door Ilja Vinzenz · · Circa 6 minuten leestijd
Bepaal eerst of je organisatie en product onder de regels vallen. Richt daarna de technische signalering, eigenaarschap, beoordeling en communicatie zo in dat een ernstig incident niet tussen teams blijft hangen.
Voor wie is deze meldplicht relevant?
De Cyber Resilience Act richt zich op producten met digitale elementen die op de markt worden gebracht. Dat kan ook software zijn. De precieze reikwijdte hangt af van het product en de rol van de organisatie, bijvoorbeeld fabrikant, importeur of distributeur. Ga niet uit van de aanname dat iedere website of elk maatwerkproject automatisch onder dezelfde productverplichtingen valt; laat de kwalificatie zo nodig toetsen.
Wat moet er sinds 11 september worden gemeld?
Volgens het Nationaal Cyber Security Centrum moeten fabrikanten een actief misbruikte kwetsbaarheid of een ernstig incident dat de beveiliging van hun digitale product raakt melden. Een kwetsbaarheid die wel bekend is maar nog niet aantoonbaar is misbruikt, valt niet automatisch onder deze meldplicht. Het NCSC vermeldt een vroegtijdige waarschuwing binnen 24 uur en een uitgebreidere melding binnen 72 uur nadat de fabrikant kennis krijgt van de situatie.
Een melding begint vóór het incident
- Houd een actueel overzicht bij van producten, versies, componenten en verantwoordelijke teams.
- Maak het mogelijk dat klanten en onderzoekers een kwetsbaarheid veilig kunnen melden.
- Leg vast wie bepaalt of er sprake is van actief misbruik of een ernstig incident.
- Zorg dat logs en technische context beschikbaar zijn zonder onnodige persoonsgegevens te verzamelen.
- Bereid een herstel- en communicatiepad voor gebruikers en leveranciers voor.
Maak afhankelijkheden zichtbaar
Een kwetsbaarheid kan ontstaan in eigen code, een gebruikte bibliotheek of een externe dienst. Een productteam moet weten welke versies waar zijn toegepast, wie een update kan testen en hoe getroffen gebruikers worden bereikt. Een inventarisatie van componenten is daarom pas bruikbaar als deze aan releases, monitoring en herstel is gekoppeld.
Verwar CRA niet met de Cyberbeveiligingswet
De CRA stelt eisen aan digitale producten en de partijen die ze op de markt brengen. De Nederlandse Cyberbeveiligingswet richt zich op de digitale weerbaarheid van organisaties in bepaalde sectoren. Een organisatie kan met beide kaders te maken krijgen, maar de reikwijdte en verantwoordelijkheden zijn verschillend. Voor de Cyberbeveiligingswet beschreven we eerder wat dit voor het beheer van API-koppelingen betekent.
Kijk ook naar het vervolg
De meldplicht is het eerste onderdeel dat nu geldt. Volgens de Rijksinspectie Digitale Infrastructuur volgen bredere producteisen, waaronder beveiliging vanaf het ontwerp en conformiteitsbeoordeling, op 11 december 2027. Gebruik de komende periode om productverantwoordelijkheid, kwetsbaarhedenbeheer en beveiligingsupdates structureel in te richten.
Veelgestelde vragen
Moet iedere gevonden kwetsbaarheid worden gemeld?
Nee. Het NCSC onderscheidt actief misbruikte kwetsbaarheden en ernstige beveiligingsincidenten van een nog niet misbruikte, intern of verantwoord gemelde kwetsbaarheid. Beoordeel de concrete situatie aan de hand van de officiële richtlijnen.
Valt een klantwebsite automatisch onder de CRA?
Nee, dat kun je niet zonder meer concluderen. De kwalificatie hangt af van het product, de manier waarop het beschikbaar wordt gesteld en de rol van de betrokken partijen.
Is dit juridisch advies?
Nee. Dit is een technisch en organisatorisch startpunt. Laat de formele toepasselijkheid en meldplicht beoordelen door een bevoegde specialist.
Lees ook hoe je uitval van een API-koppeling herkent en herstelt en bekijk onze aanpak voor maatwerksoftware.
Van inzicht naar uitvoering
Bekijk de diensten en expertise waarmee we dit vraagstuk analyseren en realiseren.
Verder lezen
Bekijk de andere inzichten binnen dit onderwerp voor aanvullende afwegingen en praktische uitleg.
Hoe ontwikkel je een cloud MVP in circa 90 dagen?
Van discovery en scope tot testen, lanceren en maandelijkse verbetering.
Lees het inzicht
Wat is een cloud MVP en wat hoort in de eerste versie?
Bepaal de kleinste betrouwbare productversie die echte waarde levert.
Lees het inzicht
Wat bepaalt de kosten van een maatwerk MVP?
Breng scope, techniek, kwaliteit en beheer samen in een realistische raming.
Lees het inzichtWaar loopt jouw organisatie vast in processen, systemen of data?
Vertel ons wat er speelt. In een eerste gesprek verkennen we de vraag, de randvoorwaarden en een passende vervolgstap.
