Nieuwe Europese cyberregels voor digitale producten, geldt de CRA voor jou?

Wat de wet regelt

De Cyber Resilience Act, in het Nederlands de verordening cyberweerbaarheid, is sinds 10 december 2024 van kracht. Hij stelt beveiligingseisen aan producten met digitale elementen. Dat is een brede term. Software en apps vallen eronder, maar ook slimme apparaten zoals camera's, babyfoons en smartwatches, en gewone apparatuur waar software in zit.

Het uitgangspunt is dat een digitaal product veilig moet zijn op het moment dat je het koopt, en veilig moet blijven zolang je het gebruikt. Een product met een bekend lek dat nooit een update krijgt hoort straks niet meer op de Europese markt thuis. De Europese Commissie heeft de wettekst samengevat (opent in een nieuw tabblad) voor wie de hoofdlijn wil zien zonder de verordening zelf door te lezen.

Eind juli 2026 kwam daar uitleg bij. De Commissie publiceerde een leidraad voor bedrijven (opent in een nieuw tabblad) van ongeveer tachtig pagina's, met voorbeelden en beslisschema's. Die leidraad is juridisch niet bindend, maar hij beantwoordt wel de vragen die fabrikanten het vaakst stellen. Het grootste deel gaat over de vraag waar bijna iedereen op vastloopt, namelijk of een product er nu wel of niet onder valt.

Verwar de CRA niet met de Cyberbeveiligingswet. Die gaat over hoe jij je eigen organisatie beveiligt, de CRA gaat over wat je verkoopt. Ze kunnen allebei gelden, en dan zijn het twee losse trajecten. Wat de eerste van je vraagt staat in de Cyberbeveiligingswet geldt vanaf nu.

Geldt hij voor jou

Voor de meeste mkb-bedrijven is het antwoord nee, en dat willen we eerst wegnemen. De CRA richt zich op wie een product op de markt brengt, niet op wie het gebruikt. Koop je software en apparatuur en zet je die in je eigen bedrijf in, dan volgen hier geen verplichtingen voor jou uit. Je merkt de wet dan vooral doordat je leveranciers beter moeten gaan leveren.

Er valt ook meer buiten dan mensen denken. Een website valt er niet onder. Een clouddienst of SaaS die je afneemt evenmin, tenzij die dienst onlosmakelijk bij een product hoort en dat product zonder die dienst niet werkt. De grens ligt dus niet bij browser of installatie, maar bij product of dienst.

Je zit er wel in zodra je zelf een digitaal product maakt, laat maken of verkoopt. Drie situaties waarin mkb-bedrijven zichzelf structureel onderschatten.

1. Je zet je eigen naam op andermans product. Verkoop je apparatuur onder je eigen merk, dan ben je voor deze wet de fabrikant, ook al heb je zelf niets ontworpen. Dat geldt net zo goed voor de importeur of handelaar die er een eigen label op plakt.
2. Je verkoopt software die je hebt laten bouwen. Wie de code geschreven heeft doet er niet toe. Wie het onder eigen naam op de markt zet is de fabrikant. Reden te meer om vast te leggen wat van jou is, zie van wie zijn de code en de data.
3. Je hebt zelf iets gebouwd en bent het gaan verkopen. Dat komt sinds AI-hulpmiddelen vaker voor dan je zou denken. Een werkend prototype is snel gemaakt, een product dat aan deze eisen voldoet is iets anders. Daar gaat je AI-app productieklaar maken over.

De twee data die tellen

In het nieuws gaat het bijna altijd over december 2027, en dat is de datum waar je je het minst druk om hoeft te maken.

1. 11 september 2026. De meldplicht gaat in. Actief misbruikte kwetsbaarheden en ernstige incidenten meld je vanaf dan.
2. 11 december 2027. De rest gaat in. De beveiligingseisen zelf, de risicobeoordeling, de technische documentatie en de CE-markering.

De eerste datum is dus al over een paar weken, en die geldt ook voor producten die je jaren geleden hebt verkocht en die nog bij klanten in gebruik zijn.

Wat er van een fabrikant wordt gevraagd

Ben je fabrikant in de zin van deze wet, dan komt het op vier dingen neer.

1. Melden binnen strakke termijnen. Dat gaat via één Europees meldpunt dat ENISA beheert, waarna de melding tegelijk bij het Nederlandse CSIRT terechtkomt. De termijnen lopen op. Binnen vierentwintig uur een eerste waarschuwing, binnen tweeënzeventig uur de melding zelf, en daarna een eindrapport, binnen veertien dagen bij een kwetsbaarheid en binnen een maand bij een ernstig incident. De Commissie beschrijft wat er precies gemeld moet worden (opent in een nieuw tabblad).
2. Risico's beoordelen en vastleggen. Je brengt in kaart wat er met je product mis kan gaan, neemt daar maatregelen op en documenteert dat. Die documentatie is ook wat een toezichthouder opvraagt.
3. Updates leveren gedurende de ondersteuningstermijn. Die is minstens vijf jaar, tenzij het product aantoonbaar korter meegaat. Gaat het langer mee, dan hoort de termijn daarbij te passen. Je moet die termijn ook vooraf aan je klant vertellen.
4. Opnieuw kijken na een substantiële wijziging. Dat is een wijziging die het beveiligingsrisico verandert op een manier die nog niet in je beoordeling stond. Een gewone beveiligingsupdate is dat niet, ook niet als er technisch veel in verandert.

De boetes lopen op tot vijftien miljoen euro of tweeënhalf procent van de wereldwijde jaaromzet, en het hoogste van die twee telt. Er zit één uitzondering in die voor kleine bedrijven uitmaakt. Een micro-onderneming of klein bedrijf kan niet worden beboet voor het missen van die eerste vierentwintig uur. De tweeënzeventig uur en alle andere plichten blijven wel gewoon staan.

Waar je nu mee begint

Begin niet bij de verordening maar bij je eigen productaanbod. In de praktijk zit de winst in vijf dingen.

1. Zet op een rij wat je onder eigen naam verkoopt, inclusief het spul dat je inkoopt en doorlevert met je eigen logo erop.
2. Weet wat er in je product zit. Je kunt geen kwetsbaarheid binnen vierentwintig uur melden als je niet weet welke componenten en bibliotheken erin verwerkt zijn.
3. Leg vast wie er meldt en wie er buiten kantooruren bereikbaar is. Een termijn van vierentwintig uur haal je niet als de vraag wie dit doet nog open staat.
4. Zorg dat je updates kunt uitrollen zonder je klanten om te gooien. Dat vraagt een plek waar je ze eerst test, zie een testomgeving los van productie.
5. Kies je ondersteuningstermijn en zet hem op papier, in je documentatie en in je verkoopvoorwaarden.

De toezichthouder in Nederland is de Rijksinspectie Digitale Infrastructuur. Op de CRA-pagina van de RDI (opent in een nieuw tabblad) lees je waar zij op gaat controleren, en het NCSC houdt de stand van zaken bij (opent in een nieuw tabblad) voor wie het wil volgen.

Wat wij hierin doen

Wij zijn geen juristen en doen niet alsof. Wat wij wel doen is de techniek eronder op orde brengen, zodat je de vragen die deze wet stelt met bewijs kunt beantwoorden in plaats van met een aanname.

Bouwen wij je software of je webapplicatie, dan hoort dit gesprek er gewoon bij. Wat er in het product zit, hoe updates eruit gaan en hoe lang je dat volhoudt zijn keuzes die je aan het begin maakt en niet achteraf. Zie maatwerk software en web ontwikkeling en onderhoud.

Weet je niet of je fabrikant bent, of weet je het wel en heb je geen idee waar je begint, dan is dat precies waar onze IT-consultancy voor bedoeld is. We brengen in kaart wat je op de markt zet, benoemen wat er ontbreekt en zetten er een volgorde in die je voor 11 september haalt.