Ontwikkel of lever je software, hardware of een ander digitaal product? Dan kan 11 september 2026 een belangrijke datum zijn.
Vanaf die dag gelden de meldverplichtingen uit artikel 14 van de Cyber Resilience Act, de CRA. Dat betekent niet dat ieder beveiligingsprobleem voortaan moet worden gemeld. De verplichting richt zich specifiek op fabrikanten van producten met digitale elementen en op twee situaties: actief uitgebuite kwetsbaarheden en ernstige incidenten die gevolgen hebben voor de beveiliging van zo’n product.
De eerste vraag is daarom niet hoe je een CRA-melding doet.
De eerste vraag is: valt jouw product onder de CRA en ben jij daarvoor de fabrikant?
Vanaf 11 september geldt de CRA nog niet volledig
De Cyber Resilience Act trad op 10 december 2024 in werking. De belangrijkste verplichtingen voor producten en fabrikanten worden vanaf 11 december 2027 van toepassing. De meldverplichtingen uit artikel 14 gelden echter al vanaf 11 september 2026.
11 september is dus geen algemene deadline waarop je de volledige CRA geïmplementeerd moet hebben. Het is vooral de datum waarop je in staat moet zijn een meldplichtige kwetsbaarheid of incident tijdig te herkennen en te melden.
Valt jouw product onder de CRA?
De CRA gaat over producten met digitale elementen die op de Europese markt worden aangeboden en waarvan het bedoelde of redelijkerwijs voorzienbare gebruik een directe of indirecte verbinding met een apparaat of netwerk omvat.
Dat kunnen zowel hardware- als softwareproducten zijn. Voor een softwarebedrijf kan bijvoorbeeld een applicatie of afzonderlijk aangeboden softwarecomponent binnen de CRA vallen.
Ook verwerking op afstand kan onderdeel zijn van zo’n product. Dat geldt wanneer de software daarvoor door of onder verantwoordelijkheid van de fabrikant is ontwikkeld en het product zonder die verwerking een functie niet kan uitvoeren. Een API of backend die noodzakelijk is voor de werking van een product kan daar bijvoorbeeld onder vallen.
En hoe zit het met SaaS?
Het label SaaS geeft op zichzelf geen antwoord op de vraag of de CRA van toepassing is.
De CRA maakt onderscheid tussen noodzakelijke verwerking op afstand die onderdeel is van een product en zelfstandige cloudservices. SaaS, PaaS en IaaS vallen dus niet alleen vanwege hun servicemodel binnen de CRA. Bij een combinatie van software, cloudverwerking en aanvullende dienstverlening moet je kijken naar wat er daadwerkelijk als product op de markt wordt gebracht en welke online functionaliteit daarvan noodzakelijk onderdeel is.
De relevante vraag is daarom niet simpelweg:
Wij leveren software, vallen we onder de CRA?
Maar:
Wat brengen wij precies op de Europese markt en welke rol hebben wij daarbij?
Ben jij volgens de CRA de fabrikant?
Je hoeft geen fysieke apparatuur te produceren om onder de CRA fabrikant te zijn.
Ook een organisatie die software ontwikkelt of laat ontwikkelen en die vervolgens onder de eigen naam of het eigen merk op de markt brengt, kan fabrikant zijn. Ook importeurs en distributeurs kunnen in bepaalde situaties fabrikant worden, bijvoorbeeld wanneer zij een product onder hun eigen naam aanbieden of het substantieel wijzigen.
Voor een eerste beoordeling zijn vier vragen vooral relevant:
- Bied je een software- of hardwareproduct met digitale elementen aan op de Europese markt?
Zo nee, dan liggen directe CRA-productverplichtingen minder voor de hand. - Ontwikkel je het product zelf, laat je het ontwikkelen of breng je het onder je eigen naam of merk uit?
Zo ja, onderzoek dan je positie als fabrikant. - Geldt voor het product een specifieke uitzondering of andere Europese sectorale regeling?
Voor sommige productcategorieën gelden afzonderlijke regimes waardoor de CRA geheel of gedeeltelijk buiten toepassing kan blijven. - Ben je fabrikant van een product dat binnen de CRA valt?
Dan zijn de meldverplichtingen vanaf 11 september direct relevant.
Wat moet je vanaf 11 september melden?
Hier zit een belangrijk onderscheid: niet iedere kwetsbaarheid en niet ieder securityincident is een CRA-melding.
Actief uitgebuite kwetsbaarheden
Artikel 14 richt zich op kwetsbaarheden waarvoor betrouwbaar bewijs bestaat dat een kwaadwillende partij deze daadwerkelijk zonder toestemming in een systeem heeft misbruikt.
Stel dat een pentest een kwetsbaarheid in je applicatie ontdekt. Die bevinding moet uiteraard worden onderzocht en opgelost, maar is daardoor nog niet automatisch meldplichtig onder artikel 14.
Krijg je betrouwbaar bewijs dat aanvallers dezelfde kwetsbaarheid daadwerkelijk misbruiken, dan verandert de situatie.
Ernstige incidenten rond het product
Ook een securityincident binnen je organisatie is niet automatisch een CRA-incident.
De meldplicht ziet op ernstige incidenten die gevolgen hebben voor de beveiliging van een product met digitale elementen. Denk bijvoorbeeld aan een situatie waarin een compromise ertoe leidt of kan leiden dat kwaadaardige code in het product of in systemen van gebruikers wordt uitgevoerd.
Ook de oorzaak hoeft niet uitsluitend in het eindproduct zelf te zitten. Een compromise van een ontwikkel-, onderhouds- of updateproces kan eveneens relevant zijn wanneer daardoor de beveiliging van het product of zijn gebruikers wordt geraakt.
Een phishingmail aan een medewerker is daarom niet automatisch een CRA-melding. Een gecompromitteerd software-updateproces waarmee schadelijke code bij klanten terecht kan komen, kan dat wel zijn.
Ook bestaande producten kunnen al geraakt worden
Een belangrijke overgangsbepaling wordt gemakkelijk gemist.
Voor veel algemene CRA-verplichtingen geldt een overgang naar 11 december 2027. Dat betekent echter niet dat bestaande producten tot die datum buiten artikel 14 vallen.
De CRA bepaalt expliciet dat de meldverplichtingen ook gelden voor producten die al vóór 11 december 2027 op de markt zijn gebracht, zolang zij binnen de reikwijdte van de verordening vallen.
De redenering ons product bestaat al jaren, dus de CRA raakt ons voorlopig niet kan daardoor verkeerd uitpakken.
Voor bestaande software kan 11 september 2026 juist de eerste concrete CRA-deadline zijn.
Hoe snel moet je melden?
Zodra je als fabrikant kennis krijgt van een meldplichtige gebeurtenis, gaan korte termijnen lopen.
| Moment | Actief uitgebuite kwetsbaarheid | Ernstig incident |
| Binnen 24 uur | Eerste waarschuwing | Eerste waarschuwing |
| Binnen 72 uur | Nadere kwetsbaarheidsmelding | Nadere incidentmelding |
| Definitieve rapportage | Uiterlijk 14 dagen nadat een corrigerende of mitigerende maatregel beschikbaar is. | Binnen één maand na de incidentmelding uit de 72 uursfase |
De wettelijke termijnen worden gekoppeld aan het moment waarop de fabrikant kennis krijgt van de actief uitgebuite kwetsbaarheid of het ernstige incident.
De eerste melding hoeft dus geen volledig afgerond forensisch onderzoek te bevatten. Het proces is bewust opgebouwd uit verschillende fasen waarin steeds meer informatie beschikbaar kan komen.
Dat maakt één punt bijzonder belangrijk:
je hoeft binnen 24 uur niet alles te weten, maar je moet wel tijdig herkennen dat de meldplicht is gaan lopen.
Voor Nederlandse fabrikanten vindt de melding vanaf 11 september plaats bij het NCSC via mijn.NCSC.nl. De CRA schrijft voor dat meldingen via het Europese Single Reporting Platform worden ingediend bij het coördinerende CSIRT en tegelijkertijd toegankelijk zijn voor ENISA.
CRA en Cyberbeveiligingswet zijn niet hetzelfde
De nieuwe meldplicht volgt kort na de inwerkingtreding van de Cyberbeveiligingswet op 15 augustus 2026. Toch kijken beide regelingen vanuit een ander perspectief.
De Cyberbeveiligingswet, de Nederlandse implementatie van NIS2, richt zich op de digitale weerbaarheid van organisaties en diensten. De CRA richt zich op de cybersecurity van producten met digitale elementen.
Een gebeurtenis kan daardoor vanuit meerdere regelingen relevant zijn, maar de reden waarom je moet beoordelen of melden verschilt.
Wil je bepalen of jouw organisatie rechtstreeks door NIS2 wordt geraakt? Lees dan ook Cyberbeveiligingswet uitgelegd: val je er vanaf 15 augustus onder?.
Je moet mogelijk ook je gebruikers informeren
De verplichting houdt niet op bij een melding aan de autoriteiten.
Na kennisneming van een actief uitgebuite kwetsbaarheid of ernstig incident moet de fabrikant getroffen gebruikers informeren en, waar passend, alle gebruikers. Wanneer dat nodig is, moet daarbij ook duidelijk worden gemaakt welke maatregelen gebruikers zelf kunnen nemen om de gevolgen te beperken.
Je moet daarom niet alleen weten wie de formele melding uitvoert. Je moet ook kunnen bepalen welke gebruikers geraakt zijn, welke correctieve maatregelen beschikbaar zijn en wie verantwoordelijk is voor de communicatie.
Dat wil je tijdens een incident niet meer hoeven organiseren.
Wat moet je vóór 11 september geregeld hebben?
Je hoeft vóór september niet de hele CRA-implementatie voor 2027 af te ronden. De voorbereiding kan veel gerichter.
Weet welke producten binnen je scope vallen
Maak geen inventarisatie van alle IT binnen je organisatie. Kijk specifiek naar de producten die je ontwikkelt, laat ontwikkelen of onder eigen naam op de markt brengt.
Leg bij twijfel vast waarom je denkt dat een product wel of niet binnen de CRA valt en onderzoek de onduidelijke gevallen verder.
Weet wie de fabrikant is
Bij volledig eigen software is dit vaak duidelijk. Bij white-labelproducten, gezamenlijke ontwikkeling, reselling en integraties kan de rolverdeling minder vanzelfsprekend zijn.
Zorg dat je niet pas tijdens een incident moet vaststellen welke partij verantwoordelijk is.
Zorg voor een herkenbaar ingangspunt
Een klant, securityonderzoeker, leverancier of medewerker kan het eerste signaal van een kwetsbaarheid geven.
Dan moet duidelijk zijn waar dat signaal terechtkomt. Een mogelijk actief uitgebuite kwetsbaarheid die enkele dagen in een algemene mailbox blijft staan, is moeilijk te verenigen met een meldtermijn van 24 uur.
Maak classificatie expliciet
Je proces moet snel antwoord kunnen geven op vier vragen: heeft dit betrekking op een CRA-product, is er betrouwbaar bewijs van actieve exploitatie, is sprake van een ernstig incident en wanneer kregen we hiervan kennis?
Dat laatste moment is belangrijk omdat daaraan de meldtermijnen zijn gekoppeld.
Leg eigenaarschap vast
Je hebt hiervoor geen uitgebreide nieuwe complianceorganisatie nodig.
Wel moet duidelijk zijn wie een mogelijke meldplicht beoordeelt, wie besluit dat wordt gemeld, wie de melding uitvoert en wie de opvolging bewaakt.
Bij een termijn van 24 uur is duidelijk eigenaarschap waardevoller dan een uitgebreid beleidsdocument.
Wat volgt op 11 december 2027?
De meldplicht is slechts één onderdeel van de Cyber Resilience Act.
Vanaf 11 december 2027 gaan de belangrijkste overige CRA-verplichtingen gelden. Fabrikanten krijgen dan onder meer te maken met eisen rond cybersecurity gedurende ontwerp en ontwikkeling, cybersecurityrisicobeoordeling, vulnerability handling, technische documentatie, informatie voor gebruikers, conformiteitsbeoordeling en CE-markering.
Het onderscheid tussen beide data is daarom eenvoudig:
11 september 2026: zorg dat je meldplichtige situaties kunt herkennen en binnen de wettelijke termijnen kunt handelen.
11 december 2027: zorg dat je product en de bijbehorende ontwikkel- en beheerprocessen aan de bredere CRA-eisen voldoen.
Zo voorkom je dat je nu een volledig implementatieproject probeert af te ronden, maar ook dat je een verplichting mist die al ruim een jaar eerder ingaat.
Begin bij toepasselijkheid, niet bij het meldformulier
Vanaf 11 september hoef je niet ieder beveiligingsprobleem te melden.
Maar ben je fabrikant van een product met digitale elementen, dan moet je wel snel kunnen herkennen wanneer een kwetsbaarheid actief wordt uitgebuit of een ernstig beveiligingsincident onder artikel 14 valt.
Daarvoor heb je vooral drie dingen nodig: duidelijkheid over je producten, een werkbare classificatie en expliciet eigenaarschap.
De meldplicht vraagt daarmee niet automatisch om een zwaar nieuw complianceproces. Wel moet de structuur vóór een incident duidelijk zijn. Anders verlies je kostbare tijd aan vragen die je vooraf al had kunnen beantwoorden: wie is verantwoordelijk, wanneer is de meldtermijn begonnen en welke acties zijn al genomen?
CompliTrack helpt om risico’s, incidenten, verantwoordelijkheden en vervolgacties centraal vast te leggen. Zo blijft opvolging niet afhankelijk van losse spreadsheets, documenten en mailboxen.
Bekijk hoe CompliTrack helpt om incidenten en compliance-acties beheersbaar te organiseren.
