De richtlijnen van de Europese Commissie inzake de Cyber Resilience Act zijn gepubliceerd: wat bedrijven moeten weten

Na jaren van wetgevingsdebat en een gefaseerd implementatieschema is de Cyber Resilience Act (Verordening (EU) 2024/2847, hierna “CRA” genoemd) sinds december 2024 volledig van kracht. De CRA introduceert horizontale, bindende cyberbeveiligingseisen voor producten met digitale elementen die op de EU-markt worden gebracht. Dit betekent een mijlpaal in de manier waarop marktdeelnemers (fabrikanten, importeurs, distributeurs…) cyberbeveiliging gedurende de gehele levenscyclus van een product moeten benaderen. De rapportageverplichtingen gelden vanaf 11 september 2026 en de belangrijkste verplichtingen gelden vanaf 11 december 2027.

Om marktdeelnemers en markttoezichtautoriteiten te helpen bij het navigeren door dit complexe kader en om een tijdige implementatie te ondersteunen, heeft de Europese Commissie op 27 juli 2026 specifieke richtlijnen gepubliceerd, waarin verduidelijking wordt geboden over sleutelbegrippen, afbakeningen van het toepassingsgebied en nalevingsverplichtingen (hierna „Richtlijnen“). De richtlijnen zijn niet bindend voor marktdeelnemers of andere actoren die onder de CRA vallen. Niettemin geven zij de interpretatie van de Commissie van de CRA weer, met het oog op het ondersteunen van de naleving en het bijdragen aan de effectieve uitvoering van de verordening.

Dit e-zine vat de belangrijkste punten uit de richtlijnen samen.

De CRA is van toepassing op producten met digitale elementen die op de Europese markt worden aangeboden.

Een „product met digitale elementen” wordt ruim gedefinieerd als software of hardware en de bijbehorende oplossingen voor gegevensverwerking op afstand, met inbegrip van afzonderlijk op de markt gebrachte onderdelen, en valt binnen het toepassingsgebied van de CRA wanneer het beoogde doel of het redelijkerwijs te verwachten gebruik ervan een directe of indirecte gegevensverbinding met een apparaat of netwerk omvat.

De richtlijnen verduidelijken een aantal praktische afbakeningen:

• Software die op het apparaat van een gebruiker draait, met inbegrip van browserextensies en lokaal geïnstalleerde webapps, is een „product met digitale elementen”. Software die uitsluitend op afstand wordt gebruikt, zoals de meeste websites en webapplicaties, valt over het algemeen buiten het toepassingsgebied, tenzij deze via gegevensverwerking op afstand een product ondersteunt dat wel onder het toepassingsgebied valt.

• Een op zichzelf staand softwareproduct wordt beschouwd als “in de handel gebracht” zodra de productiefase is voltooid en het voor het eerst wordt geleverd voor distributie of gebruik in de EU in het kader van een commerciële activiteit. Alle exemplaren van diezelfde versie worden behandeld alsof ze gelijktijdig in de handel zijn gebracht, ongeacht wanneer individuele gebruikers ze verkrijgen.

• Latere softwareversies leiden alleen tot een nieuwe in de handel brenging wanneer zij een „wezenlijke wijziging“ vormen. Routine-updates die niet aan die drempel voldoen, laten de oorspronkelijke datum van in de handel brengen ongewijzigd.

• Wanneer hardware is ontworpen om samen te werken met specifieke software van dezelfde fabrikant om de beoogde functie uit te voeren, vormen de hardware en de software samen één enkel product met digitale elementen, zelfs als de software via een afzonderlijk kanaal, zoals een app-winkel, wordt verkregen.

• De vereiste inzake gegevensverbinding van de CRA wordt niet geactiveerd door de loutere aanwezigheid van elektronica: een echte „gegevensverbinding“ vereist dat digitaal gecodeerde informatie opzettelijk door een verzender wordt gegenereerd en door een ontvanger kan worden gedecodeerd. Signalen die uitsluitend worden gebruikt om een functie te activeren of van stroom te voorzien, zonder gecodeerde informatie over te dragen, vallen buiten het toepassingsgebied. Met andere woorden, als het product gegevens kan verzenden, ontvangen of uitwisselen met een ander apparaat of netwerk, valt het binnen het toepassingsgebied van de CRA.

In de richtlijnen wordt verduidelijkt dat FOSS over het algemeen alleen onder de verplichtingen voor fabrikanten valt wanneer het in het kader van een commerciële activiteit beschikbaar wordt gesteld. Het louter publiceren of delen van open-sourcecode houdt op zichzelf nog geen het in de handel brengen van software in. Individuele bijdragers zijn over het algemeen niet verantwoordelijk voor de naleving van de CRA. Rechtspersonen die niet-commerciële FOSS ondersteunen, kunnen in aanmerking komen als beheerders van open-source software en zijn dan uitsluitend onderworpen aan de beperkte verplichtingen van artikel 24 die op deze beheerders van toepassing zijn. Fabrikanten die FOSS van derden in commerciële producten integreren, blijven volledig verantwoordelijk voor het waarborgen van de naleving van de CRA, met inbegrip van de vereisten inzake kwetsbaarheidsbeheer en zorgvuldigheid.

Fabrikanten moeten een ondersteuningsperiode vaststellen die aansluit bij de verwachte levensduur van het product en ervoor zorgen dat kwetsbaarheden gedurende die periode worden verholpen. De door de CRA vastgestelde minimumtermijn van vijf jaar is slechts een waarborg, geen standaardregel. Producten met een langere levensduur vereisen langere ondersteuning. Elke substantieel gewijzigde softwareversie moet een eigen ondersteuningsperiode hebben, tenzij de wijziging geen invloed heeft op de factoren die bepalend zijn voor de verwachte levensduur van het product. Fabrikanten mogen het verhelpen van kwetsbaarheden beperken tot de nieuwste versie als gebruikers kosteloos kunnen upgraden, zonder dat dit extra kosten met zich meebrengt, zoals verplichte hardwareaankopen.

Op grond van de CRA gelden voor producten die als „belangrijk“ of „cruciaal“ zijn ingedeeld, strengere eisen op het gebied van conformiteitsbeoordeling. De classificatie is gebaseerd op de kernfunctionaliteit van het product, dat wil zeggen de kenmerken die essentieel zijn voor het beoogde doel, en niet op bijkomende kenmerken of ingebouwde componenten. Fabrikanten kunnen strengere eisen niet omzeilen door de mogelijkheden van een product verkeerd voor te stellen. Hoewel voor sommige belangrijke producten met een lager risico (klasse I) zelfbeoordeling volstaat, is voor belangrijke producten met een hoger risico (klasse II) en kritieke producten over het algemeen een onafhankelijke conformiteitsbeoordeling door een derde partij vereist.

De richtlijnen maken een onderscheid tussen de cyberbeveiligingsrisicobeoordeling van het product zelf en de zorgvuldigheidsverplichting met betrekking tot geïntegreerde componenten van derden. Er wordt benadrukt dat resterende cyberbeveiligingsrisico’s niet uitsluitend kunnen worden gerechtvaardigd op basis van kosten, commerciële overwegingen of de risicobereidheid van een fabrikant, noch mogen worden afgewenteld op gebruikers of derden. De richtlijnen staan fabrikanten ook toe om voor productfamilies die dezelfde architectuur, hetzelfde beveiligingsontwerp en hetzelfde risicoprofiel delen, gebruik te maken van één enkele risicobeoordeling, één technisch dossier, één conformiteitsbeoordeling en één conformiteitsverklaring, mits verschillen tussen de varianten geen invloed hebben op hun cyberbeveiligingskenmerken.

In de richtlijnen wordt bevestigd dat producten die zijn ontworpen voordat de CRA op 11 december 2027 van kracht wordt, niet automatisch opnieuw moeten worden ontworpen. Fabrikanten moeten nog steeds een cyberbeveiligingsrisicobeoordeling uitvoeren en mogen vertrouwen op bestaande beveiligingsmaatregelen wanneer deze de geïdentificeerde risico’s adequaat aanpakken. Zij blijven echter onderworpen aan alle andere CRA-verplichtingen, waaronder conformiteitsbeoordeling, het opstellen van een EU-conformiteitsverklaring en CE-markering voordat het product in de handel wordt gebracht.

Aangezien de rapportageverplichtingen op 11 september 2026 ingaan en volledige naleving uiterlijk op 11 december 2027 vereist is, moeten bedrijven nu actie ondernemen: vaststellen welke producten onder het toepassingsgebied van de CRA vallen, hun risicoclassificatie bepalen en eventuele hiaten in bestaande risicobeoordelingen en documentatie aanpakken.