CRA-meldplicht vanaf 11 september 2026: wat u meldt

De meeste softwarebedrijven die van de Cyber Resilience Act gehoord hebben, hebben één datum onthouden: december 2027. Dat is wanneer de CE-markering en de essentiële productvereisten van kracht worden, en het voelt ver weg.

Er staat een andere datum in de verordening, en die is dichterbij. Vanaf 11 september 2026 geldt de meldplicht uit artikel 14. Vanaf dan moet u elke actief misbruikte kwetsbaarheid en elk ernstig incident binnen 24 uur melden. Zonder overgangsperiode, en ook voor software die u jaren geleden verkocht.

In het kort

• De meldplicht uit artikel 14 gaat in op 11 september 2026, vijftien maanden vóór de rest van de verordening.
• De klok start op het moment van kennisname, niet wanneer u een patch klaar hebt of wanneer de directie samenkomt.
• Alleen actief misbruikte kwetsbaarheden vallen eronder. Een gewone CVE-melding zonder aanwijzing van misbruik in het veld niet.
• U meldt via het centrale platform van ENISA, dat de melding deelt met het nationale CSIRT. In België is dat het Centrum voor Cybersecurity België.
• Software die vóór september 2026 op de markt kwam maar nog commercieel ondersteund wordt, valt er integraal onder.
• Inbreuken op de meldplicht vallen onder het zwaarste sanctieregime: tot 15 miljoen euro of 2,5 procent van de wereldwijde jaaromzet.

Wanneer gaat de meldplicht in en voor wie?

De meldplicht onder artikel 14 van de Cyber Resilience Act treedt in werking op 11 september 2026. Vanaf die datum moeten fabrikanten van software en verbonden producten actief misbruikte kwetsbaarheden en ernstige incidenten binnen 24 uur melden aan de toezichthouders, ruim vijftien maanden voordat de overige productverplichtingen en de CE-markeringseisen in december 2027 van kracht worden.

De faseringskalender

De wetgever koos in verordening (EU) 2024/2847 bewust voor verschillende overgangstermijnen. Productvereisten en conformiteitsbeoordelingen kregen 36 maanden. Voor de meldplicht werd dat ingekort tot 21 maanden, zodat toezichthouders vroeg zicht krijgen op de dreigingssituatie in de Europese toeleveringsketen.

Waarom bestaande software er meteen onder valt

Dit is het punt dat in vrijwel geen enkele Nederlandstalige publicatie helder staat, en het bepaalt of u volgende week iets te doen hebt.

De materiële ontwerpeisen uit bijlage I worden pas afdwingbaar vanaf december 2027, en dan voor producten die nieuw op de markt komen. Artikel 14 kent zo’n overgangsvrijstelling niet. Alle programmatuur die op 11 september 2026 commercieel wordt aangeboden of actief wordt onderhouden, valt onmiddellijk onder het meldregime. Een applicatie die u in 2021 opleverde en waarvoor u nog updates uitrolt, telt dus mee.

Wat u moet melden, en wat niet

De angst die in ontwikkelteams leeft, is bureaucratische verlamming door de dagelijkse stroom aan CVE-notificaties. Die angst is ongegrond, maar de grens moet u wel kennen.

Artikel 14 beperkt de meldplicht tot twee categorieën. Ten eerste actief misbruikte kwetsbaarheden in uw product: beveiligingslekken waarvoor betrouwbaar bewijs bestaat dat een kwaadwillende actor ze zonder toestemming uitvoert in een operationeel product. Ten tweede ernstige beveiligingsincidenten die de integriteit, beschikbaarheid of vertrouwelijkheid van het product of zijn cloudbackend aantasten.

Buiten de meldplicht vallen theoretische zwakheden, intern vastgestelde bugs, reguliere CVE-notificaties zonder exploitatie, en kwetsbaarheden die enkel in onderzoek zijn aangetoond zonder misbruik in het veld. Die handelt u af via uw normale ontwikkelcyclus, zoals beschreven in ons artikel over de secure development lifecycle.

Het praktische probleem voor een Vlaamse kmo zit in de verificatie. U beschikt zelden over de monitoring om vast te stellen of een lek in uw software daadwerkelijk misbruikt wordt bij een klant. Dat vergroot het risico op twee kanten: te weinig melden, of uit voorzichtigheid alles melden. Een vooraf vastgelegd triagecriterium lost dat op, en dat criterium ontwerpt u nu, niet tijdens een incident.

De meldketen in stappen

De verordening splitst de procedure op in twee trajecten met verschillende eindtermijnen. Dat onderscheid wordt vaak over het hoofd gezien.

Traject 1: actief misbruikte kwetsbaarheid

1. Vroegtijdige waarschuwing binnen 24 uur. Een beknopte notificatie dat er misbruik plaatsvindt, met aanduiding van het getroffen product en de lidstaten waar vermoedelijk impact optreedt.
2. Kwetsbaarheidsmelding binnen 72 uur. Een technisch rapport met de classificatie en ernst, indicatoren van de dreigingsactor voor zover bekend, en de reeds genomen of geplande noodmaatregelen.
3. Eindrapport binnen 14 dagen na mitigatie. Deze termijn hangt niet aan de 72-uursmelding maar aan het beschikbaar komen van de oplossing. Zodra u een patch, update of workaround hebt vrijgegeven, hebt u veertien dagen om de volledige analyse in te dienen.

Traject 2: ernstig beveiligingsincident

1. Vroegtijdige waarschuwing binnen 24 uur, met vermelding of het incident opzettelijk veroorzaakt lijkt en wat de vermoedelijke reikwijdte is.
2. Incidentmelding binnen 72 uur, met een gedetailleerde impactanalyse en vermelding van eventuele besmetting van andere systemen.
3. Eindrapport binnen één maand na de 72-uursmelding, met bronoorzakenanalyse en herstelmaatregelen.

Daarnaast verplicht artikel 14, lid 8 u om uw gebruikers zonder onnodige vertraging te informeren en hen concrete handvatten te geven om het risico te beperken. Die stap wordt in de praktijk het vaakst vergeten, terwijl ze commercieel het meest zichtbaar is.

Verschil met de NIS2-meldketen

Veel softwarebedrijven leveren aan essentiële entiteiten of vallen zelf onder de Belgische NIS2-wet. Beide regimes lijken op elkaar in de eerste twee fasen en verschillen daarna.

Aan wie meldt u in België?

Meldingen dient u in via het centrale platform van ENISA, dat de gegevens deelt met het coördinerend CSIRT van uw lidstaat van vestiging. Voor Belgische softwareleveranciers is dat het Centrum voor Cybersecurity België.

Over het markttoezicht is nog niet alles beslist, en dat zeggen we liever expliciet dan dat we het gladstrijken. Het CCB fungeert als operationeel coördinerend CSIRT voor de meldingen. De markttoezichtautoriteit die productinspecties uitvoert en boetes oplegt, moet echter formeel worden aangewezen in nationale wetgeving. Het BIPT bouwt daarvoor technische capaciteit op, mede in overleg met toezichthouders uit de buurlanden, en de FOD Economie houdt toezicht op algemene productveiligheid. De Belgische uitvoeringswet die dit definitief regelt, is op het moment van schrijven nog niet gepubliceerd in het Belgisch Staatsblad.

Dat verandert niets aan uw meldplicht per 11 september. Het betekent wel dat de handhavingspraktijk in België zich nog moet uitkristalliseren.

Wat er intern moet staan

Een beleidsdocument helpt u niet tijdens een actief incident. Wat u nodig hebt, is een keten die op vrijdagavond werkt.

Dat laatste is geen boutade. De 24-uursklok start niet wanneer uw directie samenkomt, maar op het exacte tijdstip waarop een technisch bevoegde medewerker betrouwbaar vaststelt dat een exploit in het veld actief is. Een melding die vrijdagavond om zes uur binnenkomt via een bugbountyplatform of via geautomatiseerde telemetrie, dwingt tot een notificatie vóór zaterdagavond zes uur.

Vier zaken moeten daarvoor klaarstaan.

• Een publiek meldkanaal. Een gecoördineerd kwetsbaarhedenbeleid met een security.txt-bestand op domeinniveau en duidelijke instructies in uw productdocumentatie. Meldingen van onderzoekers mogen niet verdwijnen in een algemene helpdeskmailbox.
• Een aanspreekpunt met mandaat, plus een vervanger. Een technisch onderlegde persoon die ook buiten kantooruren en tijdens verlofperiodes bevoegd is om te melden zonder directieberaad af te wachten.
• Vooraf geregistreerde toegang en sjablonen. Een account op het meldplatform en klaargezette teksten voor fase 1, 2 en 3, zodat u onder tijdsdruk geen uren verliest aan formulieren.
• Een actuele softwarestuklijst. Een machineleesbare inventaris van uw componenten, zodat u binnen minuten weet welke applicaties en versies een kwetsbare bibliotheek bevatten.

Dat laatste punt is geen luxe. Een softwarepakket bestaat gemiddeld voor het overgrote deel uit externe afhankelijkheden. Duikt er een zerodaykwetsbaarheid op in een breed gebruikte bibliotheek en wordt die actief benut tegen uw applicatie, dan draagt u de volledige meldlast, ook wanneer de upstreamcommunity nog geen oplossing heeft. Hoe u kwetsbaarheden structureel opvolgt, staat in ons artikel over vulnerability assessment.

“Wij bouwen enkel maatwerk voor Belgische klanten”

Dat argument hoort u vaak, en het is niet zonder grond. Levert u uitsluitend unieke code volgens de specificaties van één klant, waarbij alle intellectuele eigendomsrechten overgaan en de code nergens anders hergebruikt wordt, dan geldt dat onder het Europese productveiligheidsrecht als een dienstverrichting en niet als het in de handel brengen van een product. In dat strikt afgebakende scenario hoeft u geen CE-markering aan te brengen.

In de praktijk houdt die afbakening zelden stand, en wel om drie redenen.

Bijna geen enkel ontwikkelbureau bouwt vanaf nul. Zodra u een eigen basisarchitectuur, authenticatiemodule, dashboardframework of set gedeelde connectoren over meerdere opdrachten inzet, worden die herbruikbare componenten producten met digitale elementen.

Daarnaast werkt het via uw klanten door. Veel afnemers van maatwerksoftware zijn middelgrote tot grote ondernemingen die onder NIS2 vallen. Zij moeten de beveiliging van hun toeleveringsketen borgen en leggen de meldtermijnen contractueel op, ongeacht uw formele productstatus. Hoe die doorwerking verloopt, staat in ons artikel over ketenrisico.

Tot slot: host en onderhoudt u de clouddienst, API of database die de maatwerkapplicatie voedt, dan kwalificeert die centrale voorziening als een oplossing voor gegevensverwerking op afstand en valt ze onder de verordening. Puur SaaS is dus niet automatisch uitgesloten: wanneer uw cloudbackend nodig is om de kernfuncties van uw software te laten werken, telt hij mee.

Wat er op het spel staat

Inbreuken op artikel 13 en 14 vallen onder de zwaarste sanctiecategorie van de verordening: tot 15 miljoen euro of 2,5 procent van de totale wereldwijde jaaromzet van het voorgaande boekjaar, waarbij het hoogste bedrag geldt. Voor andere verplichtingen van distributeurs, importeurs en gemachtigden ligt het plafond op 10 miljoen euro of 2 procent. Het verstrekken van onjuiste of misleidende informatie aan toezichthouders kan tot 5 miljoen euro of 1 procent kosten.

De verordening verplicht lidstaten wel om bij het bepalen van boetes rekening te houden met de economische situatie van kmo’s en start-ups. Boetes moeten proportioneel zijn. Dat is geen vrijgeleide, maar het betekent dat de plafonds niet het richtsnoer zijn voor een bedrijf van twintig man.

Wie moet er deze week iets doen?

Niet iedereen die dit leest, heeft dezelfde urgentie. Drie profielen wel.

Verkoopt of onderhoudt u standaardsoftware, een SaaS-product of een applicatie met een cloudbackend, dan valt u vanaf 11 september onder de meldplicht en moet uw keten staan. Bouwt u maatwerk maar hergebruikt u eigen modules of host u de backend, dan geldt hetzelfde en is de eerste stap nagaan welke componenten die kwalificatie krijgen. Levert u aan bedrijven die onder NIS2 vallen, dan komt de verplichting hoe dan ook via uw contracten op u af, ook als u formeel buiten scope blijft.

Bent u zuiver dienstverlener zonder herbruikbare componenten en zonder eigen backend, dan hebt u tijd. Leg dat wel vast, want die kwalificatie moet u kunnen onderbouwen wanneer een klant erom vraagt.

Cyberplan helpt bij het inrichten van dat proces: het bepalen welke van uw producten binnen scope vallen, het opzetten van een gecoördineerd kwetsbaarhedenbeleid en een triagecriterium, en het testen of uw meldketen ook buiten kantooruren werkt. Wat er in uw situatie eerst moet gebeuren, bekijken we in een gesprek over uw CRA-verplichtingen.

Veelgestelde vragen

Wat is de eerste deadline van de Cyber Resilience Act?

11 september 2026. Vanaf die datum geldt de meldplicht voor actief misbruikte kwetsbaarheden en ernstige incidenten, vijftien maanden vóór de overige verplichtingen in december 2027.

Moet elke gevonden kwetsbaarheid gemeld worden?

Nee. Alleen kwetsbaarheden waarvoor betrouwbare aanwijzingen bestaan dat ze daadwerkelijk misbruikt worden in het veld. Theoretische bugs en gewone CVE-notificaties zonder exploitatie vallen erbuiten.

Begint de klok pas te lopen als er een patch is?

Nee. De termijn start op het moment van kennisname van het actieve misbruik. Een afgerond forensisch rapport of een beschikbare oplossing is geen voorwaarde.

Geldt de meldplicht voor software die al vóór 2026 is uitgebracht?

Ja. Vanaf 11 september 2026 geldt de meldplicht voor alle ondersteunde producten met digitale elementen die op de markt circuleren, ook wanneer die jaren eerder zijn uitgebracht.

Geldt de meldplicht als wij uitsluitend SaaS leveren?

Wanneer uw clouddienst functioneert als een oplossing voor gegevensverwerking op afstand die noodzakelijk is voor de kernfuncties van de software, valt die onder de verordening.

Wat als het lek in een opensourcebibliotheek zit?

Wordt dat lek actief misbruikt in uw product, dan meldt u het en informeert u de beheerder van de component. Wie opensourcecomponenten in commerciële software verwerkt, geldt juridisch als fabrikant.

Wie binnen een kmo mag melden?

Een formeel aangewezen aanspreekpunt met een vervanger, die het mandaat hebben om rechtstreeks te melden zonder vertragend directieberaad af te wachten.

Is het CCB de markttoezichthouder voor de CRA in België?

Nee. Het CCB treedt op als operationeel coördinerend CSIRT voor de meldingen. De markttoezichtautoriteit wordt aangewezen via nationale uitvoeringswetgeving, die op het moment van schrijven nog niet gepubliceerd is.

Hoe verhoudt dit zich tot de GDPR?

De verordening regelt productveiligheid. Leidt een beveiligingsincident ook tot een inbreuk op persoonsgegevens, dan blijft een afzonderlijke melding binnen 72 uur aan de Gegevensbeschermingsautoriteit verplicht.