Leestijd: 6 minuten
Vanaf september 2026 verandert alles voor bedrijven die software ontwikkelen. De Europese Cyber Resilience Act (CRA) dwingt fabrikanten om cybersecurity niet langer als afterthought te behandelen, maar als voorwaarde voor markttoegang. Of u nu een mobiele app bouwt, firmware ontwikkelt of een SaaS-platform beheert met een client-component: de kans is groot dat deze wetgeving ook uw producten raakt.
Waarom de CRA er komt
De Europese Commissie heeft vastgesteld dat de markt onvoldoende prikkels bood om te investeren in veilige software. Producten werden gelanceerd met standaardwachtwoorden, bekende kwetsbaarheden en zonder mechanisme voor beveiligingsupdates. Incidenten zoals de Log4j-kwetsbaarheid en de SolarWinds-aanval toonden pijnlijk aan dat de veiligheid van de digitale keten slechts zo sterk is als de zwakste schakel.
De CRA is het antwoord hierop. Het stelt minimumeisen aan alle digitale producten op de EU-markt en creëert een gelijk speelveld. Bedrijven die investeren in security worden niet langer weggeconcurreerd door aanbieders van onveilige, goedkope alternatieven.
CRA versus NIS2: Wat is het verschil?
Een veelvoorkomende vraag bij onze klanten: “Vallen wij onder de CRA of onder NIS2?” Het antwoord is vaak: beide, maar om verschillende redenen.
NIS2 richt zich op de cyberweerbaarheid van organisaties die essentiële of belangrijke diensten leveren. De verplichtingen rusten op de entiteit als geheel. De CRA daarentegen is productwetgeving. Het richt zich op de cyberveiligheid van het product zelf en de levenscyclus daarvan. De verplichtingen rusten op de fabrikant van dat specifieke product.
Concreet: een bedrijf dat een HR-platform aanbiedt via de browser valt onder NIS2 als cloudserviceprovider. Lanceren ze ook een mobiele app waarmee werknemers kunnen inklokken? Dan valt die app als product onder de CRA. Compliance met de ene wet betekent niet automatisch compliance met de andere.
De Tijdlijn: Waarom 2026 het keerpunt is
De volledige CRA-handhaving start pas in december 2027. Toch is september 2026 het echte “point of no return”. Vanaf dat moment treden de verplichtingen rondom de rapportage van actief uitgebuite kwetsbaarheden in werking.
Dit betekent concreet dat fabrikanten binnen 24 uur melding moeten maken bij de nationale CSIRT of ENISA zodra zij kennis krijgen van een kwetsbaarheid die actief wordt misbruikt. Binnen 72 uur moet een uitgebreider rapport volgen met een initiële beoordeling van de ernst en impact. En binnen 14 dagen na het beschikbaar stellen van een patch volgt een eindrapport.
Wachten tot 2027 is dus geen optie. Uw incident response processen en kwetsbaarheidsbeheer moeten vóór september 2026 operationeel zijn.
Valt SaaS onder de CRA?
Dit is waar het interessant wordt. De aanname dat “pure SaaS” buiten de CRA valt, klopt in theorie. Maar de praktijk is complexer.
De CRA introduceert het concept van “remote data processing solutions”: cloudcomponenten die essentieel zijn voor het functioneren van een product met digitale elementen. Zodra een SaaS-dienst fungeert als backend voor een verbonden apparaat, of wanneer er sprake is van client-side componenten zoals mobiele apps, verschuift de juridische status.
Denk aan een slimme thermostaat die data naar een cloud-backend stuurt. Zonder de cloud werkt de “slimme” functie niet. De fabrikant moet zorgen dat zowel de thermostaat als de cloud-software aan de CRA-eisen voldoen. Hetzelfde geldt voor een mobiele app die verbindt met een SaaS-platform: de app zelf is een product en valt onder de CRA.
Security by Design: De nieuwe standaard
De kern van de CRA is de verschuiving van reactieve naar proactieve beveiliging. Annex I van de verordening bevat de essentiële cybersecurity-eisen waaraan elk product moet voldoen. De belangrijkste punten zijn de afwezigheid van bekende uitbuitbare kwetsbaarheden bij lancering, veilige standaardinstellingen (geen “admin/admin” wachtwoorden meer), bescherming tegen ongeautoriseerde toegang, encryptie van data in rust en in transit, en mechanismen om te verifiëren dat updates niet zijn gemanipuleerd.
Voor ontwikkelteams betekent dit dat security een integraal onderdeel wordt van elke fase. Threat modeling in de designfase, secure coding practices tijdens ontwikkeling, geautomatiseerde security testing in de CI/CD-pipeline, en beveiligde update-mechanismen bij deployment.
De Software Bill of Materials wordt onmisbaar
Een Software Bill of Materials (SBOM) is een formele, machinaal leesbare inventaris van alle componenten waaruit software is opgebouwd. Wanneer een nieuwe kwetsbaarheid wordt ontdekt in een veelgebruikte bibliotheek, stelt de SBOM organisaties in staat om binnen seconden te zien welke producten geraakt zijn.
Softwarebouwers moeten automatisch een SBOM genereren bij elke build, standaarden gebruiken zoals CycloneDX of SPDX, en de SBOM dynamisch up-to-date houden.
De CE-markering voor software
Ja, u leest het goed. Software krijgt een CE-markering, net als speelgoed of elektrische apparaten. Bij software wordt deze markering digitaal aangebracht: in het “About” scherm, op de downloadpagina, of in de installatiehandleiding.
De classificatie van uw product bepaalt de zwaarte van het toetsingsproces. Ongeveer 90% van alle producten valt in de standaardcategorie en kan volstaan met zelfevaluatie. Producten met een security-functie zoals browsers, password managers of VPN-clients vallen in Klasse I. Infrastructuur-software zoals firewalls of container runtimes valt in de zwaardere Klasse II en vereist een externe audit.
Wat nu te doen?
De eerste stap is een scope-bepaling. Analyseer uw productportfolio en identificeer welke software een product is onder de CRA en welke een dienst onder NIS2. Bepaal vervolgens de classificatie van elk CRA-product aan de hand van Annex III.
Richt vóór september 2026 uw incident response proces in voor de 24-uurs melding. Publiceer een beleid voor gecoördineerde openbaarmaking van kwetsbaarheden op uw website. En begin met het opbouwen van technische dossiers voor bestaande producten.
De bedrijven die nu proactief hun processen op orde brengen, zullen de CRA ervaren als een kwaliteitsimpuls. Zij die wachten, riskeren in september 2026 juridische blootstelling en in 2027 een handelsverbod.
Veelgestelde vragen over de Cyber Resilience Act
Wanneer treedt de CRA in werking?
De CRA is op 10 december 2024 in werking getreden. De meldplicht voor actief uitgebuite kwetsbaarheden geldt vanaf 11 september 2026. De volledige toepassing, inclusief CE-markering, start op 11 december 2027.
Valt mijn SaaS-product onder de CRA?
Zuivere browser-only SaaS valt onder NIS2, niet onder de CRA. Maar zodra u een mobiele app, desktop client of andere geïnstalleerde software aanbiedt die verbindt met uw SaaS-backend, valt dat component wél onder de CRA.
Wat gebeurt er als ik niet voldoe aan de CRA?
Na december 2027 mogen producten die niet voldoen aan de CRA-eisen niet meer op de EU-markt worden gebracht. Daarnaast kunnen fabrikanten vanaf september 2026 al aansprakelijk worden gesteld voor het niet melden van actief uitgebuite kwetsbaarheden.
Moet ik een externe audit laten uitvoeren?
Dat hangt af van de classificatie van uw product. De meeste software valt in de standaardcategorie en kan volstaan met zelfevaluatie. Security-gerelateerde software zoals password managers of VPN-clients valt in Klasse I en vereist mogelijk een externe audit. Infrastructuur-software zoals firewalls valt in Klasse II en vereist verplicht een externe audit.
Wat is een SBOM en waarom heb ik die nodig?
Een Software Bill of Materials is een inventaris van alle componenten in uw software. De CRA vereist transparantie in de supply chain. Met een SBOM kunt u snel identificeren of uw producten geraakt zijn wanneer een kwetsbaarheid wordt ontdekt in een veelgebruikte bibliotheek.
Valt open source software onder de CRA?
Niet-commerciële open source projecten zijn uitgesloten. Maar zodra u open source componenten integreert in een commercieel product, wordt u als fabrikant verantwoordelijk voor de conformiteit van die componenten.
Hulp nodig bij uw CRA-voorbereiding?
De Cyber Resilience Act vraagt om een combinatie van technische expertise en procesmatige borging. Bij Cyberplan helpen we softwarebedrijven met gap-analyses, het inrichten van vulnerability management processen en het opzetten van Security by Design binnen de ontwikkelcyclus.
Plan een vrijblijvend kennismakingsgesprek →
Dit artikel is bedoeld als algemene informatie en vormt geen juridisch advies. Voor specifieke vragen over de toepassing van de CRA op uw situatie raden wij aan contact op te nemen met een juridisch specialist.
