De CRA-meldtermijn van 11 september: wat je moet melden, wanneer en waar
| Interlynk
De eerste bindende vereiste onder de EU Cyber Resilience Act wordt van kracht op 11 september 2026. Hier staat op wie die van toepassing is, wat bedrijven moeten melden en hoe het meldproces werkt.
Overzicht
Het grootste deel van de Cyber Resilience Act geldt pas vanaf 11 december 2027. Eén belangrijke vereiste komt veel eerder.
Vanaf 11 september 2026 moeten fabrikanten van producten met digitale elementen actief uitgebuite kwetsbaarheden en ernstige incidenten binnen uren melden aan EU-autoriteiten.
Dit is de eerste vaste termijn van de CRA, en die dekt producten die al op de markt zijn, niet alleen producten die na de termijn worden gelanceerd. Deze gids legt uit wie het betreft, wat een melding in gang zet, hoe snel een bedrijf moet handelen, waar de melding naartoe gaat en de twee verwante verplichtingen die makkelijk over het hoofd worden gezien.
CRA-melding in het kort
Vanaf 11 september 2026 vereist artikel 14 dat fabrikanten een actief uitgebuite kwetsbaarheid of een ernstig incident in een product binnen het toepassingsgebied melden aan het coördinerende nationale CSIRT en aan ENISA, via één platform. Het proces heeft drie fasen: een eerste waarschuwing binnen 24 uur, een vollediger melding binnen 72 uur en een eindrapport binnen 14 dagen nadat een corrigerende maatregel beschikbaar komt. Bij een ernstig incident is het eindrapport verschuldigd binnen één maand na de incidentmelding. De vereiste geldt voor producten die al op de EU-markt zijn aangeboden. Boetes bij niet-naleving kunnen oplopen tot 15 miljoen euro of 2,5 procent van de wereldwijde jaaromzet.
Juridische grondslag: artikel 14 en de termijn van 11 september
De CRA staat formeel bekend als Verordening (EU) 2024/2847 [1]. Die is in december 2024 in werking getreden en geldt volledig vanaf 11 december 2027. De meldplicht begint eerder, op 11 september 2026, onder artikel 14. Dat geeft toezichthouders vroeg zicht op uitgebuite zwakheden in digitale producten voordat de rest van het kader van kracht wordt.
Dat onderscheid is belangrijk omdat het vaak verkeerd wordt begrepen. Artikel 14 creëert een op zichzelf staande, tijdgevoelige meldplicht. De bredere eisen voor kwetsbaarheidsbeheer in bijlage I, samen met conformiteitsbeoordeling, technische documentatie en CE-markering, staan in artikel 13 en gelden doorgaans vanaf december 2027. Een fabrikant hoeft niet bijna volledig CRA-compliant te zijn om onder artikel 14 te vallen. Als de meldplicht geldt, begint de termijn in september 2026, ongeacht hoe ver de rest van het complianceprogramma gevorderd is.
Wie het betreft
De verplichting geldt voor fabrikanten van producten met digitale elementen. Dat is een brede categorie. Die omvat software, hardware, oplossingen voor gegevensverwerking op afstand, en software- of hardwarecomponenten die apart op de markt worden aangeboden. De CRA geldt sectoroverstijgend voor producten die in de EU worden aangeboden, al vallen sommige productcategorieën onder andere EU-regels en zijn ze uitgezonderd.
Twee details kunnen een bedrijf eerder dan verwacht onder de regel brengen.
Producten die al op de markt zijn tellen mee. Onder artikel 69(3) dekt de meldplicht producten binnen het toepassingsgebied die al vóór de termijn op de EU-markt waren. Die is niet beperkt tot producten die na 11 september 2026 in de handel worden gebracht. Als een product dat enkele jaren geleden is uitgeleverd nog in de EU wordt verkocht of geleverd, kan het nog steeds binnen de reikwijdte van artikel 14 vallen. Bedrijven hebben betrouwbare gegevens nodig die laten zien wat ze hebben uitgeleverd, welke versies erbij betrokken zijn en waar die producten zijn aangeboden.
Fabrikanten buiten de EU zijn niet automatisch uitgezonderd. Als een bedrijf buiten de EU producten aan de Europese markt verkoopt, kan de verplichting het bereiken via zijn gemachtigde, importeur of distributeur. Verkopen van buiten de EU neemt de meldverantwoordelijkheid op zichzelf niet weg.
Wat gemeld moet worden
Artikel 14 richt zich op twee specifieke situaties. Het vereist geen melding voor elke CVE of elk beveiligingsprobleem.
Een actief uitgebuite kwetsbaarheid. Dit betekent een kwetsbaarheid in het product die een kwaadwillende heeft ontdekt en in de echte wereld uitbuit. De trigger is bewijs van werkelijke uitbuiting, niet slechts een theoretische mogelijkheid. Een hoge CVSS-score, een openbaar beschikbare proof of concept of een gewone kwetsbaarheidsmelding zet de meldtermijn niet automatisch in gang. Het bewijs moet erop wijzen dat de kwetsbaarheid in het product wordt uitgebuit.
Een ernstig incident. Dit is een beveiligingsincident dat een significant effect heeft, of kan hebben, op de beveiliging van het product of de gebruikers ervan.
De guidance van de Europese Commissie van 27 juli 2026 voegt twee nuttige punten toe [3].
Ten eerste heeft de uitdrukking "op de hoogte raken" een specifieke betekenis. De termijn begint nadat een eerste beoordeling de fabrikant met redelijke zekerheid oplevert dat een kwetsbaarheid in zijn product actief wordt uitgebuit of dat een ernstig incident heeft plaatsgevonden. Een gerucht of een ongeverifieerde tip zet de termijn niet automatisch in gang op het moment dat die binnenkomt.
Ten tweede hangen kwetsbaarheden van derden af van de vraag of de betrokken code bereikbaar is en in het product wordt uitgebuit. Als een actief uitgebuite kwetsbaarheid afkomstig is uit een component die je hebt geïntegreerd, is een melding onder artikel 14 vereist wanneer die kwetsbaarheid actief wordt uitgebuit in je product. Is de betrokken code niet bereikbaar of wordt die in je product niet uitgebuit, dan is op die grond geen melding onder artikel 14 vereist, ook al kunnen andere upstream- en kwetsbaarheidsbeheerverplichtingen blijven gelden. Deze bepaling snel maken vereist een nauwkeurige componenteninventaris en een manier om vast te stellen of de betrokken code bereikbaar is.
Het meldproces
Artikel 14 legt een meldproces in drie stappen vast. De eerste twee stappen zijn gelijk voor een actief uitgebuite kwetsbaarheid en een ernstig incident. De timing van het eindrapport verschilt.
Fase | Termijn | Inhoud |
|---|---|---|
Vroegtijdige waarschuwing | Binnen 24 uur na op de hoogte raken | Melding dat er een actief uitgebuite kwetsbaarheid of ernstig incident is |
Volledige melding | Binnen 72 uur na op de hoogte raken | Een uitgebreidere technische beoordeling, inclusief genomen corrigerende of mitigerende maatregelen |
Eindrapport | Binnen 14 dagen nadat een corrigerende maatregel beschikbaar komt voor een kwetsbaarheid, of binnen één maand voor een ernstig incident | Details van de kwetsbaarheid of het incident, betrokken kwaadwillenden en de stappen die worden genomen om het te corrigeren |
De termijn voor het eindrapport van een kwetsbaarheid wordt makkelijk verkeerd gelezen. De 14-dagenperiode begint wanneer een corrigerende of mitigerende maatregel beschikbaar komt. Die begint niet wanneer de fabrikant voor het eerst op de hoogte raakt van de kwetsbaarheid. Bij een ernstig incident is het eindrapport verschuldigd binnen één maand na de 72 incidentmelding. Dit zijn korte vensters, dus het meldproces moet klaar zijn voordat een incident zich voordoet. Er zal niet genoeg tijd zijn om het tijdens een lopende respons vanaf nul op te zetten.
Waar en hoe je meldt
Meldingen worden ingediend via het CRA Single Reporting Platform, of SRP. ENISA moet het platform onder artikel 16 opzetten en vóór 11 september 2026 operationeel hebben [2]. Een testperiode wordt vooraf verwacht.
Het proces is ontworpen rond één indiening. De fabrikant meldt aan het coördinerende CSIRT, dat is het CSIRT dat hoort bij de hoofdvestiging van de fabrikant in de EU. De melding wordt ook via het platform beschikbaar gesteld aan ENISA. Voor vervolgmeldingen kan de fabrikant via hetzelfde coördinerende CSIRT blijven werken. Het is niet nodig aparte meldingen naar elke EU-lidstaat te sturen.
Omdat het platform wordt uitgerold terwijl de termijn nadert, moeten bedrijven de actuele SRP-pagina van ENISA en de CRA-meldpagina van de Europese Commissie raadplegen voor de nieuwste registratie- en indieningsinstructies. Vertrouw niet op een oudere beschrijving van hoe het platform werkt.
De verplichtingen die teams missen
Melden aan autoriteiten is maar een deel van de respons. Twee aanvullende verplichtingen worden makkelijk over het hoofd gezien.
Informeer de componentfabrikant of maintainer. Als een actief uitgebuite kwetsbaarheid in je product afkomstig is uit een component van derden, moet je de fabrikant of maintainer van die component informeren. In producten die uit veel bibliotheken en modules zijn opgebouwd, wordt je componenteninventaris daardoor niet alleen een register van wat er in het product zit, maar ook een operationele contactlijst.
Informeer gebruikers. Zodra je op de hoogte raakt van een actief uitgebuite kwetsbaarheid of een ernstig incident, moet je de getroffen gebruikers, en waar passend alle gebruikers, informeren over het probleem en de corrigerende maatregelen die ze kunnen nemen. De melding moet zonder onnodige vertraging gebeuren. Informeert de fabrikant de gebruikers niet, dan kan het CSIRT dat rechtstreeks doen.
Beide verplichtingen hangen af van dezelfde basisvaardigheid als de melding aan autoriteiten: weten wat er in elk product zit, welke versies getroffen zijn en wie er gecontacteerd moet worden.
Praktische stappen vóór 11 september
De meldvereiste is smal, maar de reactietijd is niet vergevingsgezind. Vóór 11 september zou een bedrijf één vraag snel moeten kunnen beantwoorden: als een kwetsbaarheid wordt uitgebuit, welke van onze producten en versies bevatten die, en wie moet worden ingelicht?
Bepaal je toepassingsgebied. Maak een lijst van de producten met digitale elementen die je op de EU-markt hebt aangeboden, inclusief oudere producten die nog in gebruik zijn of nog worden verkocht. Bestaande producten kunnen binnen het toepassingsgebied vallen.
Houd een actuele SBOM per product bij. De termijnen van 24 en 72 uur zijn moeilijk te halen als je je componenten niet kunt identificeren en aan de uitgebuite kwetsbaarheid kunt koppelen. Een actuele SBOM kan het verschil maken tussen een respons op dezelfde dag en een gehaast handmatig onderzoek.
Koppel exploit-monitoring aan je inventaris. Actieve uitbuiting verschilt van theoretisch risico, en alleen actieve uitbuiting zet deze meldtermijn in gang. Threat intelligence zou moeten aansluiten op je componenteninventaris, zodat een geloofwaardig signaal snel aan getroffen producten kan worden gekoppeld.
Bereid de meldpaden voor. Maak sjablonen voor de melding aan autoriteiten, de melding aan de upstream-componentfabrikant of maintainer en de gebruikersmelding. Het schrijven zou niet moeten beginnen met een al lopende 24-uurstermijn.
Wijs duidelijk eigenaarschap toe. Beslis wie vaststelt dat het bedrijf op de hoogte is van een meldplichtige gebeurtenis, wie de SRP-melding indient en wie de gebruikers contacteert. De verordening gaat ervan uit dat deze verantwoordelijkheden zijn toegewezen.
De eisen voor kwetsbaarheidsbeheer in bijlage I worden pas in december 2027 bindend, dus een volledig CRA-kwetsbaarheidsbeheerprogramma is niet vereist tegen september 2026. Wat wel vereist is, is het vermogen om uitbuiting te identificeren, de getroffen producten via hun componenten te vinden en binnen de vereiste termijnen te melden.
De conclusie
11 september 2026 wordt de eerste echte test van de CRA, en die komt ruim een jaar voordat de verordening volledig geldt. De meldvereiste is beperkt tot actief uitgebuite kwetsbaarheden en ernstige incidenten, maar de reactietijden zijn veeleisend.
De praktische uitdaging komt neer op zichtbaarheid. Bedrijven moeten weten wat er in hun producten zit, over elke versie die nog op de markt is, en ze moeten blootstellingsvragen in uren in plaats van dagen beantwoorden. Teams die hun SBOMs als levende operationele data behandelen, staan veel sterker om op tijd te melden. Teams die een SBOM behandelen als een eenmalig gemaakt en gearchiveerd document, reconstrueren hun inventaris mogelijk nog terwijl de klok loopt.
Voor de eisen die komen wanneer de CRA volledig geldt, inclusief de SBOM-velden uit BSI TR-03183, zie onze gids over SBOM-vereisten voor de CRA.
Interlynk helpt fabrikanten om audit-klare SBOMs bij elke build bij te houden, kwetsbaarheden gedurende de hele productlevenscyclus te bewaken en vragen zoals "welke producten en versies bevatten deze component" in minuten te beantwoorden. Genereer SBOMs in CycloneDX of SPDX, houd ze actueel en wees klaar om binnen de termijn van de CRA te reageren. Lees meer over onze oplossing voor de Cyber Resilience Act. Vertrouwd door security- en complianceteams bij meer dan 100 gereguleerde bedrijven.
Plan een demo · Gratis starten
Deze gids geeft de CRA-tekst, Verordening (EU) 2024/2847, en de niet-bindende toepassingsguidance van de Europese Commissie van 27 juli 2026 weer. Die is op het moment van publicatie op juistheid gecontroleerd. Platformwerking en officiële guidance kunnen vóór de termijn veranderen. Bevestig actuele details op de Single-Reporting-Platform-pagina van ENISA en de CRA-meldpagina van de Europese Commissie, en raadpleeg je eigen juridisch adviseur. Dit artikel is uitsluitend informatief en vormt geen juridisch advies.
Referenties
Verordening (EU) 2024/2847, de Cyber Resilience Act (EUR-Lex): https://eur-lex.europa.eu/eli/reg/2024/2847/oj
ENISA, Single Reporting Platform (SRP): https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp
Europese Commissie, Cyber Resilience Act, meldplichten: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting