Cyber Resilience Act: eisen, data en meldplicht

Wat is de Cyber Resilience Act?

De CRA is Verordening (EU) 2024/2847 van het Europees Parlement en de Raad van 23 oktober 2024 betreffende horizontale cyberbeveiligingsvereisten voor producten met digitale elementen. De verordening is op 20 november 2024 bekendgemaakt in het Publicatieblad van de Europese Unie. Als verordening is ze in al haar onderdelen verbindend en geldt ze rechtstreeks in elke lidstaat, ook zonder omzetting in nationaal recht. Voor wie in cybersecurity werkt, is dit een van de wetten die de productkant raken.

De verordening bevat vier soorten regels. Ze gaat over het op de markt aanbieden van producten met digitale elementen, zodat hun cyberbeveiliging geborgd is. Ze stelt cyberbeveiligingseisen aan het ontwerp, de ontwikkeling en de productie, met verplichtingen voor marktdeelnemers. Ze stelt eisen aan de procedures om op kwetsbaarheden te reageren zolang het product naar verwachting in gebruik is. En ze regelt markttoezicht en handhaving. Volgens de Europese Commissie gelden de eisen voor elke fase van de waardeketen en vult de CRA de wet NIS2 aan.

Het verschil met NIS2 zit in het onderwerp. NIS2 en de Cyberbeveiligingswet gaat over de organisatie en haar netwerk- en informatiesystemen, terwijl de CRA gaat over het product dat een fabrikant op de markt brengt. Een fabrikant van een slim apparaat kan dus onder beide vallen: de CRA voor wat hij verkoopt, en NIS2 voor de eigen organisatie, als die in een van de sectoren van NIS2 zit.

Alles in dit artikel is de stand op de controledatum 5 november 2026.

Voor welke producten geldt de Cyber Resilience Act?

De verordening geldt voor producten met digitale elementen die op de markt worden aangeboden. Dat zijn software- en hardwareproducten, oplossingen voor gegevensverwerking op afstand, en componenten die afzonderlijk in de handel worden gebracht. Een product valt eronder als het beoogde doel of het redelijkerwijs voorzienbare gebruik een directe of indirecte logische of fysieke gegevensverbinding met een apparaat of netwerk omvat. Denk aan slimme apparaten, besturingssoftware en losse componenten.

De fabrikant is de partij die zo'n product ontwikkelt of laat ontwikkelen en onder eigen naam of merk in de handel brengt, tegen betaling, met een verdienmodel of gratis. Ook importeurs en distributeurs zijn marktdeelnemers.

Niet alles valt eronder. Uitgezonderd zijn producten waarop de verordeningen (EU) 2017/745 en (EU) 2017/746 (medische hulpmiddelen) of (EU) 2019/2144 van toepassing zijn, producten die uitsluitend voor nationale veiligheid of defensie zijn ontwikkeld, en reserveonderdelen die identieke componenten vervangen.

Voor open source geldt een aparte rol. Een opensourcesoftwaresteward is een rechtspersoon die geen fabrikant is en die systematisch en duurzaam ondersteuning verleent aan de ontwikkeling van specifieke opensourceproducten die voor handelsactiviteiten zijn bestemd. De verplichtingen voor stewards gaan in op 11 december 2027.

Welke data gelden voor de CRA?

De tabel zet de vaste datums van de verordening naast de stand op 5 november 2026.

Voor producten die er al zijn, geldt een overgangsregel in artikel 69. Producten die vóór 11 december 2027 in de handel zijn gebracht, vallen alleen onder de eisen van de verordening als ze vanaf die datum ingrijpend worden gewijzigd. De meldplicht uit artikel 14 geldt wel voor alle producten binnen het toepassingsgebied die vóór 11 december 2027 in de handel zijn gebracht.

Wat moeten fabrikanten doen?

De verplichtingen van fabrikanten staan in artikel 13. In het kort komen ze hierop neer:

• Het product wordt ontworpen, ontwikkeld en geproduceerd volgens de cyberbeveiligingseisen van bijlage I.
• De fabrikant beoordeelt de cyberbeveiligingsrisico's, documenteert ze en neemt ze op in de technische documentatie.
• Bij het integreren van componenten van derden, ook open source, betracht de fabrikant passende zorgvuldigheid. Een kwetsbaarheid in zo'n component meldt hij aan wie de component onderhoudt.
• Kwetsbaarheden worden aangepakt gedurende een ondersteuningsperiode die de verwachte gebruiksduur weerspiegelt en ten minste vijf jaar bedraagt, tenzij het product naar verwachting korter in gebruik is.
• Elke beveiligingsupdate blijft na afgifte ten minste tien jaar beschikbaar, of voor de rest van de ondersteuningsperiode als die langer is.
• De technische documentatie en de EU-conformiteitsverklaring blijven ten minste tien jaar beschikbaar voor markttoezichtautoriteiten.
• De einddatum van de ondersteuningsperiode, ten minste maand en jaar, wordt bij aankoop duidelijk vermeld.
• De fabrikant wijst een centraal contactpunt aan, onder meer voor het melden van kwetsbaarheden, en heeft een beleid voor gecoördineerde openbaarmaking.

De eisen zelf staan in bijlage I. Deel I beschrijft eigenschappen van het product: het wordt zonder bekende uitbuitbare kwetsbaarheden op de markt aangeboden, het heeft een standaard beveiligde configuratie, kwetsbaarheden zijn aan te pakken met beveiligingsupdates, het beschermt tegen ongeoorloofde toegang via authenticatie en toegangsbeheer, het beschermt de vertrouwelijkheid en integriteit van gegevens, bijvoorbeeld met versleuteling, en het verwerkt zo min mogelijk gegevens. Ook de beschikbaarheid van kernfuncties, zelfs bij denial-of-serviceaanvallen, en een beperkt aanvalsoppervlak horen erbij. Gebruikers moeten gegevens en instellingen veilig kunnen verwijderen.

Deel II gaat over de respons op kwetsbaarheden. De fabrikant stelt kwetsbaarheden en componenten vast en legt ze vast, onder meer in een softwarestuklijst in een gangbaar machineleesbaar formaat. Hij pakt kwetsbaarheden onverwijld aan met beveiligingsupdates en test de beveiliging regelmatig, een taak voor security testing. Verholpen kwetsbaarheden maakt hij openbaar zodra een update beschikbaar is. Updates worden veilig verspreid en, tenzij anders overeengekomen met een zakelijke gebruiker, kosteloos.

Een softwarestuklijst (SBOM) is een lijst van de componenten in je software, ook de open source-onderdelen. Wie weet wat erin zit, kan sneller nagaan of een nieuwe kwetsbaarheid het product raakt.

Dit is werk voor product security, application security en architectuur. Het begint bij het ontwerp, niet bij het testen aan het eind. Eisen als "zonder bekende uitbuitbare kwetsbaarheden" en "standaard beveiligde configuratie" los je niet op met een controle vlak voor de lancering. Een security architect kan al bij het ontwerp nagaan of de eisen haalbaar zijn, en threat modelling is een manier om dat systematisch te doen.

Hoe werkt de meldplicht voor kwetsbaarheden en incidenten?

Een fabrikant meldt elke actief uitgebuite kwetsbaarheid in zijn product, en elk ernstig incident dat gevolgen heeft voor de beveiliging van het product. De melding gaat tegelijk naar het als coördinator aangewezen CSIRT en naar Enisa. Het gaat in drie stappen:

De fabrikant informeert ook de getroffen gebruikers.

Het centrale meldingsplatform van Enisa, het Single Reporting Platform, is volgens de Europese Commissie operationeel sinds 11 september 2026. Een fabrikant meldt eenmalig bij het CSIRT van de lidstaat waar hij zijn hoofdvestiging heeft, en Enisa ontvangt de melding tegelijk. In Nederland meldt een fabrikant bij het Nationaal Cyber Security Centrum (NCSC), via Mijn NCSC of het online meldformulier, zoals de RDI beschrijft.

Een product security incident response team (PSIRT) is een team of rol bij een fabrikant dat meldingen over kwetsbaarheden in het eigen product behandelt. Bij sommige bedrijven zit dat bij security, bij andere bij engineering of productmanagement. De CRA noemt de term niet, maar een fabrikant kan zo de meldplicht organiseren: vooraf bepalen wie beoordeelt of een kwetsbaarheid actief wordt uitgebuit en wie de melding doet. Zonder zo'n proces haal je de 24 uur niet, want de termijn loopt vanaf het moment dat de fabrikant het weet.

Gecoördineerde openbaarmaking (coordinated vulnerability disclosure) betekent dat iemand die een kwetsbaarheid vindt, die eerst privé meldt, en dat de fabrikant het proces beheert voordat het openbaar wordt. De CRA vraagt fabrikanten om hiervoor een beleid en een contactpunt. Het afhandelen van zulke meldingen valt onder vulnerability management.

Wat is de CE-markering voor software en hardware?

Voordat een product in de handel komt, voert de fabrikant een conformiteitsbeoordeling uit van het product en van zijn processen (artikel 32). Daarna stelt hij een EU-conformiteitsverklaring op (artikel 28) en brengt hij de CE-markering aan (artikel 30). Ook de technische documentatie is onderdeel van dit werk.

Voor producten in de vorm van software wordt de CE-markering aangebracht op de EU-conformiteitsverklaring of op de website die bij het product hoort. Interne controle, module A, is een van de procedures die de fabrikant mag kiezen voor producten die niet onder de strengere categorieën vallen.

Voor bepaalde productcategorieën gelden strengere procedures, zoals EU-typeonderzoek, volledige kwaliteitsborging of een Europese certificeringsregeling. Voor welke producten dat geldt, lees je in de bijlagen III en IV van de verordening.

Voor bedrijven die de CE-markering tot nu toe alleen van fysieke producten kenden, is dit nieuw terrein, omdat de CE-markering nu ook voor software geldt. Dit is geen conformiteitsadvies. De exacte vereisten per productcategorie staan in de verordening.

Wie houdt toezicht en wat zijn de boetes?

Niet-naleving van de eisen van bijlage I en van de artikelen 13 en 14 kan leiden tot een administratieve geldboete tot € 15.000.000 of, voor een onderneming, tot 2,5% van de totale wereldwijde jaaromzet in het voorgaande boekjaar, als dat hoger is. Voor andere verplichtingen die artikel 64 noemt, is het maximum € 10.000.000 of 2%. Voor onjuiste, onvolledige of misleidende informatie aan toezichthouders of aangemelde instanties is het maximum € 5.000.000 of 1%.

Er gelden uitzonderingen. Fabrikanten die micro- of kleine ondernemingen zijn, krijgen geen geldboete voor het missen van de 24-uurstermijn. Voor opensourcesoftwarestewards geldt geen geldboete bij inbreuken.

Volgens de RDI is de RDI in Nederland de toezichthouder voor de CRA. De nationale rol wordt geregeld in de Uitvoeringswet verordening cyberweerbaarheid. Dat wetsvoorstel (36875) is op 10 september 2026 door de Tweede Kamer aangenomen. Op de controledatum 5 november 2026 is het volgens de Eerste Kamer zelf nog niet aangenomen: de inbreng voor het verslag was op 27 oktober 2026, en het verslag is in bewerking. Het dossier staat op de website van de Eerste Kamer.

Welke functies en werkgevers raakt de CRA?

Voor kandidaten is de CRA vooral relevant bij organisaties die producten maken of verkopen met software of een gegevensverbinding. Denk aan fabrikanten van apparatuur, softwarebedrijven en bedrijven in de industrie. Je vindt die organisaties op de sectorpagina's voor IT, SaaS en technologie en voor industrie, productie en high tech.

Een application security engineer bouwt security in het ontwikkelproces. Die doet dreigingsmodellering, code review, afhankelijkheidsbeheer en kwetsbaarheidsafhandeling. Een security engineer levert de maatregelen in de product- en bouwomgeving, zoals het veilig verspreiden van updates en het beheren van geheimen. Een security architect ontwerpt het product en de omgeving zo dat de eisen uit bijlage I haalbaar zijn.

Een penetratietester toetst of het product en de updates daadwerkelijk standhouden, wat past bij de eis om de beveiliging regelmatig te testen. Een compliance officer of GRC-consultant houdt de technische documentatie, de conformiteitsbeoordeling en de EU-conformiteitsverklaring op orde. Een incident responder behandelt gemelde kwetsbaarheden en incidenten en bereidt de melding binnen de termijnen voor.

Welke werkgevers deze functies hebben, zie je op de werkgeverspagina's, zoals die voor application security engineers. Wie zich wil verdiepen in het vakgebied, vindt in de kennisbank meer over wetgeving, kaders en certificeringen.