Verordening cyberweerbaarheid I: welke producten vallen eronder, en in welke klasse

Het juridisch kader

De Verordening cyberweerbaarheid, beter bekend als de Cyber Resilience Act (CRA), is Verordening (EU) 2024/2847 van 23 oktober 2024. Ze verscheen op 20 november 2024 in het Publicatieblad en trad in werking op 10 december 2024. Ze legt cyberbeveiligingsvereisten op aan verbonden hardware en software voordat die in de Unie verkocht mogen worden.

De verordening wordt in drie stappen van toepassing (artikel 71):

• 11 juni 2026: hoofdstuk IV (artikelen 35 tot en met 51), de regels voor de instanties die producten zullen beoordelen (aangemelde instanties).
• 11 september 2026: artikel 14, de plicht van fabrikanten om actief uitgebuite kwetsbaarheden en ernstige incidenten te melden. Dat behandelen we in deel II van deze reeks.
• 11 december 2027: al de rest, met de productvereisten, de CE-markering en de plichten van importeurs en distributeurs.

Dit eerste deel beantwoordt twee vragen: valt je product eronder, en in welke klasse?

De toets van artikel 2

De CRA geldt voor "op de markt aangeboden producten met digitale elementen waarvan het beoogde doel of het redelijkerwijs voorzienbaar gebruik een directe of indirecte logische of fysieke gegevensverbinding met een apparaat of netwerk omvat" (artikel 2, lid 1). Drie elementen uit die toets zijn belangrijk.

Een product met digitale elementen. Dat is "een software- of hardwareproduct en zijn oplossingen voor gegevensverwerking op afstand", ook componenten die afzonderlijk in de handel worden gebracht (artikel 3, punt 1). Losse software telt mee. Een chip die je aan andere fabrikanten verkoopt ook.

Gegevensverwerking op afstand. Cloudfuncties vallen er alleen onder als de fabrikant ze ontwerpt of laat ontwerpen en het product zonder die functie een van zijn functies niet kan vervullen (artikel 3, punt 2). Overweging 12 geeft het voorbeeld van de cloudfunctie waarmee je een slim huishoudtoestel op afstand bedient. Een website die de functionaliteit van een product niet ondersteunt valt er niet onder, net zomin als een clouddienst die buiten de verantwoordelijkheid van een productfabrikant is ontwikkeld. Dezelfde overweging wijst erop dat NIS2 clouddiensten zoals software as a service dekt.

Op de markt aangeboden. Dat is het leveren "in het kader van een handelsactiviteit, tegen betaling of kosteloos" (artikel 3, punt 22). Gratis software kan er dus onder vallen als er een verdienmodel achter zit. Overweging 15 geeft voorbeelden, zoals betaalde technische ondersteuning die meer dan de kosten dekt, of persoonsgegevens als voorwaarde voor gebruik voor andere doelen dan beveiliging, compatibiliteit of interoperabiliteit. De positie van opensourcesoftware staat in deel III.

Wat valt erbuiten

Artikel 2, leden 2 tot en met 7, sluit uit:

• producten die onder de Verordening medische hulpmiddelen (EU) 2017/745, de Verordening medische hulpmiddelen voor in-vitrodiagnostiek (EU) 2017/746 of de typegoedkeuringsverordening voor motorvoertuigen (EU) 2019/2144 vallen;
• producten die gecertificeerd zijn onder de luchtvaartverordening (EU) 2018/1139;
• uitrusting van zeeschepen onder Richtlijn 2014/90/EU;
• reserveonderdelen die identieke componenten vervangen en volgens dezelfde specificaties gemaakt zijn;
• producten die uitsluitend voor nationale veiligheid of defensie zijn ontwikkeld of gewijzigd, of die ontworpen zijn om gerubriceerde informatie te verwerken.

De Commissie kan de CRA bovendien bij gedelegeerde handeling beperken of uitsluiten als sectorale regels een even hoog of hoger beschermingsniveau bieden (artikel 2, lid 5).

De vier niveaus

Elk product dat eronder valt, moet voldoen aan de essentiële vereisten van bijlage I (artikel 6). De klasse bepaalt hoe je dat aantoont.

Gewone producten. De meeste producten staan op geen enkele lijst. De fabrikant mag dan zelf de conformiteit beoordelen via interne controle (module A) (artikel 32, lid 1).

Belangrijke producten, klasse I (artikel 7 en bijlage III). De lijst telt 19 categorieën. Voorbeelden: software en hardware voor identiteitsbeheer en geprivilegieerde toegang, op zichzelf staande en ingebedde browsers, wachtwoordbeheer, antimalwaresoftware, VPN-producten, netwerkbeheersystemen, SIEM-systemen, bootmanagement, software voor publieke-sleutelinfrastructuur, besturingssystemen, routers, internetmodems en switches, microprocessoren en microcontrollers met beveiligingsfuncties, virtuele assistenten voor slimme huizen, slimme-huisproducten met beveiligingsfuncties (slimme deursloten, beveiligingscamera's, babymonitors, alarmsystemen), verbonden speelgoed met sociale interactie of locatietracering, en wearables voor gezondheidsmonitoring die geen medisch hulpmiddel zijn of die voor kinderen bedoeld zijn.

Belangrijke producten, klasse II. Vier categorieën: hypervisors en containerruntimesystemen, firewalls en systemen voor inbraakdetectie en -preventie, manipulatiebestendige microprocessoren en manipulatiebestendige microcontrollers.

Kritieke producten (artikel 8 en bijlage IV). Drie categorieën: hardwareapparaten met beveiligingsboxen, slimme-metergateways en andere apparaten voor geavanceerde beveiligingsdoeleinden, waaronder veilige cryptoverwerking, en smartcards of vergelijkbare apparaten, waaronder secure elements.

Wat telt, is de kernfunctionaliteit van het product. Artikel 7, lid 1, voegt een handige regel toe: wie een belangrijk product inbouwt, maakt het gastproduct daardoor nog niet belangrijk. Een slimme koelkast met een ingebouwde browser wordt geen klasse I-product omdat de browser het is.

Artikel 7, lid 2, geeft de criteria voor de lijst: functies die cruciaal zijn voor de cyberbeveiliging van andere producten, of een functie met een aanzienlijk risico op verstoring of schade, zoals netwerkbeheer of virtualisatie. De Commissie kan de lijsten bij gedelegeerde handeling wijzigen, voor belangrijke producten in de regel met een overgangsperiode van minstens 12 maanden (artikel 7, lid 3) en voor kritieke producten van zes maanden (artikel 8, lid 2). Artikel 7, lid 4, droeg de Commissie op om tegen 11 december 2025 een uitvoeringshandeling vast te stellen met de technische beschrijving van de categorieën uit de bijlagen III en IV. Lees de bijlagen samen met die handeling.

De conformiteitsroute per klasse

• Gewoon: module A (interne controle), module B plus C, module H of een Europese certificeringsregeling (artikel 32, lid 1).
• Klasse I: module A volstaat alleen als je geharmoniseerde normen, gemeenschappelijke specificaties of een Europese cyberbeveiligingscertificeringsregeling op zekerheidsniveau minstens "substantieel" volledig toepast. Anders komt er een aangemelde instantie aan te pas, via module B plus C of module H (artikel 32, lid 2).
• Klasse II: module B plus C, module H, of een Europese certificeringsregeling op niveau minstens "substantieel". Zelfbeoordeling kan niet (artikel 32, lid 3).
• Kritiek: een Europees cyberbeveiligingscertificaat als een gedelegeerde handeling op grond van artikel 8, lid 1, dat vereist; anders een van de routes voor klasse II (artikel 32, lid 4).

Vrije en opensourcesoftware in een categorie van bijlage III mag de routes van artikel 32, lid 1, volgen als de technische documentatie openbaar wordt gemaakt wanneer het product in de handel komt (artikel 32, lid 5). Micro- en kleine ondernemingen mogen een vereenvoudigd formulier voor de technische documentatie gebruiken (artikel 33, lid 5).

AI met een hoog risico

Een product dat ook een AI-systeem met een hoog risico is onder de AI-verordening, wordt geacht te voldoen aan de cyberbeveiligingseis van artikel 15 van die verordening als het aan bijlage I van de CRA voldoet en de EU-conformiteitsverklaring dat aantoont (artikel 12). In ons overzicht van de AI-verordening lees je wanneer een AI-systeem een hoog risico heeft.

Producten die al op de markt zijn

Producten die vóór 11 december 2027 in de handel zijn gebracht, vallen alleen onder de CRA als ze na die datum ingrijpend worden gewijzigd (artikel 69, lid 2). De meldplicht van artikel 14 is de uitzondering: die geldt voor alle producten binnen het toepassingsgebied, ongeacht wanneer ze in de handel kwamen (artikel 69, lid 3). Een ingrijpende wijziging is een wijziging die de conformiteit met deel I van bijlage I raakt of het beoordeelde beoogde doel verandert (artikel 3, punt 30).

Boetes

Inbreuken op bijlage I of op de artikelen 13 en 14 kunnen leiden tot boetes tot 15 miljoen euro of 2,5% van de wereldwijde jaaromzet, als dat hoger is. Andere inbreuken, ook die van importeurs en distributeurs, gaan tot 10 miljoen euro of 2% (artikel 64). De lidstaten leggen de sanctieregels vast.

In de praktijk

Een Belgisch bedrijf maakt een slimme thermostaat met een app en een cloudomgeving waarmee je de temperatuur vanaf je gsm regelt. Thermostaat, app en cloudfunctie vormen samen één product met digitale elementen. Thermostaten staan niet in bijlage III, dus het is een gewoon product en het bedrijf mag zelf de conformiteit beoordelen. Voegt het een module voor een deurslot toe, dan is die module een klasse I-product, en hangt de route ervan af of een geharmoniseerde norm volledig wordt toegepast.

Een softwarebedrijf verkoopt een wachtwoordbeheerder voor de desktop. Dat is klasse I. Is er geen geharmoniseerde norm of past het bedrijf die maar gedeeltelijk toe, dan moet een aangemelde instantie meekijken. Plan dat dus ruim vóór 11 december 2027.

Een start-up bouwt firewalls. Die zijn klasse II, dus er komt altijd een aangemelde instantie aan te pas, of er wordt een certificeringsregeling op niveau "substantieel" gebruikt.

Een online boekingsplatform draait volledig als gehoste dienst in de browser. Dat is geen product met digitale elementen onder de CRA. Het kan wel onder NIS2 vallen; zie ons artikel over de NIS2-richtlijn.

Een fabrikant verkoopt sinds 2025 een routermodel. Verkoopt hij het ongewijzigde model na 11 december 2027 verder, dan gelden de productvereisten niet voor exemplaren die vóór die datum in de handel zijn gebracht. Een firmware-update die de beveiligingsarchitectuur verandert, kan een ingrijpende wijziging zijn, en dan geldt het volledige regime. De meldplicht van artikel 14 geldt al sinds 11 september 2026.

Praktische stappen

1. Maak een lijst van elk product, elke app, firmware en cloudfunctie die je op de EU-markt brengt, ook componenten voor andere fabrikanten.
2. Pas de toets van artikel 2 en de uitzonderingen toe en noteer telkens de kernfunctionaliteit.
3. Leg die functionaliteit naast de bijlagen III en IV en de technische beschrijvingen.
4. Kies een conformiteitsroute en plan de aangemelde instantie waar nodig.
5. Behandel oude modellen die je na 11 december 2027 wijzigt als nieuwe producten.
6. Bekijk je contracten met leveranciers en klanten (hieronder).

Contracten

Vraag in leveringscontracten aan de maker van een component welke klasse hij heeft toegepast, welke conformiteitsroute, welke ondersteuningsperiode en welke softwarestuklijst hij kan delen. Spreek af wie welke kwetsbaarheid aan wie meldt en hoe snel, want een fabrikant die een kwetsbaarheid in een component vindt, moet die melden aan de maker van dat component (artikel 13, lid 6). Maak in distributiecontracten de CE-markering, de conformiteitsverklaring en de gebruikersinformatie een voorwaarde voor levering. Ons artikel over productie- en leveringsovereenkomsten bespreekt de bredere set bedingen.

Veelgestelde vragen

Geldt de CRA voor ons SaaS-product?

Niet voor een louter gehoste dienst. Wel voor gegevensverwerking op afstand die de fabrikant van een product ontwerpt en zonder welke het product een functie niet kan vervullen, zoals de cloudomgeving van een verbonden toestel (artikel 3, punt 2, en overweging 12).

We verkopen alleen aan bedrijven. Vallen we er toch onder?

Ja. De toets hangt niet af van wie koopt. Een fabrikant en een zakelijke gebruiker mogen wel een andere standaardconfiguratie afspreken voor een product op maat (bijlage I, deel I, punt 2, b)).

Is een product met een ingebouwde browser een klasse I-product?

Niet om die reden alleen. Een belangrijk product inbouwen maakt het gastproduct niet belangrijk (artikel 7, lid 1). De browser zelf is klasse I als hij afzonderlijk in de handel wordt gebracht.

Wat gebeurt er met producten die we nu al verkopen?

Exemplaren die vóór 11 december 2027 in de handel zijn gebracht, blijven buiten de productvereisten, tenzij ze ingrijpend worden gewijzigd. De meldplicht van artikel 14 geldt er sinds 11 september 2026 wel voor.

Hoe dit samenhangt

De CRA komt eerst in je contracten terecht: bij leveranciers van componenten en bij klanten die bewijs vragen. Ons team handelscontracten en transacties stelt de bedingen op, en Document Studio, ons eigen systeem voor documentanalyse en -opmaak, toetst bestaande leverings- en distributiecontracten op ontbrekende punten. Het register van rechten en verplichtingen volgt daarna ondersteuningsperiodes en meldafspraken op. Komt er een kwetsbaarheid of incident, dan helpt ons team datalekken met de melding die daarnaast onder de AVG nodig kan zijn.

In één oogopslag

Aangehaalde bepalingen: Verordening (EU) 2024/2847, artikelen 2, 3, 6, 7, 8, 12, 13, lid 6, 14, 32, 33, lid 5, 64, 69 en 71; bijlagen I, III en IV; overwegingen 12 en 15.

Belangrijke data: inwerkingtreding 10 december 2024; aangemelde instanties (hoofdstuk IV) vanaf 11 juni 2026; meldplicht (artikel 14) vanaf 11 september 2026; alle andere bepalingen vanaf 11 december 2027.

De reeks: deel II, kwetsbaarheden en meldingen en deel III, importeurs, distributeurs, open source en contracten. Verwant: AI, software en de nieuwe richtlijn productaansprakelijkheid, de NIS2-richtlijn, de AI-verordening en productie- en leveringsovereenkomsten.