Cyber Resilience Act.
Producten met digitale elementen veilig ontwikkelen, kwetsbaarheden behandelen en het passende conformiteitsbewijs voorbereiden.
- Verordening (EU) 2024/2847
- Door Derya Altinay
- Stand: 22-10-2026
- Leestijd: 7 min.
Kort antwoord.
De Cyber Resilience Act is de EU-verordening voor cyberbeveiliging van producten met digitale elementen die eronder vallen. Fabrikanten dragen verantwoordelijkheid voor beveiliging tijdens ontwikkeling, beschikbaarstelling en ondersteuning. De meldplichten voor fabrikanten gelden sinds 11 september 2026; de algemene productverplichtingen vanaf 11 december 2027. De grondslag is Verordening (EU) 2024/2847.
Cyber Resilience Act en CRA-termijnen.
De Cyber Resilience Act, kortweg CRA of cyberweerbaarheidsverordening, regelt de cyberbeveiliging van producten. Verordening (EU) 2024/2847 verbindt ontwerpeisen met verplichtingen tijdens de productlevenscyclus. Het onderwerp is het concrete product, inclusief relevante componenten en bijbehorende gegevensverwerking op afstand. Een organisatiebreed beveiligingsprogramma kan dit werk ondersteunen, maar beantwoordt de productspecifieke vragen niet alleen.
De CRA-termijnen gelden gefaseerd. Volgens Art. 71 lid 2 CRA beginnen de algemene eisen op 11 december 2027; meldingen door fabrikanten volgens Art. 14 gelden al sinds 11 september 2026. Hoofdstuk IV over de aanmelding van conformiteitsbeoordelingsinstanties geldt sinds 11 juni 2026. Deze institutionele datum is geen vervroegde algemene CE-deadline voor alle softwareproducten.
Oudere producten zijn niet algemeen uitgezonderd van meldingen door fabrikanten. Art. 69 leden 2 en 3 CRA maakt onderscheid tussen de overgangsregels voor productconformiteit en meldingen. De Commissierichtsnoeren C(2026) 5252, paragraaf 9.1, lichten dit onderscheid ook toe voor producten die vóór december 2027 in de handel zijn gebracht. De richtsnoeren zijn een niet-bindend interpretatiehulpmiddel; de verordening blijft bepalend.
Welke producten en ondernemingen onder de CRA vallen.
De CRA betreft hardware- en softwareproducten die eronder vallen, op de EU-markt worden aangeboden en een directe of indirecte gegevensverbinding met een apparaat of netwerk voorzien. Art. 2 en 3 CRA bepalen het toepassingsgebied en de begrippen. Daaronder kunnen zelfstandig aangeboden componenten vallen. Toets de werkelijke functie en de wettelijke uitzonderingen voordat u het hele portfolio op dezelfde manier classificeert.
De rol van de onderneming bepaalt haar verplichtingen. Fabrikanten, importeurs en distributeurs hebben verschillende taken; de fabrikantenrol kan ook relevant zijn bij het op de markt brengen onder eigen merk. Bij opensourcesoftware moeten commerciële beschikbaarstelling, bijdragen van individuele personen en de bijzondere rol van de opensourcesoftwaresteward worden onderscheiden. Een vrije licentie stelt de fabrikant van een commercieel product niet algemeen vrij van zijn verantwoordelijkheid.
Een SaaS-dienst valt niet alleen op grond van de verkoopbenaming binnen of buiten de CRA. Productgrens en bijbehorende gegevensverwerking op afstand zijn bepalend. De Commissierichtsnoeren, paragrafen 2 en 8, onderscheiden softwareproducten van op afstand geleverde diensten. Leg de onderbouwing voor de concrete architectuur vast; een algemene uitspraak over alle cloudaanbiedingen zou te ruim zijn.
De hoofdgebieden van de CRA-eisen.
De CRA-eisen verbinden risicogestuurde productbeveiliging met doorlopende verantwoordelijkheid. Art. 13 en Bijlage I CRA vormen de basis van de productverplichtingen; Art. 14 regelt de eerder geldende meldingen door fabrikanten. De volgende gebieden bieden oriëntatie zonder de afzonderlijke wettelijke eisen te vervangen.
Product en risico’s begrijpen.
Een cyberbeveiligingsrisicobeoordeling draagt de beveiligingsbeslissingen gedurende de levenscyclus. Fabrikanten houden rekening met het beoogde en redelijkerwijs voorzienbare gebruik. Beschrijf praktisch welke functies, interfaces en afhankelijkheden het product heeft en welke gevolgen een beveiligingsprobleem voor de gebruikers kan hebben.
Beveiliging in het product opnemen.
Veilig ontwerp en veilige standaardinstellingen horen bij elkaar. Bijlage I CRA omvat producteigenschappen zoals toegangsbeveiliging, gegevensbescherming en het beperken van aanvalsoppervlakken. Een achteraf opgestelde richtlijn kan technische eigenschappen niet vervangen; ontwikkelingsbeslissingen en de toetsing daarvan moeten aansluiten bij de risicobeoordeling.
Componenten verantwoord integreren.
Geïntegreerde componenten blijven deel van de productbeoordeling. Fabrikanten hebben navolgbare informatie nodig over wat zij leveren en hoe kwetsbaarheden in afhankelijkheden hun product raken. De Commissie beschrijft expliciet de vereiste zorgvuldigheid ten aanzien van componenten van derden; alleen het doorgeven van leveranciersinformatie beantwoordt niet elke productvraag.
Kwetsbaarheden en updates behandelen.
Het behandelen van kwetsbaarheden is een doorlopende taak tijdens de relevante ondersteuningsperiode. Daarbij horen bereikbare meldkanalen, beoordeling, herstel en veilige levering van beveiligingsupdates. Maak onderscheid tussen de technische behandeling van een bevinding en de juridische beoordeling of een actief uitgebuite kwetsbaarheid of ernstig incident meldplichtig is.
Ondersteuning en gebruikersinformatie vastleggen.
De ondersteuningsperiode hangt af van de criteria van Art. 13 lid 8 CRA en het verwachte gebruik. In beginsel is minimaal vijf jaar voorzien; bij een korter verwacht gebruik geldt die gebruiksduur, bij een langer verwacht gebruik kan een langere periode nodig zijn. De Commissierichtsnoeren, paragraaf 5, lichten expliciet toe dat vijf jaar geen algemeen maximum is.
Meldingen door fabrikanten mogelijk maken.
Art. 14 CRA onderscheidt actief uitgebuite kwetsbaarheden van ernstige beveiligingsincidenten. Voor fabrikanten gelden gefaseerde meldingen: onverwijld en uiterlijk binnen 24 uur een vroege waarschuwing en binnen 72 uur verdere gegevens na kennisneming. De termijnen voor het eindverslag verschillen per aanleiding. Alleen een scannerbevinding is daarom noch automatisch een verplichte melding, noch voldoende reden om het voorval af te sluiten.
Conformiteit en documentatie voorbereiden.
Technische documentatie en conformiteitsbeoordeling moeten het aangeboden product verklaren. Art. 32 CRA en de productcategorie bepalen de toegestane procedure. Leg de gekozen beoordelingsgrondslag samen met de productversie vast; een algemene documentenverzameling zonder navolgbare relatie met de onderzochte uitvoering volstaat niet als praktische bewijsstrategie.
CRA-implementatie als productproces.
Portfolio en rollen afbakenen.
Breng als praktische eerste stap de aangeboden producten, hun relevante functies, de verantwoordelijke rechtspersoon en de rol in elk verkoopkanaal in kaart.
Toepassingsfasen onderscheiden.
Maak onderscheid tussen de reeds geldende gereedheid voor meldingen door fabrikanten en de voorbereiding van de algemene productconformiteit en toets overgangsregels voor bestaande producten.
Risico’s vertalen naar productbeslissingen.
Verbind de risicobeoordeling met ontwerp, componentselectie en toetsbare beveiligingscriteria voor ontwikkeling en vrijgave.
Meldkanalen oefenen.
Benoem verantwoordelijke personen en vervangers en oefen beoordeling, escalatie en indiening met onvolledige informatie binnen de toepasselijke termijnen.
Ondersteuning en bewijstraject vastleggen.
Plan het onderhoud van ondersteunde productversies en bepaal aan de hand van de categorie welke conformiteitsbeoordeling en technische documentatie nodig worden.
CE-markering van software en productbewijs.
Het CRA-bewijs is een productgebonden conformiteitsbeoordeling. De Commissie licht bij Art. 32 CRA toe dat voor de standaardcategorie een interne beoordeling mogelijk is. Voor bepaalde belangrijke of kritieke producten gelden strengere procedures met een aangemelde instantie of andere toegestane bewijstrajecten. De werkelijke productfunctie bepaalt de categorie; een commerciële productnaam volstaat daarvoor niet.
De EU-conformiteitsverklaring en CE-markering volgen de toepasselijke procedure. Ze vormen geen algemeen certificaat voor de hele onderneming en beloven niet dat een product nooit een kwetsbaarheid zal hebben. Een uniforme certificaatlooptijd is daarom geen passende beschrijving van de CRA: documentatie, kwetsbaarheidsafhandeling en toepasselijke verplichtingen moeten over de relevante levenscyclus worden bekeken.
Andere frameworks en zelfstandige verplichtingen.
ISO 27001 organiseert een managementsysteem voor informatiebeveiliging; een bijbehorend certificaat bevestigt niet op zichzelf de CRA-conformiteit van een product. NIS2 kijkt naar instellingen die eronder vallen en hun beveiligingsorganisatie. De AVG beschermt persoonsgegevens, waardoor een productincident aanvullende privacyvragen kan oproepen. Verwante werkprocessen kunnen worden gecoördineerd; de juridische aanleidingen en bewijsvoering moeten afzonderlijk worden getoetst.
In Secani.
Secani bevat een redactionele CRA-werkcatalogus met bronnen, toetsvragen en bewijsvoorbeelden. Het ondernemingsprofiel legt onder meer rollen en de beoordelingsdatum vast; onduidelijke voorwaarden blijven zichtbaar als te toetsen punten. Het hulpmiddel ondersteunt de organisatie van de toetsing, maar bevestigt noch de juridische classificatie, noch de conformiteit van een product.
Begin met een afgebakend product.
Kies een concreet product en bepaal eerst de grens, de verantwoordelijke rechtspersoon en de bevoegde personen voor beveiligingsmeldingen. Toets vervolgens welke huidige en komende verplichtingen dit product betreffen. Deze start maakt de voorbereiding overzichtelijk en voorkomt dat een algemeen complianceproject de reeds vereiste meldgereedheid aan het zicht onttrekt.
Bronnen.
- Verordening (EU) 2024/2847 – Cyber Resilience Act
- Europese Commissie: Cyber Resilience Act en toepassingsdata
- Europese Commissie: samenvatting van de rechtshandeling
- Europese Commissie: fabrikantenverplichtingen
- Europese Commissie: conformiteitsbeoordeling
- Europese Commissie: CRA en open source
- Europese Commissie: richtsnoeren C(2026) 5252 met bijlage
Veelgestelde vragen.
Ja, voor fabrikanten die eronder vallen gelden de meldingen volgens Art. 14 CRA sinds 11 september 2026. De algemene productverplichtingen beginnen op 11 december 2027; bijzondere rollen en overgangsregels moeten afzonderlijk worden getoetst.
Nee, de benaming SaaS bepaalt het toepassingsgebied niet. Toets het softwareproduct, de functies en de bijbehorende gegevensverwerking op afstand aan de hand van de concrete architectuur.
Nee, de bijzondere behandeling van voorafgaande opensourcebijdragen stelt de commerciële productfabrikant niet algemeen vrij van zijn verplichtingen. De fabrikantenrol en een mogelijke stewardrol moeten worden onderscheiden.
Nee, een ISO 27001-certificaat betreft een afgebakend managementsysteem. De CRA vereist een afzonderlijke productbeoordeling en het toepasselijke conformiteitsbewijs.
Productbeveiliging navolgbaar organiseren.
Met Secani CRA-eisen en de toetsing daarvan gestructureerd behandelen.
Deze pagina licht de Cyber Resilience Act op algemeen niveau toe en vervangt geen juridische toetsing van het afzonderlijke product. De geldende rechtshandelingen zijn bepalend.