26 augustus 2026 · 11 min leestijd · EU-regelgeving

CRA-rapportageplicht start 11 september 2026: de 24-uursklok uitgelegd

De meeste organisaties die zich in de Cyber Resilience Act hebben verdiept, hebben één datum onthouden: 11 december 2027. Dat is wanneer het merendeel van de verplichtingen gaat gelden — CE-markering, conformiteitsbeoordeling, de essentiële eisen uit Bijlage I.

Er is een eerdere datum, en die is veel dichterbij. Vanaf 11 september 2026 gelden de meldingsverplichtingen. Vanaf die dag moet u, als fabrikant van een product met digitale elementen, een actief misbruikte kwetsbaarheid in uw product binnen 24 uur melden. Ook voor producten die al lang op de markt zijn.

Dat is geen papieren verplichting die u in 2027 een keer inregelt. Het is een operationele klok die over een paar weken begint te lopen, en de meeste teams die wij spreken hebben er geen procedure voor.

Wat er precies gaat gelden

De Cyber Resilience Act is Verordening (EU) 2024/2847. De meldingsverplichtingen voor fabrikanten staan in artikel 14 en gaan in op 11 september 2026. Er zijn twee categorieën meldplichtige gebeurtenissen:

• Een actief misbruikte kwetsbaarheid in uw product met digitale elementen — dus niet elke kwetsbaarheid, maar een kwetsbaarheid waarvan u weet dat die in het wild wordt uitgebuit.
• Een ernstig incident dat de beveiliging van uw product heeft aangetast.

Voor beide gelden drie deadlines, en ze lopen parallel — niet achter elkaar.

Daarnaast moet u de getroffen gebruikers van uw product zonder onnodige vertraging informeren, en waar nodig over de corrigerende maatregelen die zij kunnen nemen.

Waar u meldt

U meldt één keer, via het Single Reporting Platform van ENISA (artikel 16). Dat platform routeert uw melding naar het CSIRT dat is aangewezen als coördinator — in beginsel dat van de lidstaat waar u uw hoofdvestiging heeft — en stelt de melding tegelijkertijd beschikbaar aan ENISA. Voor Nederlandse fabrikanten ligt het NCSC hier voor de hand; de formele aanwijzing is nationale invulling en de moeite van het natrekken waard voordat u uw procedure vastlegt.

Het platform is bedoeld om operationeel te zijn op 11 september 2026. Reken er niet op dat u op dag één een soepele interface aantreft, en reken er zeker niet op dat u dan pas voor het eerst gaat uitzoeken wie bij u de melding indient.

Valt u eronder? De vraag die de meesten verkeerd beantwoorden

De CRA gaat over producten met digitale elementen die op de markt worden aangeboden. Dat is een bredere categorie dan "IoT-apparaten", en tegelijk een smallere dan "alles wat software is".

De grens die de meeste verwarring geeft, loopt bij SaaS:

• Zuivere SaaS en clouddiensten vallen in beginsel buiten de CRA. Een clouddienst die is ontworpen en ontwikkeld buiten de verantwoordelijkheid van een fabrikant van een product met digitale elementen, valt niet onder deze verordening. Websites die de functionaliteit van zo'n product niet ondersteunen, evenmin.
• Maar oplossingen voor gegevensverwerking op afstand vallen er wél onder wanneer de software door of namens de fabrikant van het product is ontwikkeld en het product zonder die verwerking een van zijn functies niet zou kunnen uitvoeren. Dan wordt de backend behandeld als onderdeel van het product.

In de praktijk betekent dat: levert u een agent, een on-premise component, een desktopapplicatie, een mobiele app of een apparaat dat alleen werkt in combinatie met úw backend, dan is het samenstel waarschijnlijk een product met digitale elementen — inclusief die backend. Levert u een webapplicatie die op zichzelf staat en die uw klant in een browser gebruikt, dan is de kans groot dat u buiten scope valt, en dan is dit artikel voor u informatief in plaats van urgent.

Dat onderscheid is geen detail. Het bepaalt of u over drie weken een 24-uursprocedure moet hebben draaien of niet, en het is de moeite waard om het met uw jurist op papier te zetten in plaats van het af te leiden uit een blogpost — deze ook niet.

"Kennis nemen van" is het scharnierpunt

De klok van 24 uur begint niet bij het incident. Hij begint op het moment dat u er kennis van neemt — en dat wordt uitgelegd als het moment waarop u, na een eerste beoordeling, met een redelijke mate van zekerheid vaststelt dat een kwetsbaarheid in uw product actief wordt misbruikt of dat een ernstig incident de beveiliging heeft aangetast.

Twee dingen volgen daaruit, en ze wijzen in tegengestelde richtingen.

Het eerste is prettig: u hoeft niet binnen 24 uur na een vaag signaal te melden. Er zit een beoordelingsstap in. Een ruwe melding van een onderzoeker, een anomalie in uw logs of een gerucht op een mailinglijst zet de klok niet meteen in gang.

Het tweede is minder prettig: die beoordelingsstap moet daadwerkelijk bestaan en moet snel zijn. Als binnenkomende signalen bij u vier dagen in een gedeelde mailbox blijven liggen voordat iemand ernaar kijkt, dan is dat geen verdediging — het is precies het gat waar een toezichthouder achteraf naar zal wijzen. De verplichting die u feitelijk moet organiseren is niet "melden binnen 24 uur". Het is "elk binnenkomend beveiligingssignaal binnen uren beoordelen, met vastlegging van wanneer en door wie".

Wat u op 11 september geregeld moet hebben

Concreet, en zonder dat er inkoop aan te pas hoeft te komen:

1. Eén ingang voor beveiligingsmeldingen die iemand daadwerkelijk leest. Een security.txt op uw domein en een gepubliceerd meldadres. Onderzoekers en CERT's moeten u kunnen bereiken zonder een supportformulier in te vullen.
2. Een aangewezen persoon en een plaatsvervanger die de eerste beoordeling doen en die de melding mogen indienen. Met een bereikbaarheidsafspraak, want kwetsbaarheden verschijnen op vrijdagavond.
3. Een registratie bij het Single Reporting Platform, uitgezocht en klaargezet vóór de dag dat u hem nodig heeft.
4. Drie concepten klaar — early warning, 72-uursmelding, eindrapport. U wilt om 23:00 uur een sjabloon invullen, geen sjabloon schrijven.
5. Een tijdlijn die u kunt reconstrueren. Wanneer kwam het signaal binnen, wanneer is het beoordeeld, wanneer werd het "redelijke mate van zekerheid". Zonder tijdstempels kunt u achteraf niet aantonen dat u binnen 24 uur was.
6. Weten wat er in uw product zit en wat er sinds de laatste beoordeling aan veranderd is. De eerste vraag bij een gemeld misbruik is of het uw code, uw afhankelijkheid of uw configuratie betreft. Als u dat niet snel kunt beantwoorden, verbrandt u het grootste deel van uw 24 uur aan uitzoekwerk.

Wat continu scannen hier wél en niet oplost

Wij verkopen scanning, dus laten we eerlijk zijn over de grens.

Wat scanning niet doet: een scanner vertelt u niet dat een kwetsbaarheid actief wordt misbruikt. Dat is dreigingsinformatie en detectie, en het komt vrijwel altijd van buiten — een onderzoeker, een CERT-advisory, een klant, uw eigen monitoring. Een scanner dient ook geen melding voor u in, en vervangt geen juridische scope-analyse. Wie u vertelt dat een tool u "CRA-compliant" maakt, verkoopt u iets dat niet bestaat.

Wat het wel doet, en het is precies de twee dingen die de 24-uursklok draaglijk maken:

• Het verkleint het venster waarin een kwetsbaarheid in uw product bestaat zonder dat u ervan weet. Het slechtste CRA-scenario is niet dat u moet melden. Het is dat u moet melden over iets dat al maanden in uw product zat, dat een externe partij eerder vond dan u, en dat u nu binnen 24 uur moet duiden terwijl u het zelf voor het eerst ziet.
• Het produceert de gedateerde vaststelling waarop uw beoordeling kan steunen. Als er een melding binnenkomt over een endpoint van uw product, is de vraag "hebben wij dit eerder gezien, en wat was toen de stand?" Met een reeks rapporten met tijdstempels is dat een opzoekactie van tien minuten. Zonder is het een dag graafwerk binnen een deadline van 24 uur.

Dat is een bescheiden claim, en het is de juiste. De CRA-meldplicht is een procesverplichting. Scanning maakt het proces uitvoerbaar; het vervangt het niet.

Bronnen