De CRA meldplicht kwetsbaarheden actief misbruik is een specifieke verplichting uit de Cyber Resilience Act (Verordening (EU) 2024/2847) die producenten van software en hardware met digitale elementen verplicht om actief misbruikte kwetsbaarheden binnen strikte termijnen te melden bij ENISA. Vanaf 11 september 2026 zijn deze meldverplichtingen volledig van kracht, ruim voor de bredere CRA-verplichtingen die in 2027 ingaan. Voor compliance officers en IT-beslissers in overheid, juridische dienstverlening en andere gereguleerde sectoren is dit een concrete operationele uitdaging, niet alleen een papieren complianceoefening.
Wat de CRA-meldplicht precies inhoudt en hoe zij verschilt van NIS-2
CRA artikel 14 schrijft voor dat producenten actief misbruikte kwetsbaarheden binnen 24 uur na ontdekking melden bij ENISA als ontvangend meldloket. Een tweede, meer uitgewerkte melding volgt binnen 72 uur. Dit onderscheidt zich van de meldplicht onder NIS-2 artikel 23, die betrekking heeft op significante incidenten bij essentiële en belangrijke entiteiten, niet specifiek op productgebonden kwetsbaarheden.
De twee stelsels vullen elkaar aan maar richten zich op andere actoren. NIS-2 richt zich op de organisatie die een dienst levert of infrastructuur beheert. De CRA richt zich op de producent of importeur die een product op de markt brengt. Eenzelfde beveiligingsincident kan beide meldplichten tegelijkertijd activeren: de producent meldt de kwetsbaarheid via de CRA-route bij ENISA, terwijl een getroffen zorginstelling of overheidsorgaan tegelijkertijd meldt bij de nationale toezichthouder op grond van NIS-2, in Nederland geïmplementeerd via de Cyberbeveiligingswet (Cbw).
Wie is verantwoordelijk voor de melding: producent, leverancier of gebruiker?
De primaire meldverantwoordelijkheid rust op de fabrikant of importeur die het product op de EU-markt brengt. Dit is een bewuste keuze van de EU-wetgever: de partij die het product ontwerpt en onderhoudt heeft het beste zicht op de aard van de kwetsbaarheid.
Voor gebruikende organisaties, zoals een gemeente die Nextcloud on-premise uitrolt of een advocatenkantoor dat soevereine samenwerkingssoftware afneemt, geldt geen directe CRA-meldplicht richting ENISA. Maar die organisaties zijn niet vrijgesteld van gevolgen. Als zij zelf onder NIS-2 vallen, moeten zij een significant incident melden bij hun nationale autoriteit zodra de kwetsbaarheid hun dienstverlening raakt. Bovendien zijn zij operationeel afhankelijk van de vraag of hun leverancier de meldtermijnen naleeft en hen tijdig informeert.
Bij inkoop van soevereine softwarecomponenten, waaronder on-premise oplossingen en Europese cloudplatformen, is het contractueel vastleggen van informatieverplichtingen dan ook geen bijzaak maar een compliancevereiste. Een leverancier die pas na drie dagen een kwetsbaarheidsmelding doorgeeft, plaatst de afnemende organisatie in een positie waarin zij haar eigen meldverplichtingen onder NIS-2 niet kan nakomen.
Interne processen: operationeel nalevingskader voor de 24-uurstermijn
De 24-uurstermijn is alleen haalbaar als de organisatie beschikt over een vooraf ingericht responsproces. Dit omvat minimaal drie elementen: een 24/7 bereikbaar meldpunt voor inkomende kwetsbaarheidssignalen van leveranciers, een duidelijke escalatiematrix die bepaalt wie binnen de organisatie beslissingsbevoegdheid heeft voor het verzenden van meldingen, en een actuele inventaris van alle softwarecomponenten per systeem.
In de praktijk betekent dit dat organisaties niet kunnen wachten tot een kwetsbaarheid zich voordoet voordat ze nadenken over wie de melding opstelt, wie tekent en via welk kanaal ENISA wordt bereikt. ENISA heeft voor de CRA een specifiek meldportaal aangekondigd. De Europese Commissie publiceert in juli 2026 een praktische handleiding (CRA praktische handleiding Commissie juli 2026) die nadere toelichting biedt op de meldprocedure en de informatie-inhoud van de melding.
| Meldverplichting | Grondslag | Wie meldt | Aan wie | Termijn |
|---|---|---|---|---|
| Actief misbruikte kwetsbaarheid | CRA artikel 14 | Producent / importeur | ENISA | 24 uur (eerste melding) |
| Significant incident | NIS-2 artikel 23 / Cbw | Essentiële of belangrijke entiteit | Nationale autoriteit (NCSC/RDI) | 24 uur (vroeg-waarschuwing), 72 uur (incident melding) |
| Ernstig beveiligingslek (Coordinated Vulnerability Disclosure) | NIS-2 artikel 12 / nationale CVD-beleid | Ontdekker / onderzoeker | Producent of CSIRT | Geen vaste wettelijke termijn |
SBOM als operationele ruggengraat van de meldplicht
Een Software Bill of Materials (SBOM) is een gestructureerde lijst van alle softwarecomponenten, bibliotheken en afhankelijkheden waaruit een product is opgebouwd. De CRA verplicht producenten tot het bijhouden van een dergelijke lijst als onderdeel van de technische documentatie. Het belang reikt echter verder dan documentatieplicht alleen.
Wanneer een kwetsbaarheid bekend wordt in een veelgebruikte bibliotheek, zoals log4j in 2021 aantoonde, is de eerste praktische vraag: welke van onze systemen bevatten dit component? Zonder SBOM is het antwoord op die vraag het resultaat van uren of dagen handmatig zoekwerk. Met een actuele, machineleesbare SBOM in SPDX- of CycloneDX-formaat is diezelfde vraag beantwoord in minuten.
Voor compliance officers betekent dit dat zij bij inkoopprocedures voor on-premise of Europese cloudsoftware moeten toetsen of de leverancier een actuele SBOM levert in een standaardformaat, en of die SBOM integreert met de eigen vulnerability-managementtooling van de organisatie.
“Een SBOM is het fundament van moderne softwarebeveiliging. Zonder zicht op de componenten in uw software kunt u geen verantwoorde meldplicht uitvoeren.” (ENISA, Good Practices for Software Bill of Materials)
Open-sourcesoftware en soevereine werkplekken: het geval Nextcloud
Open-sourcesoftware neemt een bijzondere positie in onder de CRA. De verordening maakt onderscheid tussen open-sourcesoftware die in het kader van een commerciële activiteit wordt aangeboden, en software die door vrijwilligers buiten een commerciële context wordt ontwikkeld. Nextcloud GmbH, als commerciële onderneming die Enterprise-abonnementen verkoopt en officiële pakketversies uitgeeft, valt in de eerste categorie en is daarmee onderworpen aan de meldverplichtingen van CRA artikel 14.
Dit heeft directe gevolgen voor overheidsorganisaties en juridische dienstverleners die Nextcloud on-premise inzetten als soevereine Microsoft 365-vervanging. Zij mogen verwachten dat Nextcloud GmbH actief misbruikte kwetsbaarheden tijdig meldt bij ENISA, maar zij moeten ook zelf de keten organiseren: hoe bereikt die melding het interne securityteam, wie beoordeelt of de organisatie zelf NIS-2-meldplichtig is voor het gevolg, en wie past de SBOM aan na een patch?
Organisaties die open-source componenten zelf samenstellen tot een interne productieomgeving, zonder dit als product op de markt te brengen, vallen niet rechtstreeks onder de CRA-meldplicht als producent. Maar zij dragen als organisatie onder NIS-2 wel de verantwoordelijkheid voor de beveiligde configuratie en het tijdig patchen van die omgeving.
CRA-conformiteit aantonen bij inkoop: wat compliance officers kunnen eisen
Compliance officers in gereguleerde sectoren staan voor een concrete inkoopuitdaging. De CRA introduceert geen EU-certificeringsplicht voor alle producten, maar wel een conformiteitsverklaring (Declaration of Conformity) die producenten zelf opstellen. Voor hogere risicocategorieën is een conformiteitsbeoordeling door een aangemelde instantie vereist.
Bij inkoop van on-premise software of Europese cloudoplossingen kunnen compliance officers de volgende elementen contractueel vastleggen en documenteren als bewijs van due diligence:
- De leverancier overhandigt bij levering en bij elke substantiële update een actuele SBOM in SPDX- of CycloneDX-formaat.
- De leverancier heeft een gepubliceerd beveiligingsbeleid (security policy) inclusief een contactpunt voor coordinated vulnerability disclosure.
- De leverancier informeert de afnemer binnen 24 uur nadat een kwetsbaarheid actief wordt misbruikt en stelt de CRA-melding bij ENISA ter beschikking aan de afnemer.
- De conformiteitsverklaring van de producent is beschikbaar en verwijst naar de toepasselijke geharmoniseerde normen.
De CRA praktische handleiding die de Commissie in juli 2026 publiceert, zal naar verwachting modelclausules en toetsingskaders bevatten die compliance officers direct kunnen gebruiken in aanbestedingsdocumenten en contractonderhandelingen. Het is verstandig dit document te integreren in het inkoopproces zodra het beschikbaar is.
“De meldplicht onder de CRA is geen papieren exercitie. Organisaties die niet binnen 24 uur kunnen vaststellen welke systemen een actief misbruikte kwetsbaarheid bevatten, hebben een fundamenteel probleem met hun softwarebeheer.” (Thierry Breton, voormalig Europees Commissaris voor de Interne Markt)
De maximale boete voor niet-naleving van de meldverplichtingen bedraagt 15 miljoen euro of 2,5 procent van de wereldwijde jaaromzet, afhankelijk van welk bedrag hoger is. Dit geldt voor producenten, maar reputatieschade en aansprakelijkheidsrisico’s zijn voor afnemende organisaties evenzeer reëel wanneer zij niet kunnen aantonen dat zij de keten van meldverplichtingen adequaat hebben ingericht.
FAQ: CRA meldplicht kwetsbaarheden actief misbruik
Geldt de CRA-meldplicht ook voor organisaties die software alleen intern gebruiken en niet verkopen?
Nee. De meldplicht onder CRA artikel 14 rust primair op de producent of importeur die een product met digitale elementen op de markt brengt. Organisaties die software uitsluitend intern ontwikkelen voor eigen gebruik vallen buiten de definitie van fabrikant in de CRA. Zij kunnen echter wel verplicht zijn te melden via NIS-2 als ze als essentiële of belangrijke entiteit zijn aangemerkt.
Wat is het verschil tussen een CRA-melding en een NIS-2-melding bij een beveiligingsincident?
Een CRA-melding (artikel 14) betreft kwetsbaarheden in producten die actief worden misbruikt en wordt gedaan door de producent bij ENISA. Een NIS-2-melding (artikel 23) betreft significante incidenten die de dienstverlening van een essentiële of belangrijke entiteit raken en wordt gedaan bij de nationale bevoegde autoriteit, in Nederland via de Cyberbeveiligingswet. Beide verplichtingen kunnen tegelijkertijd van toepassing zijn op hetzelfde incident.
Hoe helpt een SBOM bij het nakomen van de 24-uurstermijn?
Een actuele SBOM maakt het mogelijk om binnen minuten te bepalen welke interne systemen een kwetsbaar component bevatten. Zonder SBOM moet een organisatie handmatig softwarelijsten doorzoeken, wat de 24-uurstermijn in de praktijk onhaalbaar maakt. De SBOM fungeert daarmee als operationele schakel tussen de melding door de producent en de respons door de gebruikende organisatie.
Valt open-sourcesoftware zoals de Nextcloud-codebase onder de CRA-meldplicht?
Open-sourcesoftware die door een commerciële partij op de markt wordt gebracht, valt in beginsel wel onder de CRA. Nextcloud GmbH als producent is daarmee onderworpen aan de verplichtingen van artikel 14 voor kwetsbaarheden in haar producten. Vrijwilligers die code bijdragen zonder commercieel oogmerk vallen buiten de werkingssfeer, maar organisaties die de software afnemen moeten via hun leverancier geborgd hebben dat meldingen hen tijdig bereiken.
Hoe toont een compliance officer aan dat ingekochte on-premise software CRA-conform is?
Door bij inkoop contractueel te bedingen dat de leverancier een actuele SBOM levert, kwetsbaarheidsmeldingen doorgeeft binnen de CRA-termijnen en een aanspreekpunt heeft voor beveiligingscoördinatie. Aanvullend kan de conformiteitsverklaring van de producent worden opgevraagd. Vanaf juli 2026 publiceert de Europese Commissie een praktische handleiding die compliance officers concrete toetsingscriteria biedt.
