Sinds 11 september 2026 moeten CRA-fabrikanten actief misbruikte kwetsbaarheden en ernstige incidenten melden via het ENISA Single Reporting Platform. Deze gids legt uit wat een melding activeert, hoe de termijnen van 24 uur, 72 uur, 14 dagen en 1 maand werken, en waar CVD, VEX en gebruikersinformatie in het proces passen.
Samenvatting
- Urgente melding geldt sinds 11 september 2026: beide stromen gebruiken een 24u-waarschuwing en een 72u-melding; het eindrapport komt 14 dagen nadat een corrigerende of risicobeperkende maatregel beschikbaar is voor kwetsbaarheden en binnen 1 maand na de 72u-melding voor ernstige incidenten.
- Dien een keer in via ENISA SRP: het platform stuurt de melding naar de coördinerende CSIRT en maakt die beschikbaar voor ENISA.
- Actief misbruik vereist betrouwbaar bewijs dat een kwaadwillende actor de kwetsbaarheid zonder toestemming in een systeem heeft misbruikt; openbaarmaking, een publieke PoC of een onderzoeksdemo is op zichzelf niet genoeg.
- Het CVD-beleid is verplicht: schriftelijk, gepubliceerd, toegepast en gekoppeld aan de meldpoort wanneer triage actief misbruik vindt.
- VEX ondersteunt meldbesluiten door vast te leggen of een CVE in een SBOM-component het product werkelijk raakt.
- Boetedetails horen in de handhavingsgids: te late of ontbrekende meldingen kunnen serieuze handhavingsblootstelling opleveren; zie CRA-boetes en handhaving voor niveaus en mkb-uitzonderingen.
De vier getallen die CRA-melding van kwetsbaarheden en incidenten sturen: waarschuwing, melding, eindrapport en sanctieniveau.
Wat moet worden gemeld
CRA-melding heeft twee verplichte gebeurtenisstromen en een afzonderlijke plicht om gebruikers te informeren. De plicht ligt bij de fabrikant van het product met digitale elementen op de EU-markt:
- Meld elke actief misbruikte kwetsbaarheid in het product aan de coördinerende CSIRT en ENISA volgens 24u / 72u / 14d.
- Meld elk ernstig incident dat gevolgen heeft voor de beveiliging van het product volgens 24u / 72u / 1 maand.
- Informeer getroffen gebruikers over de kwetsbaarheid of het incident en corrigerende maatregelen zonder onnodige vertraging.
Deze pagina behandelt ook twee aangrenzende controles die de meldbeslissing voeden: het verplichte CVD-beleid en toepasbaarheidsbewijs zoals VEX. Geen van deze plichten heeft een omvangsdrempel. Micro- en kleine ondernemingen krijgen alleen een smalle boetevrijstelling voor de 24h-vroege waarschuwing; zij zijn niet vrijgesteld van melden.
Het ENISA Single Reporting Platform (SRP)
SRP is het enige kanaal voor verplichte CRA-meldingen over kwetsbaarheden en incidenten. De fabrikant meldt een keer via het elektronische punt van de coördinerende CSIRT; de melding is tegelijk beschikbaar voor ENISA tenzij het uitzonderlijke mechanisme voor vertraagde verspreiding wordt toegepast. De coördinerende CSIRT verspreidt de informatie daarna naar betrokken CSIRT's in andere lidstaten.
Die uitstelregel laat de coördinerende CSIRT de verdere verspreiding uitstellen in uitzonderlijke omstandigheden, op gerechtvaardigde cyberbeveiligingsgronden en zolang dat strikt noodzakelijk is. U kunt erom vragen en u kunt aangeven hoe gevoelig de informatie is, maar het besluit ligt bij de CSIRT en niet bij u. Er is een tweede, aparte vertraging voor een kwetsbaarheid waarvan de coördinerende CSIRT via een gecoördineerde openbaarmakingsprocedure kennis heeft gekregen. Daar kan de CSIRT de melding tegenhouden op gerechtvaardigde cyberbeveiligingsgronden, niet langer dan strikt noodzakelijk is en tot de partijen bij die openbaarmaking instemmen met bekendmaking. Dat is het weten waard als u een CVD-traject draait, maar ook hier ligt het besluit bij de CSIRT, dus reken er niet op dat een embargo standhoudt.
Bijzondere uitzonderlijke omstandigheden, kortweg PEC, is een smaller en apart mechanisme. Het geldt alleen voor de 72-uurskennisgeving over een actief misbruikte kwetsbaarheid, en alleen wanneer het misbruik beperkt blijft tot de lidstaat van uw coördinator, wanneer bredere openbaarmaking ingaat tegen de wezenlijke belangen van die staat, of wanneer de verspreiding zelf een onmiddellijk hoog cyberbeveiligingsrisico oplevert. U zet er in het platform een schakelaar voor om en kunt een onderbouwing meegeven; de coördinerende CSIRT beslist. Zolang het geldt, krijgt ENISA nog steeds een beperkte set: dat er een melding is gedaan, algemene productinformatie, de algemene aard van het misbruik en het gegeven dat beveiligingsgronden zijn ingeroepen. De volledige melding volgt zodra de vertraging afloopt. Het PEC-richtsnoer van ENISA beschrijft de procedure.
Status, 11 september 2026: het SRP is beschikbaar op portal.cra-srp.enisa.europa.eu. U kiest op de startpagina de rol Assigned Representative en logt in met een persoonlijk EU Login-account met multifactorauthenticatie. Dat account meldt namens een fabrikant of een opensourcesoftwaresteward en is niet hetzelfde als een gemachtigde vertegenwoordiger onder de CRA. ENISA werkte de FAQ en de registratiegids voor de Assigned Representative bij op 10 september 2026, en de gids over de platforminterface en de gids over het indienen en bijwerken van meldingen op 9 september 2026. Op 9 september 2026 verscheen ook een AR User Manual van 55 pagina's, de weg scherm voor scherm door de registratie, de drie meldingsfasen en het bijwerken van een melding. De SRP Glossary is versie 1.3 en geeft de veld-voor-veldreferentie, alleen in het Engels. De lijst met CSIRT's die als coördinator zijn aangewezen draagt 10 september 2026. Er is bij de eerste release geen SRP-API; u dient meldingen in via de platforminterface. Vrijwillige melding komt pas in een latere fase. ENISA merkt zijn richtsnoeren aan als huidige kennis die nog kan wijzigen. Maak nu een EU Login-account aan, gebruik de ENISA SRP-onboardinggids en neem zo nodig contact op via cra-srp-helpdesk@enisa.europa.eu.
Meldtermijnen in detail
Meldschema
| Stap | Kwetsbaarheid | Ernstig incident | Startpunt |
|---|---|---|---|
| Eerste waarschuwing | 24 uur | 24 uur | Fabrikant krijgt kennis |
| Gedetailleerde melding | 72 uur | 72 uur | Fabrikant krijgt kennis |
| Eindrapport | 14 dagen nadat een corrigerende of risicobeperkende maatregel beschikbaar is | 1 maand na de 72u-incidentmelding | Verschillende ankers |
| Gebruikersinformatie | Zonder onnodige vertraging | Zonder onnodige vertraging | Gebruikersmelding |
Wat elke indiening bevat
De eerste waarschuwing is een waarschuwing, geen volledige analyse. De 72u-melding geeft algemene informatie over product, exploit of incident, genomen maatregelen, gebruikersacties en gevoeligheid waar relevant. Het eindrapport bevat ten minste de gegevens voor de betreffende stroom: beschrijving van de kwetsbaarheid, ernst, impact en corrigerende maatregelen, of beschrijving van het incident, waarschijnlijke oorzaak en lopende maatregelen.
- Fabrikant krijgt kennis. De 24u-klok start wanneer een snelle eerste beoordeling de fabrikant een redelijke mate van zekerheid geeft dat een kwetsbaarheid in zijn product actief wordt misbruikt.
- +24h. Dien de eerste waarschuwing in via ENISA SRP.
- +72h. Voeg technische details, getroffen versies, misbruikstatus en herstelstatus toe.
- Maatregel beschikbaar. Voor kwetsbaarheden begint de klok voor het eindrapport hier, niet bij ontdekking.
- +14d. Dien de eindgegevens voor de kwetsbaarheids- of incidentstroom in.
Ernstige incidenten volgen dezelfde openingsstappen van 24 uur en 72 uur; het eindrapport is uiterlijk 1 maand na de 72u-melding vereist.
Gegevensvelden in de SRP-meldingssjabloon
De SRP Glossary van ENISA is de veld-voor-veldreferentie voor wat het platform in elke fase vraagt. Versie 1.3 telt 39 velden: 18 die voor beide stromen gelden, 12 die alleen bij een actief misbruikte kwetsbaarheid horen en 9 die alleen bij een ernstig incident horen. De Glossary bestaat alleen in het Engels en ENISA merkt hem aan als huidige kennis die nog kan wijzigen. Codes: X verplicht, O optioneel, C overgenomen van de vorige stap of bijgewerkt, I verplicht als de informatie beschikbaar is, - niet van toepassing in die fase.
| # | Veld | Eerste waarschuwing 24u | 72u | Eindrapport |
|---|---|---|---|---|
| Gemeenschappelijke velden | ||||
| 1 | Meldingstype (kwetsbaarheid of incident) | X | C | C |
| 2 | Titel | X | C | C |
| 3 | Samenvatting | X | C | C |
| 4 | Naam van de fabrikant | X | C | C |
| 5 | Lidstaten waar het product beschikbaar is (betrokken CSIRT) | X | C | C |
| 6 | Productnaam | X | C | C |
| 7 | Productversie | X | C | C |
| 8 | Producttype (standaard / belangrijk / kritiek) | O | C | C |
| 9 | Productklasse | O | C | C |
| 10 | Productcategorie | O | C | C |
| 11 | Indicator einde ondersteuning | O | C | C |
| 12 | Componentnaam | O | C | C |
| 13 | Risicobeperkende maatregel binnenkort verwacht | O | C | C |
| 14 | Gebruikersactie die de impact kan beperken | O | C | C |
| 15 | Overwogen gevoeligheid van informatie | O | O | C |
| 16 | Genomen corrigerende of risicobeperkende maatregelen | O | O | X |
| 17 | Corrigerende of risicobeperkende maatregelen die gebruikers kunnen nemen | O | O | X |
| 18 | Aanvalsvector | - | O | O |
| Actief misbruikte kwetsbaarheid | ||||
| v19 | CVE-ID | O | C | C |
| v20 | EUVD-ID | O | C | C |
| v21 | Algemene informatie | O | X | C |
| v22 | Datum waarop een corrigerende of risicobeperkende maatregel beschikbaar is gekomen | O | O | X |
| v23 | Details over de beschikbare beveiligingsupdate of corrigerende maatregel | O | O | X |
| v24 | Volledige beschrijving van de ernst van de kwetsbaarheid | O | O | X |
| v25 | Volledige beschrijving van de impact van de kwetsbaarheid | O | O | X |
| v26 | Datum en tijdstip waarop u kennis krijgt van de actief misbruikte kwetsbaarheid [1] | X | C | C |
| v27 | Kwaadwillende actor die de kwetsbaarheid heeft uitgebuit of uitbuit | O | O | I |
| v28 | Bijzondere uitzonderlijke omstandigheden (PEC) | - | O | - |
| v29 | Reden voor PEC-vertraging | - | O | - |
| v30 | Nadere informatie | O | O | C |
| Ernstig incident | ||||
| i31 | Incident vermoedelijk veroorzaakt door onrechtmatige of kwaadwillende handelingen | X | C | C |
| i32 | Algemene informatie over de aard van het incident | O | X | C |
| i33 | Toegepaste en lopende risicobeperkende maatregelen | O | O | X |
| i34 | Gedetailleerde beschrijving van de ernst van het incident | O | O | X |
| i35 | Gedetailleerde beschrijving van de impact van het incident | O | O | X |
| i36 | Type dreiging of hoofdoorzaak die het incident waarschijnlijk heeft veroorzaakt | O | O | X |
| i37 | Datum en tijdstip waarop u kennis krijgt van het incident (UTC) [2] | X | X | C |
| i38 | Datum en tijdstip waarop het incident plaatsvond (UTC) | O | X | O |
| i39 | Eerste beoordeling van het incident | O | X | C |
Ernstcriteria (i34): een ernstig incident is een incident dat (1) de mogelijkheid van het product om de beschikbaarheid, authenticiteit, integriteit of vertrouwelijkheid van gevoelige of belangrijke gegevens of functies te beschermen negatief beïnvloedt of kan beïnvloeden, of (2) heeft geleid of kan leiden tot het introduceren of uitvoeren van kwaadaardige code in het product of in de netwerk- en informatiesystemen van een gebruiker.
Bron: SRP Glossary van ENISA, versie 1.3, laatst bijgewerkt op 10 september 2026.
Wat een meldplicht activeert
1. Actief uitgebuite kwetsbaarheden
Een actief misbruikte kwetsbaarheid betekent dat er betrouwbaar bewijs is dat een kwaadwillende actor de kwetsbaarheid zonder toestemming in een systeem heeft misbruikt en dat de fabrikant daarvan kennis heeft gekregen. Een publieke PoC of onderzoeksdemo is op zichzelf niet genoeg.
2. Ernstige incidenten
Een ernstig incident moet worden gemeld wanneer het gevolgen heeft, of kan hebben, voor de bescherming door het product van beschikbaarheid, authenticiteit, integriteit of vertrouwelijkheid van gevoelige of belangrijke gegevens of functies, of wanneer het leidt of kan leiden tot kwaadaardige code in het product of het systeem van de gebruiker.
Meldplichtige en niet-meldplichtige scenario's
| Scenario | Meldplicht? | Waarom |
|---|---|---|
| Privé-rapport van onderzoeker | Nee | Geen bewijs van misbruik; behandel via CVD |
| Publieke PoC | Nee | Publicatie is geen misbruik |
| Klant meldt activiteit die op misbruik lijkt | Beoordelen | Meld als het bewijs betrouwbaar is |
| Misbruik in het wild waargenomen | Ja | Betrouwbaar bewijs van kwaadwillend gebruik |
| SBOM-component met bekende misbruikte CVE | Beoordelen | Alleen als uw product werkelijk geraakt wordt |
| Uw product wordt aangevallen door bij naam genoemde dreigingsactoren | Ja | Rechtstreeks bewijs van misbruik |
| Generieke malware gebruikt een kwetsbaarheidsklasse die uw product heeft | Beoordelen | Alleen als uw specifieke implementatie geraakt wordt |
Kennis en bewijs
De CRA-definitie gebruikt betrouwbaar bewijs om een actief misbruikte kwetsbaarheid vast te stellen. Kennis is een afzonderlijke toets: na een snelle eerste beoordeling moet de fabrikant een redelijke mate van zekerheid hebben dat een kwetsbaarheid in zijn product actief wordt misbruikt. Een afgerond forensisch onderzoek is niet vereist.
CVD-intake en meldpoort
Het CVD-beleid is de intake die externe rapporten omzet in gestructureerde triage. Wijst de triage op actief misbruik, beoordeel dit dan direct. De meldtermijn start wanneer die eerste beoordeling de fabrikant een redelijke mate van zekerheid geeft. Een publieke CVD-pagina en security.txt onder /.well-known/security.txt zijn de praktische manier om het contact vindbaar te maken.
VEX en kwetsbaarheidstoepasbaarheid
VEX (Vulnerability Exploitability eXchange) is een gestructureerde, machineleesbare verklaring over de vraag of een kwetsbaarheid in een SBOM-component een specifiek product werkelijk raakt. Het zet ruwe CVE-treffers om in een verdedigbare, productspecifieke status:
| Status | Betekenis |
|---|---|
not_affected |
De kwetsbaarheid zit in de component, maar raakt dit product niet (het kwetsbare codepad is onbereikbaar, de functie wordt niet aangeroepen, de configuratie beperkt het risico, enzovoort). Een motivering wordt verwacht. |
affected |
De kwetsbaarheid raakt dit product. Er worden een maatregel en een aanbeveling verwacht. |
fixed |
De kwetsbaarheid was aanwezig en is in deze versie verholpen. |
under_investigation |
De status is nog niet bepaald; de beoordeling loopt. |
Voor melden draait het om toepasbaarheid plus actief misbruik. Een kwetsbaarheid met status affected en betrouwbaar bewijs van actief misbruik is precies het soort gebeurtenis dat de 24u-klok voor de eerste waarschuwing start. Een kwetsbaarheid met status not_affected en een deugdelijke motivering onderbouwt een besluit om niet te melden. De CRA noemt VEX niet bij naam, maar VEX is een praktische manier om die motivering te bewaren. Voor VEX-formaten, voorbeelden, motiveringstypen, tooling en SBOM-integratie, zie de VEX-gids.
Verlichting voor kleine fabrikanten
Micro- en kleine ondernemingen (minder dan 50 werknemers en een jaaromzet of balanstotaal tot EUR 10 miljoen; micro: minder dan 10 werknemers, EUR 2 miljoen) zijn alleen vrijgesteld van boetes voor het missen van de eerste 24h-vroege waarschuwing. De verlichting geldt alleen voor die eerste stap.
Blijft verplicht, zonder mkb-verlichting:
- De gedetailleerde 72h-melding.
- Het 14-dagen-eindrapport voor kwetsbaarheden en het 1-maands-eindrapport voor ernstige incidenten.
- Het CVD-beleid.
- Alle overige CRA-productbeveiligingsplichten, inclusief de baseline zonder bekende uitbuitbare kwetsbaarheden.
Middelgrote ondernemingen vallen hier niet onder. Het is een smalle boetevrijstelling, geen lichter meldregime. De volledige structuur staat in CRA-boetes en handhaving.
Veelgemaakte fouten
- Wachten op forensische zekerheid. Een snelle eerste beoordeling en een redelijke mate van zekerheid zijn genoeg; een afgerond forensisch onderzoek is niet vereist.
- CVD en urgente melding verwarren. Het rapport van de onderzoeker is CVD-intake; CRA-melding begint wanneer de eerste beoordeling de fabrikant een redelijke mate van zekerheid over actief misbruik geeft.
- Een enkele escalatiepersoon. De 24u-klok pauzeert niet in het weekend.
- Geen gepubliceerd CVD-beleid. Een intern document is niet genoeg.
- Geen toepasbaarheidsbesluiten. Zonder VEX of equivalent is moeilijk te verdedigen waarom een CVE het product niet raakt.
- SRP als toekomstprobleem behandelen. Templates, piket en CSIRT-relaties zijn nu nodig.
Veelgestelde vragen
Wanneer beginnen de CRA-meldplichten?
Verplichte CRA-melding van kwetsbaarheden en incidenten geldt sinds 11 september 2026. Sinds die datum moeten fabrikanten ENISA SRP gebruiken voor 24u-waarschuwingen, 72u-meldingen en eindrapporten. De bredere productbeveiligingseisen gelden vanaf 11 december 2027.
Wat is ENISA SRP?
SRP is het gezamenlijke kanaal voor verplichte CRA-meldingen. Vrijwillige melding is niet beschikbaar en komt pas in een latere fase. Volg de Commissiepagina en de ENISA SRP-pagina voor registratiedetails.
Is een CVD-beleid verplicht?
Ja. Elke fabrikant heeft een CVD-beleid en een praktisch intakekanaal nodig. security.txt wordt niet in de CRA genoemd, maar is een praktische manier om het contactadres te publiceren.
Is VEX nodig?
VEX is niet bij naam verplicht, maar een toepasbaarheidsregister is zeer nuttig om te onderbouwen waarom een bekende CVE het product niet raakt.
Welke boetes gelden?
Te late of ontbrekende meldingen kunnen serieuze handhavingsblootstelling opleveren; alleen micro- en kleine ondernemingen hebben een smalle verlichting voor de eerste 24h-vroege waarschuwing. Zie CRA-boetes en handhaving voor de volledige structuur.
Waar dienen we in als het product in meerdere lidstaten wordt verkocht?
Dien een keer in via het SRP-punt van uw coördinerende CSIRT. Zonder hoofdvestiging in de Unie geldt de keten gemachtigde vertegenwoordiger, importeur, distributeur, grootste gebruikersconcentratie.
Pauzeert de 24u-klok in het weekend?
Nee. De klokken lopen in kalendertijd, dus weekend- en feestdagpiket is operationeel nodig.
Hoe werkt CRA samen met NIS 2?
Beide kunnen op dezelfde gebeurtenis van toepassing zijn, maar CRA is productniveau via SRP en NIS 2 is entiteits- of dienstniveau via een nationaal kanaal. Behandel claims dat een enkele indiening voor beide volstaat als onbevestigd totdat autoriteiten definitieve richtsnoeren publiceren.
De Glossary noemt dit veld verplicht bij de eerste waarschuwing van 24 uur en vermeldt in dezelfde regel dat het in de volgende release van het platform komt. Zolang die release er niet is, kunt u het op het scherm missen. Leg uw eigen tijdstip van kennisname vast en zorg dat u het hoe dan ook kunt aanleveren. ↩︎
De Glossary vermeldt dat dit veld in de huidige release “Date and time when the incident was detected (UTC time)” heet. Detectie is niet hetzelfde als kennisname, dus leg beide vast. ↩︎