Wat is de Cyber Resilience Act?
De Cyber Resilience Act (CRA) 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 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. De eerste verplichtingen — het melden van actief misbruikte kwetsbaarheden — gelden al vanaf 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 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. 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:
- 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 vanaf september 2026
De eerste concrete verplichting die ingaat, is de meldplicht. Vanaf 11 september 2026 moeten fabrikanten actief misbruikte kwetsbaarheden en ernstige beveiligingsincidenten melden bij ENISA (het Europese cybersecurity-agentschap):
- 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. 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 — 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 — eisen aan organisaties die essentiële diensten leveren
- CRA — eisen aan de producten die zij gebruiken en verkopen
- EU AI Act — 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 — 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?
- Nu — Q2 2026 — Inventariseer of je producten onder de CRA vallen. Begin met een SBOM en vulnerability management-proces.
- 11 september 2026 — Meldplicht voor actief misbruikte kwetsbaarheden gaat in. Je moet incidenten binnen 24 uur kunnen melden.
- 2026–2027 — Geharmoniseerde standaarden worden gepubliceerd. Richt je conformiteitsproces alvast in.
- 11 december 2027 — Volledige CRA-compliance verplicht, inclusief CE-markering, technische documentatie en conformiteitsverklaring.
