---
title: "Cyber Resilience Act: wat het betekent voor jouw software | Coding Agency"
description: "De EU Cyber Resilience Act verplicht fabrikanten van digitale producten om security in te bouwen vanaf het ontwerp. Sinds 11 september 2026 gelden de eerste meldplichten. Wat betekent dat voor jouw software?"
url: https://coding.agency/kennisbank/cyber-resilience-act-software
source: Coding Agency (https://coding.agency)
language: nl
---

Juridisch  9 min leestijd  

#  Cyber Resilience Act: wat het betekent voor jouw software. 

De EU Cyber Resilience Act verplicht fabrikanten van digitale producten om security in te bouwen vanaf het ontwerp. Sinds 11 september 2026 gelden de eerste meldplichten. Wat betekent dat voor jouw software?

 [ Jasper Koers ](http://coding-agency-coding-agency-website-production.brewless.dev/over/jasper-koers) · 30 mrt. 2026 ·  Laatst bijgewerkt 14 sep. 2026  

##  In het kort 

- De CRA verplicht security-by-design voor alle digitale producten op de Europese markt
- Meldplicht voor actief misbruikte kwetsbaarheden geldt sinds 11 september 2026
- Volledige compliance inclusief CE-markering verplicht vanaf 11 december 2027
- Boetes tot 15 miljoen euro of 2,5% van de wereldwijde jaaromzet
- De CRA gaat over je product, NIS2 over je organisatie — je hebt met beide te maken

## Wat is de Cyber Resilience Act?

De [Cyber Resilience Act (CRA)](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act) is een Europese verordening die eisen stelt aan de cybersecurity van producten met digitale elementen. Denk aan software, hardware, IoT-apparaten — maar ook aan SaaS-producten en apps die op de Europese markt worden aangeboden.

Waar de [NIS2-richtlijn](http://coding-agency-coding-agency-website-production.brewless.dev/kennisbank/nis2-en-softwareontwikkeling) zich richt op organisaties en hun beveiligingsbeleid, gaat de CRA over de producten zelf. Het idee is simpel: als je iets digitaals verkoopt in de EU, dan moet het veilig zijn — en dat moet je kunnen aantonen.

De verordening is op [10 december 2024 in werking getreden](https://eur-lex.europa.eu/eli/reg/2024/2847). De eerste verplichtingen — het melden van actief misbruikte kwetsbaarheden — gelden sinds 11 september 2026. De volledige eisen, inclusief CE-markering, gelden vanaf 11 december 2027.

## Waarom de CRA er is

De afgelopen jaren zijn cyberaanvallen op softwareproducten explosief gestegen. Supply chain attacks, kwetsbaarheden in veelgebruikte libraries, ransomware via onveilige IoT-apparaten — de schade loopt in de miljarden. Tot nu toe was er geen Europese wetgeving die eisen stelde aan de beveiliging van digitale producten zelf. Dat verandert met de CRA.

De Europese Commissie wil af van de situatie waarin fabrikanten digitale producten op de markt brengen zonder minimale beveiligingsgaranties. De CRA verplicht een [security-by-design aanpak](https://www.blazeinfosec.com/post/eu-cra-cyber-resilience-act/) gedurende de hele levenscyclus van het product.

## Wat valt onder de CRA?

De scope is breed. De CRA geldt voor alle "producten met digitale elementen" die op de EU-markt worden geplaatst. Dat omvat:

- **Software** — standalone applicaties, firmware, besturingssystemen
- **Hardware met software** — routers, smart home-apparaten, industriële controllers
- **SaaS-producten** — voor zover ze data verwerken als onderdeel van een product met digitale elementen
- **Open-source software** — alleen als deze commercieel wordt geëxploiteerd

Niet-commerciële open-source software die door vrijwilligers wordt ontwikkeld is [expliciet uitgezonderd](https://openssf.org/public-policy/eu-cyber-resilience-act/). Maar zodra er een commercieel model omheen zit — support, hosting, premium features — kan de uitzondering vervallen.

> De CRA geldt voor alles wat digitaal is én commercieel op de EU-markt komt. Van firmware tot SaaS.

## De drie pijlers van de CRA

### 1. Security-by-design

Producten moeten vanaf het ontwerp veilig zijn. Dat betekent niet alleen "geen bekende kwetsbaarheden bij release", maar een structurele aanpak:

- Risicoanalyse uitvoeren voor elke release
- Minimale aanvalsoppervlakte als ontwerpprincipe
- Veilige standaardinstellingen — geen default wachtwoorden, geen onnodige open poorten
- Bescherming van opgeslagen en verzonden data
- Beperking van toegang tot functionaliteit en data op basis van het least privilege-principe

### 2. Vulnerability management

Fabrikanten worden verplicht om kwetsbaarheden actief te beheren gedurende de gehele levenscyclus van het product, met een [minimum van vijf jaar](https://www.european-cyber-resilience-act.com/):

- Een gecoördineerd proces voor het ontvangen en afhandelen van kwetsbaarheidsrapporten
- Beveiligingsupdates tijdig en kosteloos beschikbaar stellen
- Een Software Bill of Materials (SBOM) bijhouden — een inventarisatie van alle componenten in je product
- Actief monitoren op nieuwe kwetsbaarheden in gebruikte dependencies

### 3. Transparantie en documentatie

Je moet kunnen aantonen dat je product aan de eisen voldoet. Dat vraagt om:

- Technische documentatie van het security-ontwerp
- Conformiteitsverklaring (EU Declaration of Conformity)
- CE-markering op het product
- Duidelijke gebruikersinstructies over veilig gebruik en updates

## Meldplicht sinds 11 september 2026

De eerste concrete verplichting is de meldplicht. Sinds [11 september 2026](https://www.crowell.com/en/insights/client-alerts/its-live-the-cyber-resilience-act-reporting-is-mandatory-as-of-today-11-september-2026) moeten fabrikanten actief misbruikte kwetsbaarheden en ernstige beveiligingsincidenten melden bij ENISA (het Europese cybersecurity-agentschap) via het [Single Reporting Platform (SRP)](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp):

- **Binnen 24 uur** — een eerste melding (early warning)
- **Binnen 72 uur** — aanvullende informatie over de aard en impact
- **Binnen 14 dagen** — een volledig rapport inclusief genomen maatregelen

Dit is een strakker regime dan de meeste bedrijven gewend zijn. Het vereist dat je monitoring, logging en incident response-processen op orde hebt — niet als papieren tijger, maar operationeel werkend.

## CE-markering voor software

Een opvallend onderdeel van de CRA: digitale producten krijgen een [CE-markering](https://www.onekey.com/resource/no-market-approval-without-cybersecurity-how-companies-can-successfully-implement-the-cra). Net als bij speelgoed of elektronische apparaten moet je als fabrikant aantonen dat je product voldoet aan de essentiële eisen voordat je het op de Europese markt mag brengen.

De CRA onderscheidt drie categorieën producten:

- **Standaard (niet-kritiek)** — zelfbeoordeling volstaat
- **Belangrijk (klasse I en II)** — afhankelijk van de klasse is een geharmoniseerde standaard of externe audit vereist
- **Kritiek** — verplichte beoordeling door een aangemelde instantie (notified body)

De meeste maatwerksoftware en SaaS-producten vallen in de standaardcategorie, waarbij een zelfbeoordeling volstaat. Maar dat betekent niet dat je er makkelijk van afkomt: je moet nog steeds alle documentatie en processen op orde hebben.

## Wat dit betekent voor jouw softwareproject

Als je software laat bouwen — of zelf een digitaal product ontwikkelt — raakt de CRA je op meerdere punten:

### Voor opdrachtgevers

- Stel eisen aan je softwareleverancier over security-by-design en vulnerability management
- Vraag om een SBOM van je product, zodat je weet welke componenten erin zitten
- Zorg dat je contractueel afspreekt wie verantwoordelijk is voor security-updates na oplevering
- Plan budget en capaciteit in voor de onderhoudsfase — de CRA vereist minimaal vijf jaar security-support

### Voor softwareontwikkelaars

- Integreer security in je volledige development lifecycle: ontwerp, bouw, test en onderhoud
- Automatiseer dependency scanning en kwetsbaarheidsdetectie in je CI/CD-pipeline
- Houd een SBOM bij en update deze bij elke release
- Richt een vulnerability disclosure-proces in — een kanaal waar onderzoekers kwetsbaarheden kunnen melden
- Documenteer je beveiligingsmaatregelen zodat je compliance kunt aantonen

> De CRA verplicht vijf jaar security-support na release. Dat maakt onderhoud en update-strategie onderdeel van je product, niet een afterthought.

## Boetes en handhaving

De CRA kent stevige sancties. Bij niet-naleving kunnen boetes oplopen tot [15 miljoen euro of 2,5% van de wereldwijde jaaromzet](https://www.armorcode.com/learning-center/eu-cyber-resilience-act-cra-requirements-guide) — afhankelijk van welk bedrag hoger is. Nationale markttoezichthouders zijn verantwoordelijk voor de handhaving en kunnen producten van de markt laten halen.

Ter vergelijking: de AVG kent boetes tot 20 miljoen euro of 4%, NIS2 tot 10 miljoen euro of 2%. De CRA zit daar precies tussenin — serieus genoeg om op de radar te staan van elke softwaremaker die in de EU opereert.

## De CRA naast NIS2 en de EU AI Act

De Europese regelgeving rond digitale producten vormt steeds meer een samenhangend geheel:

- **[NIS2](http://coding-agency-coding-agency-website-production.brewless.dev/kennisbank/nis2-en-softwareontwikkeling)** — eisen aan organisaties die essentiële diensten leveren
- **CRA** — eisen aan de producten die zij gebruiken en verkopen
- **[EU AI Act](http://coding-agency-coding-agency-website-production.brewless.dev/kennisbank/eu-ai-act-software)** — specifieke eisen voor AI-componenten in die producten

Als je software bouwt voor een klant die onder NIS2 valt, en die software bevat AI-functionaliteit, dan heb je met alle drie de regelgevingen te maken. Dat klinkt overweldigend, maar in de praktijk overlappen de eisen. Een goed security-by-design proces dekt het grootste deel van wat zowel NIS2 als de CRA verwachten.

## Hoe wij hiermee omgaan

Bij Coding Agency bouwen we software met een security-first aanpak die goed aansluit op wat de CRA vraagt:

- **Dependency scanning** — geautomatiseerde controle op bekende kwetsbaarheden in packages en libraries
- **CI/CD met security gates** — code wordt pas gedeployed als security checks slagen
- **[Security by design](http://coding-agency-coding-agency-website-production.brewless.dev/kennisbank/security-by-design-laravel)** — OWASP-richtlijnen als standaard in ons ontwikkelproces
- **Versleuteling overal** — data in transit en at rest, met gescheiden sleutelbeheer
- **Monitoring en logging** — zodat incidenten snel gedetecteerd en gemeld kunnen worden
- **Documentatie** — technische documentatie die aansluit op de CRA-eisen voor conformiteit

De CRA formaliseert wat wij als goed vakmanschap beschouwen. Het verschil is dat het nu een wettelijke verplichting wordt — met deadlines en boetes. Wie al professioneel ontwikkelt, heeft een voorsprong. Wie dat niet doet, moet nu beginnen.

## Tijdlijn: wat moet je wanneer geregeld hebben?

- **11 juni 2026** (bereikt) — [Eerste CRA-implementatiemijlpaal](https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation): lidstaten hebben notificerende autoriteiten aangewezen voor de beoordeling en aanwijzing van conformiteitsbeoordelingsinstanties.
- **11 september 2026** (bereikt) — Meldplicht voor actief misbruikte kwetsbaarheden is ingegaan. Meldingen lopen via ENISA's [Single Reporting Platform (SRP)](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp), dat [op 11 september live is gegaan](https://www.crowell.com/en/insights/client-alerts/its-live-the-cyber-resilience-act-reporting-is-mandatory-as-of-today-11-september-2026). ENISA publiceerde op [31 juli 2026 de onboarding-instructies](https://www.cyberresilienceact.eu/news/enisa-srp-step-by-step-instructions-31-july-2026.html) en op [3 augustus 2026 aanvullende richtlijnen](https://www.cyberresilienceact.eu/news/enisa-srp-guidance-update-3-august-2026.html).
- **2026–2027** — Geharmoniseerde standaarden worden gepubliceerd. Richt je conformiteitsproces alvast in, inclusief een SBOM en vulnerability management-proces.
- **11 december 2027** — Volledige CRA-compliance verplicht, inclusief CE-markering, technische documentatie en conformiteitsverklaring.

##  Veelgestelde vragen 

 Ja, als je software commercieel op de markt brengt in de EU. Interne bedrijfssoftware die niet wordt doorverkocht valt er in principe niet onder, maar SaaS-producten en producten met een digitale component wel. Laat je software bouwen voor eigen gebruik én doorverkoop, dan is de CRA relevant. 

 NIS2 richt zich op organisaties die essentiële diensten leveren en stelt eisen aan hun cybersecurity-beleid. De CRA richt zich op de producten zelf: software en hardware met een digitale component moeten veilig ontworpen, onderhouden en gedocumenteerd zijn. Kort gezegd: NIS2 gaat over jouw organisatie, de CRA over wat je maakt. 

 De meldplicht voor kwetsbaarheden geldt sinds 11 september 2026. De volledige verplichtingen — inclusief CE-markering en technische documentatie — gelden vanaf 11 december 2027. Begin nu met voorbereiden, want de eisen raken je hele ontwikkelproces. 

 Gerelateerde expertise — Maatwerk Software

 **Maatwerk software laten maken?** Bekijk onze aanpak, werkwijze en referentieprojecten. Vanaf € 3.000, 16+ jaar ervaring, 150+ projecten opgeleverd.

 [ Bekijk onze aanpak ](http://coding-agency-coding-agency-website-production.brewless.dev/expertises/maatwerk-software-laten-maken) [ Gratis prijsindicatie ](http://coding-agency-coding-agency-website-production.brewless.dev/prijsindicatie) 

 Onderwerpen CRA Security EU Compliance CE-markering 

##  Gerelateerde artikelen 

 [ 16 feb. 2026 

 Juridisch 

###  NIS2 &amp; softwareontwikkeling 

 De Europese NIS2-richtlijn stelt strengere eisen aan cybersecurity. Wat betekent dat concreet voor jouw software, je leveranciers en je ontw...

 ](http://coding-agency-coding-agency-website-production.brewless.dev/kennisbank/nis2-en-softwareontwikkeling) [ 1 nov. 2024 

 Architectuur 

###  Security by design in Laravel 

 Waarom beveiliging geen feature is die je later toevoegt, maar een ontwerpprincipe dat je vanaf het eerste commit doorvoert. Over threat mod...

 ](http://coding-agency-coding-agency-website-production.brewless.dev/kennisbank/security-by-design-laravel) [ 25 mrt. 2026 

 Juridisch 

###  EU AI Act: wat betekent het voor jouw software? 

 De Europese AI-verordening is een feit. Wat moet je weten als je AI inzet in je bedrijfssoftware, en hoe zorg je dat je compliant bent?

 ](http://coding-agency-coding-agency-website-production.brewless.dev/kennisbank/eu-ai-act-software) 

##  Hulp nodig? 

Vragen over dit onderwerp? Laten we het erover hebben.

 [ Neem contact op ](http://coding-agency-coding-agency-website-production.brewless.dev/contact)

---
*Bron: [Coding Agency](https://coding.agency/kennisbank/cyber-resilience-act-software)*