Vandaag geldt de CRA-meldplicht: wat een plugin-aanbieder nu doet

Vandaag is het 11 september 2026, en daarmee geldt artikel 14 van de Cyber Resilience Act. De officiële titel is meldplichten van de fabrikant. Dat het vanaf precies deze datum van toepassing is, staat in artikel 71 van Verordening (EU) 2024/2847.

Over de CRA is inmiddels veel geschreven, bijna alles op dezelfde hoogte: er is een meldplicht, er zijn termijnen, begin op tijd. Wat ontbreekt is het deel dat telt wanneer er echt een mail binnenkomt waarin iemand een misbruikt lek in jouw plugin beschrijft. Welke instantie, welke termijn vanaf welk moment, en wat je in de uren daarna opschrijft.

Dat staat hier. Het is een inschatting op de onderzoeksstand van 21 augustus 2026 en geen juridisch advies. Waar een gegeven onzeker was, staat dat er uitdrukkelijk bij.

Over wie het hier eigenlijk gaat

Twee definities dragen de hele zaak. Een product met digitale elementen is volgens artikel 3, punt 1, een software- of hardwareproduct samen met de bijbehorende gegevensverwerking op afstand, uitdrukkelijk inclusief onderdelen die afzonderlijk in de handel worden gebracht. Een los verspreide plugin valt daarmee onder de tekst. Fabrikant is volgens artikel 3, punt 13, wie zulke producten ontwikkelt of laat ontwikkelen en ze onder eigen naam of eigen merk op de markt brengt, tegen betaling, tegen monetisering of gratis. Ook een gratis plugin die met jouw naam in de directory staat, maakt je volgens de tekst tot fabrikant.

Eerlijk erbij: die lezing is goed te onderbouwen vanuit de primaire definities, maar er bestaat tot vandaag geen uitspraak van een autoriteit of van de Commissie die WordPress-plugins uitdrukkelijk noemt.

Drie data, en maar één daarvan is vandaag

De CRA komt in fasen, en dat is de meest voorkomende verwarring in gesprekken erover. Artikel 71 noemt drie data:

• 11 juni 2026: hoofdstuk IV geldt, de regels over de aangemelde instanties. Voor een plugin-aanbieder zonder conformiteitsbeoordeling verandert er niets.
• 11 september 2026: artikel 14 geldt, de meldplichten. Dat is vandaag.
• 11 december 2027: de rest van de verordening geldt. Daaronder vallen CE-markering, technische documentatie, conformiteitsbeoordeling en de softwarestuklijst uit bijlage I, deel II.

Wat vandaag begint, is de plicht om te melden als er iets gebeurt. Wat in 2027 begint, is de plicht om doorlopend aan te tonen hoe je ontwikkelt. Wie vandaag SBOM-gereedschap koopt, koopt voor over twee jaar.

Twee meldsporen met eigen termijnen

De formule 24 uur, 72 uur, 14 dagen staat in bijna elk overzichtsartikel. Ze beschrijft precies één van de twee gevallen die artikel 14 regelt. Het tweede geval heeft dezelfde eerste twee trappen en een andere einddatum.

Spoor 1: actief misbruikte kwetsbaarheid

Spoor 2: ernstig beveiligingsincident

Twee dingen vallen op die in de korte formule verdwijnen. Ten eerste is het eindverslag bij het incident na een maand aan de beurt, en niet na 14 dagen. De Duitse autoriteit BSI noemt die maandtermijn op haar eigen pagina's. Ten tweede starten de termijnen niet allemaal op dezelfde plek: de 24 en de 72 uur lopen vanaf het moment dat je het weet, de 14 dagen lopen vanaf het moment dat er een oplossing beschikbaar is, en de maand loopt vanaf het moment dat je de melding van 72 uur hebt ingediend.

In de praktijk betekent dat: het eindverslag in het kwetsbaarheidsspoor kan weken na de vroegtijdige waarschuwing aan de beurt zijn. De agenda-afspraak ervoor ontstaat pas als de fix er is.

Wat de meldplicht in gang zet, en wat niet

Een actief misbruikte kwetsbaarheid vraagt om stevige aanwijzingen dat een aanvaller haar daadwerkelijk misbruikt. Een ernstig beveiligingsincident is een gebeurtenis die het vermogen van het product om de beschikbaarheid, authenticiteit, integriteit of vertrouwelijkheid van gegevens te beschermen nadelig beïnvloedt of kan beïnvloeden.

Een gewone fout zet geen melding in gang, een routine-update evenmin. Een lek dat een beveiligingsonderzoeker bij je meldt en dat niemand misbruikt, hoort in het normale herstelpad. Wie aanwijzingen van lopend misbruik krijgt en er drie dagen over nadenkt, is de eerste termijn kwijt. Dat onderscheid is de vraag die je bij ernst als eerste beantwoordt.

De tweede plicht, die vaak ondersneeuwt

Artikel 14, lid 8, verplicht de fabrikant om de gebruikers van het product te informeren over de kwetsbaarheid of het incident en, waar relevant, over maatregelen die gebruikers zelf kunnen nemen, waar nodig in machineleesbaar formaat.

Dat is een zelfstandige plicht naast de melding aan de autoriteiten, en voor een plugin-aanbieder het zichtbaarste deel van de verordening, want elke klant krijgt het mee. Zonder voorbereiding sneuvelt juist dit deel als eerste: verspreid je je plugin gratis via wordpress.org, dan ken je je gebruikers niet. Je hebt het updatekanaal, de release notes en de readme. Wie updates toch laat liggen, krijgt de informatie ook niet als je haar netjes verstuurt, en daarmee begint een ander onderwerp, dat van WordPress-plugins bijwerken.

Waar de melding heen gaat, en waarom dat vandaag nog stroef loopt

Er wordt tegelijk gemeld aan het coördinerende CSIRT en aan ENISA, via het centrale meldplatform uit artikel 16, de Single Reporting Platform. Het ontvangende CSIRT verdeelt de melding naar de CSIRT's van de overige lidstaten waar jouw product wordt aangeboden.

Zover de verordening. De werkelijkheid op 21 augustus 2026 zag er zo uit:

• Het platform was niet publiek bereikbaar. ENISA formuleerde het in de toekomende tijd: vanaf 11 september 2026 zal het door CSIRT's en fabrikanten worden gebruikt voor de verplichte meldingen.
• Er was geen publieke registratielink. Het productieadres van het platform was nog niet gepubliceerd.
• Er waren handleidingen van ENISA voor registratie en voor het indienen van meldingen, laatst bijgewerkt in juli en augustus 2026, en een helpdeskadres: cra-srp-helpdesk@enisa.europa.eu.
• Volgens die handleidingen loopt het inloggen via EU Login. Bij de eerste toegang worden rol, bevoegd CSIRT, een juridische overeenkomst en fabrikantgegevens vastgelegd.

Een ENISA-update van 3 augustus 2026 haalt wat druk weg. De validatie van je account door het coördinerende CSIRT is geen voorwaarde om aan je meldplicht te hebben voldaan; ze loopt parallel, een nog niet vrijgegeven account leidt dus niet vanzelf tot een overtreding. Het doorzetten naar CSIRT's van andere lidstaten gebeurt handmatig. En ENISA adviseert om het EU Login-account vooraf aan te maken, maar de registratie op het platform pas te doen wanneer er een concrete melding ligt. Deze punten komen uit een secundaire bron, de handleidingen van ENISA zelf waren niet vrij op te vragen.

Het nationale stuk: aan welke instantie je meldt

Er wordt gemeld aan het CSIRT van de lidstaat van je hoofdvestiging. Welke instantie dat is verschilt per land, want elke lidstaat wijst haar zelf aan. Zoek de jouwe op voordat je haar nodig hebt en zet haar naast je beveiligingsadres.

Duitsland dient als voorbeeld, omdat de aanwijzing daar al gepubliceerd is: het BSI met CERT-Bund. Het BSI bevestigt op zijn eigen pagina's de trap van termijnen inclusief het eindverslag na een maand, en verwijst voor het platform naar ENISA. De Duitse uitvoeringswet was op 21 augustus 2026 nog niet in werking. Het wetsvoorstel ligt er als Bundestag-document 21/6134 van 26 mei 2026, eerste lezing op 11 juni 2026, daarna doorverwezen naar de commissie voor binnenlandse zaken, zonder bezwaren van de Bundesrat. Het schept geen nieuwe plichten, het verdeelt bevoegdheden. In andere lidstaten volgt de nationale uitvoering een eigen tijdlijn.

De vergelijking met de AI Act is leerzaam. Daar is de Duitse uitvoeringswet sinds 29 juli 2026 in werking. Bij de CRA zit ze nog in de procedure, terwijl de verordening vandaag rechtstreeks geldt. Een verordening wacht niet op de nationale begeleidingswet, en dat geldt in elke lidstaat waar je gevestigd bent.

Wat de gemiste melding kost

Artikel 64, lid 2, noemt voor inbreuken op de essentiële eisen uit bijlage I en op de verplichtingen uit de artikelen 13 en 14 boetes tot 15.000.000 euro of, bij ondernemingen, tot 2,5 procent van de totale wereldwijde jaaromzet van het voorgaande boekjaar, afhankelijk van welk bedrag hoger is. Die laatste formulering wordt vaak weggelaten, en dan draait de betekenis om. Het is geen keuze naar beneden.

Ter plaatsing: artikel 64, lid 3, voorziet in tot 10.000.000 euro of 2 procent voor andere verplichtingen, en lid 4 in tot 5.000.000 euro of 1 procent voor onjuiste, onvolledige of misleidende informatie aan aangemelde instanties en markttoezichtautoriteiten.

En dan staat er in artikel 64, lid 10, een uitzondering die bijna niemand kent. Boetes gelden niet voor fabrikanten die micro-onderneming of kleine onderneming zijn, voor zover het gaat om het missen van de termijn uit artikel 14, lid 2, punt a, of artikel 14, lid 4, punt a. Dat zijn de twee vroegtijdige waarschuwingen van 24 uur. Ook beheerders van opensourcesoftware, de open-source software stewards, zijn van boetes op grond van die bepaling uitgezonderd.

Die uitzondering is smal, en ze wordt geregeld te ruim gelezen. Ze betreft de termijn van de vroegtijdige waarschuwing. Ze bevrijdt niet van de meldplicht zelf, ze dekt de melding van 72 uur niet en ze dekt het eindverslag niet. Een kleine aanbieder die helemaal niet meldt, valt daarmee in hetzelfde boetekader als een grote.

De eerste 24 uur, praktisch

Het verloop hieronder is een werkmodel en geen weergave van wettelijke formuliereisen. De verordening noemt termijnen en geadresseerden. Welke velden het meldformulier van het platform echt vraagt, was op 21 augustus 2026 niet openbaar in te zien. Wat hier staat, is wat je voor een melding hoe dan ook bij elkaar moet zoeken.

Uur nul. De melding komt binnen, per mail op je beveiligingsadres, via het supportforum of via een disclosureplatform. Leg datum en tijd op de minuut vast. Daar begint de termijn, en dat is het ene gegeven dat je later niet meer kunt reconstrueren.

Eerste uur. Eén persoon beslist welk spoor. Zijn er aanwijzingen voor daadwerkelijk misbruik, logregels, gecompromitteerde installaties, een publieke exploit? Dan spoor 1. Is er iets gebeurd dat de beschermende werking van het product aantast, een gemanipuleerde update of een inbraak in je build-infrastructuur? Dan spoor 2. Allebei tegelijk kan, en bij twijfel geldt het strengste spoor. De beslissing wordt schriftelijk vastgelegd.

Tot uur vier. Omvang bepalen: welk product, welke versies, sinds wanneer, welke opstelling is betrokken, of er een tegenmaatregel is zonder update. Ondertussen contact houden met de melder, zodat die niet tussentijds publiceert.

Tot uur 24. Vroegtijdige waarschuwing indienen. Ze heet vroegtijdige waarschuwing en geen analyse, en ze mag open punten bevatten.

Wat je voor de vroegtijdige waarschuwing nodig hebt

• Productnaam, betrokken versies, gegevens van de aanbieder.
• Moment en bron van je kennis.
• Korte beschrijving van wat er is gebeurd en waaruit je misbruik afleidt.
• Eerste inschatting van het effect en van de verspreiding van de betrokken versies.
• De lidstaten waar het product beschikbaar is. Bij een plugin in de open directory is dat de hele Unie.
• Wat er al loopt, en wanneer je een oplossing verwacht.

Wat in je eigen logboek hoort

Het logboek is de minst spannende en nuttigste helft van het werk. Het beantwoordt later de vraag of je de termijnen hebt gehaald. Een tekstbestand in de repository volstaat, zolang iemand het bijhoudt.

• Moment en bron van de kennis.
• De beslissing over het spoor, met twee zinnen onderbouwing.
• Moment van de vroegtijdige waarschuwing, van de melding van 72 uur en van het eindverslag, telkens met ontvanger.
• Moment vanaf wanneer een oplossing beschikbaar was. Vanaf dat punt tel je de 14 dagen in het kwetsbaarheidsspoor.
• De versie van de klantinformatie zoals ze de deur uit is gegaan, en wanneer.
• Betrokken versies en de versie die de fix bevat.

Hoe de klantinformatie eruitziet

Kort, zakelijk, zonder sussen. Betrokken versies noemen, zeggen wat een gebruiker nu moet doen, zeggen vanaf welke versie het probleem verholpen is. Is er een tussenmaatregel, dan staat die bovenaan. Bij een WordPress-plugin is de plek daarvoor de readme met de changelog-regel en de update zelf, plus de beveiligingspagina en, als je een klantenlijst hebt, een mail. Het machineleesbare deel uit artikel 14, lid 8, is bij een plugin in de praktijk de versievermelding in het updatekanaal.

Wat vooraf moet staan, zodat je bij ernst niet zoekt

• Een gepubliceerd beveiligingscontact, het liefst een eigen postbus en niet het supportforum.
• Een /.well-known/security.txt volgens RFC 9116, zodat melders de weg vinden zonder te gokken.
• Een beleid voor gecoördineerde openbaarmaking: wat je toezegt, wat je vraagt, welke reikwijdte geldt.
• Een manier om alle betrokken gebruikers te bereiken. Bij gratis directory-plugins is dat het updatekanaal met de readme, bij verkochte producten de klantenlijst.
• Een vaste plek voor het logboek, aangemaakt voordat je hem nodig hebt.

Een weekend kost dat niet. Midden in een incident kost het te lang. Welk gereedschap helpt om je installaties in de gaten te houden, is stof voor een andere vergelijking van beveiligingsplugins.

Waar we zelf staan

Omdat een gids die alleen eist weinig waard is: bij ons is er een beveiligingspagina met gepubliceerd beveiligingscontact, toegezegde reactietijden, reikwijdte en het beleid voor gecoördineerde openbaarmaking, plus een /.well-known/security.txt volgens RFC 9116 die naar die pagina verwijst. Daarachter staat de eigen verklaring met de fabrikantgegevens, zo geschreven dat een melder niet hoeft te vragen waar hij binnenkomt.

Wat bij ons nog niet staat, hoort hier net zo goed. Van onze gratis plugins in de WordPress-directory, bijvoorbeeld Wellenbrecher, kennen we de installaties niet. Onze weg naar die gebruikers is het updatekanaal en de readme, meer niet. Registratie op het meldplatform is tot nu toe niet mogelijk, voorbereiden laat zich alleen het EU Login-account. En ons incidentlogboek ligt intern, het is geen openbare pagina.

Veelgestelde vragen