De CRA krijgt zijn instructiehandleiding: wat de Commissieleidraad voor u betekent

De Cyber Resilience Act heeft zijn tekst al sinds eind 2024. Wat ontbrak was een gebruikshandleiding. Op 3 maart 2026 publiceerde de Europese Commissie precies dat: ontwerp-Mededeling Ares(2026)2319816 — ongeveer 70 pagina's praktische leidraad over de interpretatie van de verordening.

Dit is de Article 26-leidraad waarop de industrie heeft gewacht. Dit is wat die zegt en wat die voor u betekent.

Samenvatting

• SaaS/cloudproducten vallen alleen binnen het toepassingsgebied als ze voldoen aan een strikte driedelige test voor "verwerking van gegevens op afstand" (RDPS). De meeste externe SaaS valt buiten de productgrens maar moet als component worden behandeld.
• Legacy-producten die vóór december 2027 op de markt zijn gebracht, hoeven niet opnieuw te worden ontworpen, maar fabrikanten moeten een actuele cybersecurity-risicobeoordeling uitvoeren en een Conformiteitsverklaring afgeven.
• Software-updates zijn over het algemeen geen "substantiële wijzigingen", tenzij ze nieuwe dreigingsvectoren introduceren of het beoogde doel van het product wijzigen.
• Open source-bijdragers zonder controle over releases, roadmap of bestuur zijn expliciet niet verantwoordelijk — zelfs als zij commitrechten hebben.
• Supportperioden moeten de verwachte productlevensduur weerspiegelen. Vijf jaar is een minimum, geen standaard.
• Kwetsbaarheidsmeldingen (september 2026): de 24-uur klok begint bij bekendheid, niet bij bevestiging.

Belangrijk: Deze leidraad is een ONTWERP. De feedbackperiode is open via het portaal Betere Regelgeving. De leidraad wordt definitief zodra alle EU-taalversies beschikbaar zijn.

Inleiding

Ontwerp-Mededeling Ares(2026)2319816, gedateerd 3 maart 2026, is het eerste uitgebreide leidraaddocument van de Europese Commissie over de Cyber Resilience Act. Met zo'n 70 pagina's behandelt het de vragen die compliance-teams 's nachts wakker houden: Wat telt als "verwerking van gegevens op afstand"? Moeten legacy-producten volledig opnieuw worden ontworpen? Wanneer wordt een software-update een nieuw product?

Dit artikel destilleert de negen meest impactvolle uitspraken tot praktische leidraad voor fabrikanten, importeurs en distributeurs van producten met digitale elementen.

1. SaaS en cloud: de RDPS-test

De Commissie introduceert een strikte drievoudige test om te bepalen of een cloud- of SaaS-component kwalificeert als "verwerking van gegevens op afstand" (RDPS) en daarmee binnen het conformiteitsgebied van het product valt.

flowchart TD
    A["Verwerkt de oplossing gegevens
'op afstand'?"] -->|Nee| B["Geen RDPS"]
    A -->|Ja| C["Zou het product een kernfunctie verliezen
zonder deze oplossing?"]
    C -->|Nee| D["Geen RDPS
(behandel als component,
due diligence per Art. 13(5))"]
    C -->|Ja| E["Ontworpen door of onder de
verantwoordelijkheid van de fabrikant?"]
    E -->|Nee| F["Geen RDPS
(externe SaaS = component,
due diligence per Art. 13(5))"]
    E -->|Ja| G["RDPS: binnen het
conformiteitsbeoordelingsgebied van het product"]

De leidraad illustreert dit aan de hand van vijf concrete scenario's: een bankieren-app, een slimme thermostaat, een e-Reader, een industriële robot en een cellulaire netwerkapparaat.

Belangrijk: Zelfs wanneer een clouddienst niet kwalificeert als RDPS, moet de fabrikant die nog steeds als component behandelen en due diligence in de toeleveringsketen uitvoeren conform Artikel 13(5). De beveiligingsverplichting verdwijnt niet — die verschuift van conformiteitsbeoordeling naar componentbeheer.

2. Legacy-producten

Producten die al vóór december 2027 op de EU-markt zijn gebracht, hoeven niet volledig opnieuw te worden ontworpen. Maar ze zijn evenmin vrijgesteld.

De Commissie verduidelijkt drie punten:

Geen historische reconstructie vereist. U hoeft de ontwikkelingsdocumentatie van jaren geleden niet te reconstrueren. Wat telt is een actuele cybersecurity-risicobeoordeling waaruit blijkt dat het product voldoet aan de essentiële eisen op basis van het beoogde gebruik.

Productfamilies kunnen worden gegroepeerd. Als meerdere legacy-producten dezelfde architectuur en hetzelfde risicoprofiel delen, kunt u één risicobeoordeling uitvoeren die de hele familie bestrijkt in plaats van elk SKU afzonderlijk te beoordelen.

Volledige conformiteit blijft van toepassing. Legacy-producten hebben nog steeds CE-markering, een Conformiteitsverklaring en actief kwetsbaarheidsbeheer nodig. De verlichting geldt voor de documentatiegeschiedenis, niet voor de verplichtingen zelf.

Voor een gedetailleerde uitleg van het conformiteitsbeoordelingsproces, zie onze beslissingsgids Conformiteitsbeoordeling. Voor plannen voor de supportperiode van legacy-producten, zie Plannen supportperiode.

3. Software en "oneindige kopieën"

Wanneer wordt software "op de markt gebracht"? De Commissie bevestigt: één keer. De initiële digitale distributie vormt de marktplaatsing. Latere kleine updates (bijv. van v1.0.0 naar v1.0.1) zetten de regulatoire klok niet opnieuw.

Dit geldt specifiek voor zelfstandige software die digitaal wordt gedistribueerd. Hardwareproducten met ingebedde software volgen de standaardregels voor marktplaatsing van fysieke goederen.

4. Wanneer updates "substantiële wijzigingen" worden

Dit gedeelte is het meest bruikbare deel van de gehele leidraad. De Commissie geeft concrete voorbeelden ter onderscheiding van routineupdates en wijzigingen die een nieuwe conformiteitsbeoordeling vereisen.

De Commissie stelt vier vragen voor die elke fabrikant vóór het uitbrengen van een update zou moeten stellen:

1. Introduceert de update nieuwe dreigingsvectoren?
2. Maakt ze nieuwe aanvalsscenario's mogelijk?
3. Verandert ze de kans op bestaande aanvalsscenario's?
4. Verandert ze de impact van bestaande aanvalsscenario's?

Als het antwoord op een van deze vragen "ja" is, vormt de update waarschijnlijk een substantiële wijziging die een nieuwe conformiteitsbeoordeling vereist.

5. Open source-regels

De leidraad geeft verschillende belangrijke verduidelijkingen over hoe de CRA van toepassing is op open source-software:

• Het publiceren van broncode op openbare repositories vormt geen "op de markt brengen". De CRA is van toepassing bij commerciële distributie, niet bij beschikbaarstelling van code.
• Community-editie vs. betaalde editie = verschillende producten. Als u een gratis communityversie en een betaalde commerciële versie aanbiedt, zijn alleen voor de betaalde versie fabricantsverplichtingen van toepassing.
• Donaties alleen maken FOSS niet commercieel — tenzij toegang tot de software afhankelijk is van het doneren. Vrijwillige donaties zijn expliciet uitgesloten.
• Non-profitorganisaties waarvan het overschot volledig naar non-profitdoeleinden gaat zijn vrijgesteld van fabricantsverplichtingen, zelfs als ze verdiensten genereren.
• Bijdragers zonder controle over releases, roadmap of bestuur worden NIET als fabrikanten beschouwd — zelfs als ze commitrechten hebben. De verantwoordelijkheid berust bij degene die het releaseproces beheert.
• Verplichtingen van open source-beheerders schalen mee met het niveau van verleende ondersteuning. Niet-technisch beheer draagt lichtere verplichtingen dan volledige commerciële ondersteuning.

6. Supportperiode: vijf jaar is een minimum

De Commissie maakt duidelijk dat de standaard vijfjarige supportperiode een minimum is, geen doelstelling. Producten waarvan verwacht wordt dat ze langer dan vijf jaar in gebruik blijven, moeten een evenredig langere supportperiode hebben.

De leidraad verduidelijkt ook het pad via Artikel 13(10): fabrikanten kunnen stoppen met het patchen van oudere versies als gebruikers gratis kunnen upgraden naar een ondersteunde versie. "Extra kosten" betekent in dit verband verplichte hardwareaankopen — routinetesten, herconfiguratie of implementatie-inspanning van de kant van de gebruiker tellen niet mee.

Voor gedetailleerde planningsstrategieën, zie onze gids Plannen supportperiode.

7. Risicobeoordeling: intern risicoappetijt is irrelevant

De Commissie is ondubbelzinnig: risicobeoordelingen onder de CRA moeten gebaseerd zijn op objectieve cybersecuritycriteria, niet op het interne risicoappetijt van de fabrikant. Specifiek:

• Commerciële strategie en kostenoverweging spelen geen rol in de cybersecurity-risicobeoordeling.
• U kunt cybersecurityrisico's niet via documentatie, disclaimers of servicevoorwaarden aan gebruikers overdragen.
• Als geïdentificeerde risico's niet via technische of organisatorische maatregelen kunnen worden aangepakt, moet het product mogelijk worden aangepast vóór marktplaatsing.

Dit is een significante uitspraak. Ze betekent dat een fabrikant niet bewust een product met onbeperkte cybersecurityrisico's op de markt kan brengen alleen omdat het bedrijf dat risico heeft "geaccepteerd".

8. Bekende misbruikbare kwetsbaarheden

De leidraad verduidelijkt wat "bekend" betekent in het kader van de CRA-vereiste dat producten zonder bekende misbruikbare kwetsbaarheden worden uitgebracht:

• Opgenomen in openbare databases: EU Vulnerability Database, CVE/MITRE, NVD.
• Bekendgemaakt via niet-openbare kanalen: gecoördineerde kwetsbaarheidsopenbaarmaking, intern beveiligingstesten, penetratietesten door derden.
• Breed gerapporteerd in betrouwbare mediakanalen: een grote kwetsbaarheid die breed wordt behandeld in mainstream cybersecurity-publicaties kwalificeert als "bekend".

Fabrikanten krijgen een beperkt onderzoeksvenster om te bevestigen of een gerapporteerde kwetsbaarheid daadwerkelijk van toepassing is op hun product. Maar "onderzoek" is geen mazen — de klok loopt vanaf bekendheid, en vertragingen zullen worden onderzocht.

9. Rapportageverplichtingen (september 2026)

De rapportageverplichtingen van september 2026 zijn de eerste CRA-deadline met echte handhavingstanden. De leidraad bevestigt de tijdlijnstructuur:

• 24 uur: Vroegtijdige waarschuwing aan ENISA na het zich bewust worden van actief misbruik
• 72 uur: Gedetailleerde notificatie met technische indicatoren
• 14 dagen: Eindrapport voor kwetsbaarheden / 30 dagen voor incidenten

"Bewust" betekent redelijke zekerheid na een initiële beoordeling — niet volledige forensische bevestiging. Als u geloofwaardig bewijs heeft van actief misbruik, loopt de klok.

Over gebruikersnotificatie: de Commissie bevestigt dat dit op basis van risico en proportioneel moet zijn. Er is geen verplichte openbare bekendmakingsverplichting als openbaarmaking het beveiligingsrisico zou verhogen.

Wat dit voor u betekent

Deze leidraad verandert niet wat de CRA vereist. Maar die verandert hoeveel giswerk er bij komt kijken. Fabrikanten hebben nu concrete tests (RDPS), concrete voorbeelden (substantiële wijzigingen) en concrete tijdlijnen (rapportage) om mee te werken.

Drie directe acties:

1. Voer de RDPS-test uit voor elke clouddienst waarvan uw product afhankelijk is. CRA Evidence automatiseert deze beoordeling als onderdeel van de productrisicoanalyse.
2. Beoordeel uw updateproces aan de hand van de vier substantiële-wijzigingsvragen. Bouw ze in uw releasechecklist.
3. Bereid u voor op september 2026-rapportage. Interne triageprocessen, escalatiepaden en rapportagesjablonen moeten vóór de deadline op orde zijn.

De feedbackperiode is open via het Betere Regelgeving-portaal. Als u standpunten heeft over de leidraad, is dit het moment.

Dit artikel is gebaseerd op ontwerp-Mededeling Ares(2026)2319816, gedateerd 3 maart 2026. Deze leidraad is nog niet officieel aangenomen door de Europese Commissie en wordt definitief zodra alle EU-taalversies beschikbaar zijn.