Wat er sinds 11 september 2026 geldt
De Cyber Resilience Act is een Europese verordening voor producten met digitale elementen. Zij werkt dus rechtstreeks, zonder Nederlandse implementatiewet. De verordening wordt in stappen van kracht en de eerste stap is de meldplicht van artikel 14, die op 11 september 2026 is ingegaan.
Je meldt in twee situaties:
- Er is betrouwbaar bewijs dat iemand met kwade bedoelingen een kwetsbaarheid in jouw product misbruikt in een systeem
- Er is een ernstig beveiligingsincident dat de beschikbaarheid, authenticiteit, integriteit of vertrouwelijkheid van gevoelige gegevens raakt, of dat kwaadaardige code kan binnenlaten
Een kwetsbaarheid die nog niet aantoonbaar misbruikt wordt, hoef je niet te melden. Dat is het belangrijkste onderscheid in de praktijk: de CRA vraagt geen melding van elke bevinding uit een pentest of elke CVE in een afhankelijkheid, maar wel van actief misbruik. In Nederland gaat de melding naar het NCSC, via het MijnNCSC-portaal of het CRA-meldformulier op ncsc.nl. Een portaalmelding houdt je meldingen bij elkaar, wat bij een vervolgmelding binnen 72 uur prettig werkt.
Wie volgens de CRA fabrikant is
Fabrikant is iedereen die een product met digitale elementen onder eigen naam of merk op de Europese markt brengt. Dat is een brede groep. Het gaat om hardware en software die verbinding kan maken met een ander apparaat of een netwerk, bijvoorbeeld:
- Bedrijfssoftware en maatwerkapplicaties die je als product aanbiedt
- Mobiele apps in de App Store en Google Play
- Besturingssystemen, firmware en ontwikkelbibliotheken
- Netwerkapparatuur, firewalls en IoT-apparaten
Importeurs en distributeurs vallen niet onder de meldplicht, tenzij zij het product onder hun eigen merk aanbieden of substantieel wijzigen. Laat je je software door een bureau bouwen en zet je er je eigen merk op, dan ben jij dus de fabrikant en niet je ontwikkelpartner. Dat maakt het nodig om in het contract vast te leggen wie signaleert, wie beoordeelt en wie binnen die 24 uur de melding doet.
Software die puur als dienst wordt geleverd valt in principe buiten de CRA, omdat die onder NIS2 valt. De uitzondering daarop is belangrijk voor veel maatwerkapplicaties: een oplossing voor gegevensverwerking op afstand die onlosmakelijk bij het product hoort en die door of namens de fabrikant is ontwikkeld, valt wel onder de CRA. Een app met een eigen backend die zonder die backend niet werkt, zit daarmee gewoon in scope.
De vier termijnen, achter elkaar
De meldketen bestaat uit drie of vier stappen, afhankelijk van of het om een kwetsbaarheid of een incident gaat:
- **Binnen 24 uur** na kennisname: vroegtijdige waarschuwing. Je meldt dat er iets speelt en in welke lidstaten het product beschikbaar is.
- **Binnen 72 uur**: de melding zelf, met gegevens over het product, de aard van de kwetsbaarheid of het incident en de maatregelen die je neemt.
- **Binnen 14 dagen** nadat een corrigerende update beschikbaar is, bij een actief misbruikte kwetsbaarheid: het eindverslag, met een beschrijving van de kwetsbaarheid, wat er bekend is over de aanvaller en details over de update.
- **Binnen een maand** na de 72-uursmelding, bij een ernstig incident: het eindverslag met oorzaak, verloop en genomen maatregelen.
Die eerste 24 uur is de reden om dit nu te regelen. Wie moet melden weet in de praktijk pas wie er bevoegd is als het al te laat is. Zorg dus dat vastligt wie de melding mag doen, welke productinformatie je standaard meestuurt en waar de inloggegevens voor MijnNCSC liggen. En let op de tegenstelling met de klok van je eigen oplossing: de melding is niet afhankelijk van of je het probleem al hebt opgelost.
Ook producten die al op de markt staan
Dit is het punt dat bij veel bedrijven mis gaat. De algemene overgangsregel van de verordening zegt dat producten die voor 11 december 2027 op de markt zijn gebracht alleen aan de eisen moeten voldoen als zij daarna substantieel worden gewijzigd. Daarop staat echter een uitdrukkelijke uitzondering: de meldplicht van artikel 14 geldt voor alle producten binnen het toepassingsgebied die voor 11 december 2027 op de markt zijn gebracht.
Met andere woorden: de app die je in 2022 hebt uitgebracht en nu alleen nog onderhoudt, en de apparatuur die al jaren bij klanten in de meterkast hangt, vallen onder de meldplicht. Ook als je er verder niets meer aan ontwikkelt.
Praktisch betekent dat twee dingen. Je hebt een lijst nodig van alle producten die je ooit onder eigen naam op de Europese markt hebt gebracht en die nog in gebruik zijn. En je hebt per product een manier nodig om te merken dat er misbruik plaatsvindt, bijvoorbeeld via monitoring, logging of meldingen van gebruikers. Zonder dat laatste merk je actief misbruik simpelweg niet en loop je de termijn van 24 uur mis zonder het te weten. Bij app-ontwikkeling nemen we om die reden standaard foutmonitoring en logging mee, ook voor applicaties die alleen nog in onderhoud zijn.
Wat er in december 2027 bij komt
Op 11 december 2027 gaan de overige verplichtingen gelden. Die zijn inhoudelijker en raken de manier waarop je bouwt en onderhoudt:
- Essentiële cyberbeveiligingseisen aan het product, waaronder veilige standaardinstellingen en het beperken van aanvalsoppervlak
- Een conformiteitsbeoordeling en CE-markering voor producten met digitale elementen
- Een beleid voor gecoördineerde kwetsbaarheidsmelding en het bijhouden van een softwarestuklijst, de SBOM
- Het beschikbaar stellen van beveiligingsupdates gedurende de ondersteuningsperiode van het product
De handhaving heeft tanden. De verordening kent drie boetecategorieën. Voor het schenden van de essentiële eisen en de kernverplichtingen van fabrikanten, waaronder de meldplicht, lopen de boetes op tot vijftien miljoen euro of 2,5 procent van de wereldwijde jaaromzet, waarbij het hoogste bedrag geldt. Voor overige verplichtingen geldt tien miljoen euro of twee procent, en voor het verstrekken van onjuiste of misleidende informatie aan toezichthouders vijf miljoen euro of een procent.
Organisaties die open source onderhouden met een commercieel oogmerk, de zogeheten open source stewards, krijgen een lichter regime. Dat is geen vrijstelling, maar wel een lichtere set verplichtingen dan die van een gewone fabrikant.
CRA en NIS2 naast elkaar
De twee regimes worden vaak door elkaar gehaald, terwijl ze een heldere scheiding hebben: de CRA gaat over producten, NIS2 over organisaties en hun diensten. Lever je een dienst in een aangewezen sector, dan val je onder de Nederlandse Cyberbeveiligingswet met een registratieplicht, zorgplicht en eigen meldplicht. Bied je een product aan, dan val je onder de CRA.
Het vervelende is dat je prima onder beide kunt vallen, met twee meldplichten die niet identiek zijn. Een zorginstelling die een eigen patiëntenapp uitbrengt, is onder de Cbw een entiteit met een zorgplicht en onder de CRA fabrikant van dat product. Beide meldplichten kennen een stap van 24 uur en een van 72 uur, maar de drempel verschilt: de Cbw kijkt naar significante incidenten in je dienstverlening, de CRA naar actief misbruikte kwetsbaarheden in je product.
Praktisch advies: regel een gezamenlijk meldproces met een duidelijke eerste beoordeling. Wie het signaal krijgt, bepaalt in de eerste uren of dit een Cbw-melding is, een CRA-melding, of beide. Hoe de registratie onder de Nederlandse wet werkt staat in registratieplicht Cyberbeveiligingswet, en wat dit van je softwareleveranciers vraagt in Cyberbeveiligingswet en je softwareleveranciers.
Zo bereid je je ontwikkelproces voor
De CRA vraagt geen nieuw ontwikkelproces, wel een paar vaste afspraken. Dit is wat wij bij klanten als eerste inrichten:
- Een actuele productlijst: wat heb je onder eigen naam op de Europese markt gebracht, welke versies draaien er nog en in welke lidstaten
- Een aanspreekpunt en een mandaat: wie beoordeelt een signaal, wie mag melden en wie neemt over buiten kantooruren
- Monitoring die misbruik zichtbaar maakt: foutmeldingen, verdacht verkeer, authenticatiepogingen en een plek waar gebruikers kwetsbaarheden kunnen melden
- Een voorbereide meldtekst met de vaste productgegevens, zodat de 24-uursmelding een invuloefening is en geen zoektocht
- Inzicht in je afhankelijkheden, zodat je bij een misbruikte kwetsbaarheid in een bibliotheek weet welke van jouw producten geraakt worden
Dat laatste punt is ook de brug naar december 2027, want de SBOM die dan verplicht wordt is precies die lijst. Wie nu begint met het bijhouden van afhankelijkheden heeft straks geen inhaalslag.
Wil je weten of jouw producten onder de CRA vallen en wat je voor de meldplicht moet inrichten, plan dan een gesprek. We lopen je producten, je monitoring en je meldproces langs en zetten op een rij wat er nu moet en wat richting 2027 kan wachten.