De Cyber Resilience Act (CRA, Verordening (EU) 2024/2847) is eind 2024 in werking getreden, maar de eerste verplichting die echt gaat knellen, staat gepland voor 11 september 2026. Vanaf die datum geldt artikel 14: de meldplicht voor actief uitgebuite kwetsbaarheden en ernstige incidenten. De volledige productverplichtingen volgen pas op 11 december 2027, maar wie hardware of software op de EU-markt brengt, moet ruim daarvoor al een werkend meldproces hebben. In dit artikel staat wat de meldplicht inhoudt, voor wie hij geldt en hoe je met een korte zelfassessment toetst of je er klaar voor bent.
Wat je moet melden
De meldplicht draait om twee situaties. De eerste is een actief uitgebuite kwetsbaarheid: een kwetsbaarheid in je product waarvan je betrouwbare aanwijzingen hebt dat een kwaadwillende die daadwerkelijk misbruikt. Een kwetsbaarheid die je zelf vindt en patcht voordat er misbruik van wordt gemaakt, valt hier dus niet onder. Een reguliere beveiligingsupdate ook niet. Het gaat om het moment waarop kwetsbaarheid en daadwerkelijke uitbuiting samenkomen.
De tweede situatie is een ernstig incident met gevolgen voor de beveiliging van het product zelf. Denk aan een compromittering van je build- of updateomgeving waardoor kwaadaardige code in het product terecht kan komen, of een aantasting van de beschikbaarheid, integriteit of vertrouwelijkheid van gevoelige functies of gegevens in het product.
Beide categorieën gaan over het product, niet over je organisatie. Dat is het wezenlijke verschil met de incidentmeldplicht onder NIS2 en de Cyberbeveiligingswet, die op de dienstverlening en de organisatie zien. Een fabrikant kan met beide meldplichten tegelijk te maken krijgen.
De meldtrappen: 24 uur, 72 uur, eindverslag
Artikel 14 werkt met een getrapt regime. Bij een actief uitgebuite kwetsbaarheid geldt: een vroegtijdige waarschuwing binnen 24 uur nadat je er kennis van hebt gekregen, een kwetsbaarheidsmelding binnen 72 uur met de aard van de kwetsbaarheid, de ernst en de getroffen of geplande corrigerende maatregelen, en een eindverslag uiterlijk 14 dagen nadat een corrigerende of risicobeperkende maatregel beschikbaar is. Bij een ernstig incident zijn de eerste twee trappen gelijk (24 en 72 uur) en volgt het eindverslag binnen een maand na de incidentmelding.
Melden doe je bij ENISA én bij de CSIRT die als coördinator is aangewezen in de lidstaat waar je je hoofdvestiging hebt. Dat is volgens de verordening de lidstaat waar de beslissingen over de cybersecurity van je producten hoofdzakelijk worden genomen; voor de meeste Nederlandse fabrikanten dus de Nederlandse CSIRT-coördinator. Beide meldingen verlopen via een gezamenlijk elektronisch meldplatform. Daarnaast moet je, waar relevant, de getroffen gebruikers van het product informeren over het incident of de kwetsbaarheid en over maatregelen die zij zelf kunnen treffen.
Wie onder de meldplicht valt
De meldplicht ligt bij de fabrikant van een product met digitale elementen dat op de EU-markt is aangeboden. Fabrikant ben je ook als je software ontwikkelt en commercieel aanbiedt, of als je een bestaand product onder eigen naam verkoopt of er een substantiële wijziging in aanbrengt. Importeurs en distributeurs hebben een afgeleide rol: horen zij van een kwetsbaarheid in een product, dan moeten zij de fabrikant informeren.
Belangrijk is dat de meldplicht vanaf 11 september 2026 geldt voor producten die dan op de markt zijn, dus ook voor producten die je jaren geleden hebt uitgebracht en nog ondersteunt. Wachten tot de volgende productrelease is geen optie.
Wat dit operationeel van je vraagt
Een termijn van 24 uur haal je niet met een procedure op papier. Er moet een keten staan die drie dingen kan: signaleren, beslissen en melden. Signaleren betekent dat meldingen over kwetsbaarheden je bereiken: een gepubliceerd beveiligingsbeleid met een contactpunt voor melders (coordinated vulnerability disclosure), monitoring van je eigen telemetrie en van externe bronnen over actieve uitbuiting. Beslissen betekent dat iemand met mandaat binnen enkele uren kan beoordelen of iets meldplichtig is, ook op zaterdagavond. Melden betekent dat je weet waar het meldplatform te vinden is, wie toegang heeft en welke informatie de eerste melding minimaal moet bevatten.
Wie al een incident-response-proces heeft voor ISO 27001 of NIS2, heeft een basis, maar niet meer dan dat. De CRA-meldplicht vraagt productkennis: welke versies zijn geraakt, wat is de corrigerende maatregel, hoe bereik je de gebruikers van het product. Dat vraagt om samenwerking tussen security, productontwikkeling en support die je vooraf moet organiseren.
Zelfassessment: ben je er klaar voor?
Onderaan dit artikel staat een interactieve zelfassessment met 19 vragen uit onze auditpraktijk. Deel A bepaalt of en in welke rol de CRA op jullie van toepassing is (fabrikant, importeur, distributeur of eigen-merkverkoper). Deel B toetst per thema of je klaar bent voor de meldplicht: van productregister, SBOM en disclosure-beleid tot het beslisproces buiten kantooruren, de 24- en 72-uursmeldingen en de tabletop-oefening. Elke nee of deels levert een concreet actiepunt op, met advies en een verwijzing naar verdieping.
Een hoge score betekent niet dat je klaar bent met de CRA, maar wel dat de meldplicht van september geen paniek gaat opleveren. Scoor je laag, begin dan nu: een deel van deze punten (SBOM's opbouwen, disclosure-beleid inrichten, oefenen) kost maanden.
Na september komt december 2027
De meldplicht is de eerste trap. Op 11 december 2027 worden de volledige verplichtingen van toepassing: essentiële cybersecurity-eisen aan het productontwerp, conformiteitsbeoordeling en CE-markering, technische documentatie en een gestructureerd kwetsbaarhedenbeheer gedurende de ondersteuningsperiode. De niet-naleving van de essentiële eisen kan boetes opleveren tot 15 miljoen euro of 2,5 procent van de wereldwijde jaaromzet. Wie het meldproces voor september 2026 goed neerzet, legt meteen een fundament voor die tweede trap: dezelfde inventarisatie, dezelfde SBOM's en hetzelfde kwetsbaarhedenproces heb je daar weer nodig.
Bron: Verordening (EU) 2024/2847 (Cyber Resilience Act), artikel 14 (meldplicht), artikel 69 (overgangsbepaling) en artikel 71 (toepassingsdata), via EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/2847/oj
Secure Audit helpt fabrikanten, importeurs en distributeurs bij het beoordelen van hun CRA-verplichtingen, het inrichten van het meldproces en kwetsbaarhedenbeheer, en het voorbereiden op de conformiteitsbeoordeling van december 2027. Neem contact op voor een CRA readiness scan.
Interactieve CRA-check
Beantwoord 19 vragen in twee delen. Deel A bepaalt of en in welke rol de CRA op jullie van toepassing is, deel B toetst of je klaar bent voor de meldplicht van 11 september 2026. De check is opgesteld door IT-auditors en is indicatief: het resultaat is geen juridisch advies. Na het invullen laat je je naam en e-mailadres achter; daarmee sturen we je het resultaat toe.
Deel A: valt jullie organisatie onder de CRA?
Brengen jullie hardware of software commercieel op de EU-markt?
De CRA geldt voor producten met digitale elementen: van IoT-apparaten, routers en industriële besturingen tot standalone software en apps. Ook producten die je gratis aanbiedt als onderdeel van een commerciële activiteit tellen mee.
Ontwikkelen jullie die producten zelf, of laten jullie ze ontwikkelen en verkopen jullie ze onder eigen naam?
Wie een product met digitale elementen ontwikkelt of laat ontwikkelen en het onder eigen naam of merk op de markt brengt, is fabrikant in de zin van de CRA. Dat geldt ook voor softwarebedrijven.
Importeren of distribueren jullie producten van andere fabrikanten?
Importeurs brengen producten van buiten de EU op de markt; distributeurs stellen producten van anderen beschikbaar.
Passen jullie bestaande producten van derden substantieel aan voordat je ze levert?
Bijvoorbeeld eigen firmware op ingekochte hardware, een fork van bestaande software of ingrijpende aanpassingen aan een wit-labelproduct.
Hoort bij jullie product een clouddienst die nodig is om het product te laten werken?
Denk aan de backend van een IoT-apparaat of een companion-app met cloudverwerking. Dit heet in de CRA een oplossing voor gegevensverwerking op afstand.
Vallen jullie producten in een belangrijke of kritieke productcategorie?
De CRA kent verzwaarde categorieën, zoals wachtwoordmanagers, VPN-oplossingen, firewalls, hypervisors en identiteits- en toegangsbeheersoftware (belangrijk, klasse I of II) en bijvoorbeeld smartcards en smart-meter-gateways (kritiek).
Deel B: ben je klaar voor de meldplicht?
Kies N.v.t. als een onderwerp niet op jullie van toepassing is op basis van deel A, bijvoorbeeld omdat jullie uitsluitend distributeur zijn.
Hebben jullie een actueel overzicht van alle producten en versies die op de EU-markt zijn, inclusief ondersteuningsperiode en einde-levensduur?
De meldplicht geldt vanaf 11 september 2026 ook voor producten die al jaren op de markt zijn. Zonder inventarisatie weet je niet waarover je moet kunnen melden.
Is per product vastgelegd welke CRA-rol jullie hebben: fabrikant, importeur of distributeur?
De rol bepaalt de verplichtingen. Let op wit-labelconstructies en substantiële wijzigingen: dan gelden fabrikantverplichtingen, ook al staat er een andere naam op de doos.
Hebben jullie per product een actuele, machineleesbare Software Bill of Materials?
Bij een kwetsbaarheid in een veelgebruikte component (denk aan een Log4j-scenario) moet je binnen uren weten welke producten en versies geraakt zijn. Dat kan alleen met een SBOM die bij elke release wordt bijgewerkt.
Is er een gepubliceerd coordinated vulnerability disclosure-beleid met een bewaakt contactpunt?
Onderzoekers en klanten moeten kwetsbaarheden eenvoudig kunnen melden, en die meldingen moeten aantoonbaar worden opgepakt. Een security.txt en een e-mailadres dat niemand leest, is niet genoeg.
Monitoren jullie actief op signalen dat een kwetsbaarheid in je product wordt uitgebuit?
De 24-uurstermijn begint zodra je kennis hebt van actieve uitbuiting. Wie niet monitort, hoort het van een ander, en vaak te laat. Denk aan eigen telemetrie, threat intelligence, lijsten van actief uitgebuite kwetsbaarheden en klantmeldingen.
Is de kwetsbaarhedenketen met component- en toeleveranciers geregeld, in beide richtingen?
Kwetsbaarheden ontstaan vaak in een ingebouwde component. Jullie moeten meldingen daarover kunnen ontvangen én, als jullie zelf een kwetsbaarheid in een component vinden, de maker van die component informeren.
Is vastgelegd wie beoordeelt of iets meldplichtig is, met criteria, en is die rol ook buiten kantooruren belegd?
Niet elke kwetsbaarheid is meldplichtig: het gaat om actieve uitbuiting en om ernstige incidenten met gevolgen voor de beveiliging van het product. Iemand met mandaat moet dat onderscheid binnen enkele uren kunnen maken, ook op zaterdagavond.
Kunnen jullie aantoonbaar binnen 24 uur een vroegtijdige waarschuwing indienen?
Dat vraagt toegang tot het meldplatform, kennis van de CSIRT-coördinator van de lidstaat waar je hoofdvestiging staat, een sjabloon voor de vroegtijdige waarschuwing en iemand die dit kan uitvoeren op het moment dat het nodig is.
Staat er een proces voor de 72-uursmelding en het eindverslag?
Binnen 72 uur moet je de aard en ernst van de kwetsbaarheid en de corrigerende maatregelen kunnen aanleveren. Het eindverslag volgt uiterlijk 14 dagen nadat een corrigerende maatregel beschikbaar is (kwetsbaarheid) of binnen een maand (ernstig incident).
Leggen jullie beoordelingen vast, ook wanneer de conclusie is dat iets níet meldplichtig is?
Achteraf kan de vraag komen waarom een kwetsbaarheid niet is gemeld. Zonder vastgelegde beoordeling sta je dan met lege handen.
Kunnen jullie een compromittering van de eigen ontwikkel-, build- of update-omgeving detecteren?
Een aanvaller die via jullie update-mechanisme kwaadaardige code bij klanten kan krijgen, is het schoolvoorbeeld van een ernstig incident onder de CRA. Dit scenario wordt vaak vergeten omdat het niet om een kwetsbaarheid in de productcode zelf gaat.
Kunnen jullie de gebruikers van een product gericht informeren over een kwetsbaarheid of incident?
De CRA vraagt om gebruikers waar relevant te informeren, inclusief maatregelen die zij zelf kunnen treffen. Dat vraagt een actueel beeld van wie welk product en welke versie gebruikt, en een kanaal dat die groep bereikt.
Hebben jullie het meldproces geoefend met een realistisch scenario?
Een tabletop-oefening rond een fictieve actief uitgebuite kwetsbaarheid legt binnen een dagdeel bloot waar het proces hapert: onduidelijk mandaat, ontbrekende sjablonen, onbereikbare mensen.
0 van 19 vragen beantwoord
Veelgestelde vragen
Wanneer gaat de CRA-meldplicht in?+
Op 11 september 2026. Vanaf die datum moeten fabrikanten actief uitgebuite kwetsbaarheden en ernstige incidenten melden volgens artikel 14 van de verordening. De volledige productverplichtingen volgen op 11 december 2027.
Moet ik elke kwetsbaarheid in mijn product melden?+
Nee. De meldplicht geldt voor actief uitgebuite kwetsbaarheden: er zijn betrouwbare aanwijzingen dat een kwaadwillende de kwetsbaarheid daadwerkelijk misbruikt. Kwetsbaarheden die je vindt en verhelpt voordat er misbruik plaatsvindt, hoef je niet via het meldplatform te melden.
Bij wie moet ik melden?+
Bij ENISA en bij de CSIRT die als coördinator is aangewezen in de lidstaat waar je je hoofdvestiging hebt (de lidstaat waar de cybersecuritybeslissingen over je producten hoofdzakelijk worden genomen). Beide meldingen verlopen via een gezamenlijk elektronisch meldplatform. Daarnaast moet je waar relevant de getroffen gebruikers van het product informeren.
Welke termijnen gelden er?+
Een vroegtijdige waarschuwing binnen 24 uur, een vervolgmelding binnen 72 uur en een eindverslag: uiterlijk 14 dagen nadat een corrigerende maatregel beschikbaar is bij een actief uitgebuite kwetsbaarheid, of binnen een maand bij een ernstig incident.
Geldt de meldplicht ook voor producten die al op de markt zijn?+
Ja. De meldplicht geldt vanaf 11 september 2026 voor producten met digitale elementen die op de EU-markt zijn aangeboden, ook als ze eerder zijn uitgebracht en nog worden ondersteund.
Lees ook
De Cyber Resilience Act verplicht CE-markering voor cybersecurity op alle digitale producten in de EU. IoT-apparaten, software en connected devices moeten security by design zijn. Meldplicht van 24 uur, SBOM-verplichting en boetes. Dit moet je weten als fabrikant of importeur.
Een incident response plan is verplicht bij vrijwel elk auditframework. Lees wat erin moet staan en hoe een auditor het beoordeelt.
De NIS2-richtlijn is van kracht en de Nederlandse implementatiewet nadert. Veel organisaties weten dat ze iets moeten doen, maar niet wat. Dit artikel beschrijft de concrete stappen die organisaties nu moeten nemen om compliant te worden.
Hulp nodig bij security?
Hoe veilig is uw IT-omgeving werkelijk? Wij testen het met vulnerability scans en pentests, en begeleiden de implementatie van ISO 27001 en IEC 62443.
Bekijk SecurityOver de auteur
Partner | IT-auditor