De CRA-meldplicht ging vroeger van start dan veel organisaties verwachtten. Sinds 11 september 2026 moeten fabrikanten van producten met digitale elementen die onder de CRA vallen, actief uitgebuite kwetsbaarheden en ernstige incidenten met impact op de productbeveiliging kunnen melden aan ENISA en de aangewezen CSIRT-coördinator, zoals het CCB in België.
Voor veel organisaties is december 2027 de datum geworden die ze met de Cyber Resilience Act associëren. Vanaf dan is de CRA algemeen van toepassing op producten met digitale elementen die op de EU-markt worden gebracht.
Maar de eerste operationele meldplichten kwamen vroeger. Sinds 11 september 2026 moeten fabrikanten van producten binnen het toepassingsgebied van de CRA actief uitgebuite kwetsbaarheden en ernstige incidenten met impact op de productbeveiliging kunnen melden. De richtsnoeren van de Europese Commissie van juli 2026 bevestigen dat dit ook geldt voor producten die al vóór 11 december 2027 op de markt zijn gebracht.
Dat verandert de vraag die vandaag op tafel ligt. Het gaat niet langer alleen over de vraag of een organisatie tegen 2027 volledige CRA-conformiteit kan aantonen. Het gaat erom of ze vandaag, onder strakke deadlines, een productbeveiligingsincident kan detecteren, beoordelen, escaleren en melden.
Zou uw organisatie morgen een CRA-relevant productbeveiligingsincident kunnen vaststellen, documenteren en melden?
1. Waarom is de eerste CRA-deadline een operationele uitdaging?
Op het eerste gezicht lijkt melden een juridische of compliance-activiteit. In de praktijk is de melding alleen de zichtbare uitkomst van een veel breder beveiligingsproces.
Voordat een fabrikant een actief uitgebuite kwetsbaarheid kan melden, moet hij vaststellen welke producten en versies getroffen zijn, of de kwetsbare functionaliteit bereikbaar is, of de uitbuiting plaatsvindt in de context van het product, welke gebruikers mogelijk getroffen zijn, welke mitigerende maatregelen beschikbaar zijn en wie bevoegd is om de beslissing tot melden te nemen.
Die capaciteiten hangen doorgaans af van Product Security, Application Security, Vulnerability Management, Incident Response en Engineering. Juridische en compliance-stakeholders blijven belangrijk, maar zij kunnen het onderliggende technische bewijs niet meer creëren als een incident al begonnen is.
De meldprocedure in één oogopslag
| Aanleiding | Binnen 24 uur | Binnen 72 uur | Eindverslag |
|---|---|---|---|
| Actief uitgebuite kwetsbaarheid | Vroege waarschuwing | Kennisgeving van de kwetsbaarheid | Uiterlijk 14 dagen nadat een corrigerende of mitigerende maatregel beschikbaar is |
| Ernstig incident met impact op de productbeveiliging | Vroege waarschuwing | Kennisgeving van het incident | Binnen één maand na de kennisgeving van het incident |
2. Wanneer begint de klok te lopen? Het begrip “kennis krijgen”
De meldklok begint niet noodzakelijk te lopen bij elk vaag signaal, elk niet-gevalideerd gerucht of elk verdacht supportticket. Volgens de richtsnoeren van de Commissie is het relevante moment bereikt wanneer de fabrikant, na een eerste beoordeling, een redelijke mate van zekerheid heeft dat een kwetsbaarheid actief wordt uitgebuit of dat een ernstig incident de beveiliging van het product heeft aangetast.
Dat onderscheid is nuttig, maar veeleisend. Het betekent dat de organisatie een snelle en verdedigbare route nodig heeft van signaal naar beslissing. Wachten op volledige zekerheid kan vertraging veroorzaken; elk zwak signaal als bevestigd beschouwen kan tot onnodige escalatie leiden. De operationele capaciteit zit in die eerste beoordeling.
Om die beoordeling consequent te maken, hebben teams afgesproken criteria, bewijsbronnen en een duidelijke beslissingsverantwoordelijkheid nodig. Ze moeten kunnen reconstrueren wanneer een signaal binnenkwam, wat er werd gecontroleerd, wanneer een redelijke mate van zekerheid werd bereikt, wie de conclusie goedkeurde en wanneer de externe meldingen werden ingediend.
Vragen die het proces moet beantwoorden
- Wie voert de eerste technische beoordeling uit?
- Welk bewijs volstaat om te besluiten dat er actieve uitbuiting is?
- Hoe worden getroffen producten, versies en klanten geïdentificeerd?
- Wie mag verklaren dat een redelijke mate van zekerheid is bereikt?
- Hoe worden onzekerheid, afwijkende meningen en goedkeuring vastgelegd?
3. Waarom vraagt melden meer dan een formulier?
Bij een actief uitgebuite kwetsbaarheid kan het proces een vroege waarschuwing binnen 24 uur vereisen, een kennisgeving van de kwetsbaarheid binnen 72 uur en een eindverslag uiterlijk 14 dagen nadat een corrigerende of mitigerende maatregel beschikbaar is. Bij een ernstig incident kan het proces een vroege waarschuwing binnen 24 uur vereisen, een kennisgeving van het incident binnen 72 uur en een eindverslag binnen één maand na de kennisgeving van het incident.
Deze meldingen moeten worden ingediend via het Single Reporting Platform (SRP) van ENISA. Dat platform biedt één centraal meldkanaal en bezorgt de informatie aan de bevoegde nationale CSIRT-coördinator, zoals het CCB in België.
De eerste fases kunnen dus niet afhangen van werk dat nog van nul moet beginnen. Productidentificatie, meldcontacten, goedkeuringsroutes, bewijsbeheer en communicatiesjablonen moeten al klaarliggen. Voor de melding binnen 72 uur is vervolgens een eerste technisch beeld nodig: de aard van de exploit of het incident, het getroffen product, de beschikbare impactanalyse, de al genomen maatregelen, de maatregelen die gebruikers kunnen nemen en de gevoeligheid van de gemelde informatie.
Nadat de fabrikant er kennis van heeft gekregen, moeten ook de getroffen gebruikers worden geïnformeerd en waar nodig de passende risicobeperkende of corrigerende maatregelen krijgen. Die communicatie moet tijdig, risicogebaseerd en proportioneel zijn. Ze moet gebruikers helpen hun blootstelling te beperken, zonder technische details ruimer te verspreiden dan nodig zolang uitbuiting nog mogelijk is.
Een component van derden kan toch een meldkwestie op productniveau worden
Een publieke CVE in een dependency is niet automatisch meldplichtig voor elke fabrikant die die dependency gebruikt. De organisatie moet nagaan of de kwetsbaarheid in de context van haar product aanwezig is, of de kwetsbare code bereikbaar is en of de situatie voldoet aan het criterium van actieve uitbuiting. Dat oordeel hangt rechtstreeks af van de kwaliteit van de SBOM (software bill of materials), de dekking van SCA (software composition analysis), het eigenaarschap van dependencies en de bereikbaarheidsanalyse in de productcontext.
4. Wat betekent dit voor elke rol?
Voor developers en productteams. Productteams hoeven geen regelgevingsspecialisten te worden. Ze moeten wel snel productinformatie beschikbaar kunnen maken wanneer zich een incident voordoet.
- Zorg voor duidelijk eigenaarschap van producten, versies, deploymentmodellen en ondersteunde configuraties.
- Koppel kwetsbaarheden en incidenten aan de getroffen releases, componenten en klantomgevingen.
- Bewaar technisch bewijs en documenteer mitigaties, patches en workarounds.
- Escaleer verdachte signalen over productbeveiliging in plaats van ze in gewone supportwachtrijen te laten liggen.
Voor Application Security- en Product Security-leads. De rol verschuift van kwetsbaarheden vinden naar beslissingen op productniveau mogelijk maken onder tijdsdruk.
- Voorzie een intake- en triageproces voor meldingen van onderzoekers, klanten, leveranciers en interne teams.
- Bepaal criteria voor de beoordeling van uitbuitbaarheid, bereikbaarheid en impact op het product.
- Verbind SBOM/SCA-resultaten, threat models en architectuurkennis met de incidentanalyse.
- Houd een beslissingslogboek bij dat toont hoe het moment van kennisname en de meldplicht werden bepaald.
Voor incident response- en PSIRT-teams. CRA-meldparaatheid hangt af van een PSIRT (Product Security Incident Response Team) of een gelijkwaardig operationeel model dat technisch onderzoek, producteigenaarschap, meldingen aan de autoriteiten en klantcommunicatie met elkaar verbindt.
- Bepaal escalatiedrempels voor actief uitgebuite kwetsbaarheden en ernstige incidenten met impact op de productbeveiliging.
- Bereid workflows en sjablonen voor de melding binnen 24 uur, binnen 72 uur en het eindverslag voor.
- Coördineer corrigerende maatregelen, richtlijnen voor gebruikers en doorlopende updates.
- Oefen de workflow voordat een echt incident deadlinedruk veroorzaakt.
Voor CTO’s en CISO’s. Het leiderschap heeft de zekerheid nodig dat het proces in de praktijk werkt, niet alleen dat er een beleid bestaat.
- Welke producten vallen onder de CRA, inclusief producten die al op de markt zijn?
- Wie is eigenaar van de beslissing om te melden?
- Kan de organisatie binnen 24 uur vaststellen of er sprake is van actieve uitbuiting?
- Weet de organisatie hoe ENISA en de aangewezen CSIRT-coördinator in de workflow passen?
- Kan ze de tijdlijn aantonen van kennisname, triage, goedkeuring, indiening en communicatie met gebruikers?
5. Hoe bouwt u de brug naar meldparaatheid?
De meeste organisaties hoeven geen volledig nieuwe beveiligingsdisciplines uit te vinden. De bouwstenen bestaan al in volwassen AppSec- en productbeveiligingsprogramma’s. Het werk bestaat erin ze te verbinden tot een herhaalbaar, op bewijs gebaseerd operationeel proces.
| Capaciteit | Hoe paraatheid eruitziet |
|---|---|
| Zicht op producten | Een inventaris van mogelijk betrokken producten, versies, eigenaars, dependencies, distributie en ondersteuningsstatus. |
| Intake van kwetsbaarheden | Een gestructureerde route om meldingen van klanten, onderzoekers, leveranciers en interne teams te ontvangen en op te volgen. |
| PSIRT-eigenaarschap | Duidelijke verantwoordelijkheid voor triage, beslissingen over meldplicht, meldingen, coördinatie van remediëring en communicatie met gebruikers. |
| Beoordeling van uitbuitbaarheid | Gedocumenteerde criteria voor bereikbaarheid, bewijs van uitbuiting, getroffen versies en impact op productniveau. |
| Meldworkflow | Gekende stappen richting ENISA en de CSIRT-coördinator, interne goedkeuringen, contactpersonen, timers en voorbereide sjablonen. |
| Communicatie met gebruikers | Een proportioneel proces om getroffen gebruikers te informeren en hun bruikbare mitigerende of corrigerende richtlijnen te geven. |
| Bewijs en traceerbaarheid | Een beslissingslogboek dat signalen, beoordelingsstappen, het moment van kennisname, goedkeuringen, indieningen en updates bewaart. |
6. Hoe sluit dit aan bij AppSec en productbeveiliging?
CRA-meldparaatheid staat niet los van veilige softwareontwikkeling. Secure SDLC-praktijken leveren de productkennis en traceerbaarheid op die tijdens een incident nodig zijn. Threat modelling brengt misbruikpaden, kritieke assets en telemetriebehoeften in kaart. OWASP SAMM kan helpen beoordelen of praktijken rond governance, ontwerp, implementatie, verificatie en operations herhaalbaar zijn in plaats van informeel.
SBOM- en SCA-capaciteiten worden operationele input voor componentanalyse. Vulnerability management bepaalt ernst, uitbuitbaarheid, eigenaarschap en remediëring. Incident response zorgt voor onderzoek en coördinatie. Governance rond productbeveiliging verbindt die capaciteiten met verantwoorde beslissingen en klantcommunicatie.
Het praktische probleem is vaak niet dat bepaalde capaciteiten ontbreken. Het is dat ze los van elkaar werken. Een goed paraatheidsprogramma verbindt ze voordat een echt incident de organisatie dwingt te improviseren.
De conclusie
De eerste operationele CRA-deadline was niet december 2027. Het was 11 september 2026, en de verplichtingen gelden nu.
De best voorbereide organisaties zijn die welke problemen met productbeveiliging snel en consequent kunnen identificeren, beoordelen, escaleren en communiceren. Een grote compliance-afdeling kan een gebrekkig zicht op producten, onduidelijk PSIRT-eigenaarschap of trage technische triage niet compenseren.
Het goede nieuws is dat de nodige bouwstenen bekend zijn: vulnerability management, PSIRT-operaties, threat modelling, SBOM/SCA, incident response en veilige ontwikkelpraktijken. De uitdaging is om ze om te vormen tot één operationeel proces dat tijdige beslissingen, betrouwbaar bewijs en proportionele communicatie oplevert.
Dat is de brug die organisaties nu moeten bouwen, voordat het eerste echte incident ze op de proef stelt.
Volgende stap. Onze CRA Reporting Readiness Check beoordeelt of u vandaag aan de meldplicht kunt voldoen, van productscope en intake van kwetsbaarheden tot de ENISA-workflow en de registratie van bewijs. Ontdek de CRA Reporting Readiness Check
Verder lezen. Download onze whitepaper “10 praktische verduidelijkingen uit de CRA-richtsnoeren”. Download de whitepaper
Veelgestelde vragen
Is elke publieke CVE in een component die we gebruiken meldplichtig?
Nee. Dat hangt ervan af of de kwetsbaarheid in uw productcontext aanwezig is, of de kwetsbare code bereikbaar is en of de situatie voldoet aan het criterium van actieve uitbuiting.
Wat moet er binnen 72 uur worden ingediend?
Een eerste technisch beeld: de aard van de exploit of het incident, het getroffen product, de beschikbare impactanalyse, de al genomen maatregelen, de maatregelen die gebruikers kunnen nemen en de gevoeligheid van de informatie.
Hebben we een nieuwe beveiligingsfunctie nodig?
Meestal niet. De bouwstenen bestaan al in volwassen AppSec- en productbeveiligingsprogramma’s. Het werk bestaat erin ze te verbinden tot één herhaalbaar proces.
Bronnen: European Commission CRA guidance, July 2026, Section 9.1 on reporting obligations. ENISA, CRA Single Reporting Platform (SRP).
Dit artikel biedt een praktische beveiligingslezing van de CRA en de richtsnoeren van de Commissie. Het is geen juridisch advies.