TL;DR: De Cyber Resilience Act (CRA) verplicht fabrikanten, importeurs en distributeurs van producten met digitale elementen om cybersecurity in te bouwen vanaf het ontwerp. De eerste meldplicht geldt al op 11 september 2026, volledige conformiteit op 11 december 2027. Belgische bedrijven die software of connected hardware maken, moeten nu starten met SBOM-generatie, kwetsbaarheidsbeheer en een Secure Development Lifecycle.

Maakt uw bedrijf software, IoT-apparaten of connected hardware? Dan verandert de Cyber Resilience Act de spelregels fundamenteel. Waar cybersecurity voor digitale producten jarenlang een kwestie van best practices was, maakt de EU er nu een harde voorwaarde voor markttoegang van. Vergelijkbaar met de CE-markering voor fysieke veiligheid, maar dan voor digitale beveiliging. In dit artikel leest u wat de CRA concreet inhoudt, welke deadlines eraan komen en hoe u uw bedrijf voorbereidt.

Wat is de Cyber Resilience Act?

De Cyber Resilience Act, officieel Verordening (EU) 2024/2847, is de eerste Europese wetgeving die dwingende cybersecurity-eisen stelt aan alle producten met digitale elementen op de EU-markt. De verordening werd op 20 november 2024 gepubliceerd en trad op 10 december 2024 in werking.

Het kernprincipe is security by design: fabrikanten moeten cybersecurity inbouwen vanaf de eerste ontwerpfase, niet achteraf toevoegen als optionele extra. Dat betekent dat elk product met een netwerk- of dataverbinding, van een slimme thermostaat tot een ERP-pakket, moet voldoen aan minimale beveiligingseisen voordat het op de Europese markt mag worden gebracht.

De CRA is een verordening, geen richtlijn. Dat verschil is belangrijk: een verordening geldt rechtstreeks in alle EU-lidstaten, zonder dat België de wet apart moet omzetten. Wat in de CRA staat, geldt dus direct voor uw bedrijf.

Valt uw bedrijf onder de CRA?

De CRA is van toepassing op elk bedrijf dat een “product met digitale elementen” vervaardigt, importeert of distribueert op de Europese markt. De definitie is bewust breed: het omvat elk hardware- of softwareproduct dat bedoeld is voor een directe of indirecte verbinding met een netwerk of apparaat.

In de praktijk raakt de CRA drie groepen bedrijven:

Fabrikanten dragen de zwaarste verantwoordelijkheid. Of u nu software ontwikkelt in Gent of IoT-sensoren assembleert in Antwerpen: als u het product ontwerpt of onder uw naam op de markt brengt, bent u fabrikant in de zin van de CRA. U moet het volledige conformiteitsproces doorlopen, van beveiligde ontwikkeling tot kwetsbaarheidsbeheer na lancering.

Importeurs die producten van buiten de EU op de Belgische markt brengen, moeten verifiëren dat de fabrikant de juiste procedures heeft doorlopen. Ontdekt u een kwetsbaarheid? Dan bent u verplicht dit te melden en mag u het product niet langer aanbieden.

Distributeurs controleren of het product de CE-markering draagt en of fabrikant en importeur aan hun verplichtingen hebben voldaan.

Uitzonderingen gelden voor producten die al onder specifieke sectorale wetgeving vallen, zoals medische hulpmiddelen (MDR/IVDR), producten voor de burgerluchtvaart en motorvoertuigen. Pure SaaS-oplossingen vallen in principe buiten de CRA en worden behandeld onder de NIS2-richtlijn. Let op: als uw cloudoplossing essentieel is voor het functioneren van een fysiek product, valt die software wél onder de CRA.

Open source software die niet commercieel wordt aangeboden, is uitgezonderd. Maar zodra u open source componenten integreert in een commercieel product, gelden de CRA-verplichtingen voor dat product.

Wat zijn de belangrijkste CRA-verplichtingen?

De CRA legt fabrikanten drie kernverplichtingen op die de volledige levenscyclus van een product bestrijken. Samen dwingen ze een fundamentele verschuiving af: van reactief patchen naar proactief beveiligen.

1. Security by design en secure defaults

Producten moeten worden geleverd zonder bekende exploiteerbare kwetsbaarheden. Standaardinstellingen moeten veilig zijn, inclusief het verbod op zwakke standaardwachtwoorden. De aanvalsoppervlakte moet tot een minimum worden beperkt, met sterke authenticatie en encryptie als basisvereisten.

2. Software Bill of Materials (SBOM)

Elke fabrikant moet een machineleesbare inventaris bijhouden van alle softwarecomponenten, bibliotheken en afhankelijkheden in het product. Denk aan een “ingrediëntenlijst” voor software. Wanneer een kwetsbaarheid opduikt in een externe bibliotheek, zoals destijds bij Log4j, kunt u met een actuele SBOM onmiddellijk vaststellen of uw product geraakt is. De SBOM moet bij elke update worden herzien en tien jaar worden bewaard. Internationale standaarden zoals CycloneDX en SPDX worden aanvaard als formaat.

3. Kwetsbaarheidsbeheer en beveiligingsupdates

Fabrikanten moeten gedurende de verwachte levensduur van het product, met een minimum van vijf jaar, gratis beveiligingsupdates leveren. Die updates moeten bovendien gescheiden zijn van functionele updates: gebruikers mogen niet gedwongen worden een zwaardere softwareversie te accepteren enkel om een beveiligingslek te dichten.

Wanneer gaat de CRA in? De tijdlijn

De CRA hanteert een gefaseerde inwerkingtreding. Niet alles wordt tegelijk verplicht, maar de eerste operationele deadline komt sneller dan veel bedrijven beseffen.

De datum van 11 september 2026 is cruciaal. Vanaf dat moment moet u een operationeel kanaal hebben met zowel ENISA als het Centrum voor Cybersecurity België (CCB). Uw systemen voor monitoring en detectie van kwetsbaarheden moeten dan al functioneren. Dat is over minder dan 18 maanden.

Wat is het verschil tussen de CRA en NIS2?

Veel Belgische bedrijven die al bezig zijn met NIS2-compliance vragen zich af hoe de CRA zich daartoe verhoudt. De twee vullen elkaar aan, maar reguleren iets fundamenteel anders.

Een belangrijk inzicht: de CRA fungeert als supply chain tool voor NIS2. Een Belgisch ziekenhuis dat onder NIS2 valt, kan alleen veilig opereren als de medische apparatuur en software die het inkoopt zelf ook cybersecure zijn onder de CRA. Zo ontstaat een gesloten beveiligingslus van fabrikant tot eindgebruiker.

Bent u al bezig met NIS2-compliance? Lees dan onze complete NIS2-gids voor Vlaamse bedrijven om te zien hoe beide regelgevingen elkaar versterken.

De meldplicht voor kwetsbaarheden: wat moet u doen?

Vanaf 11 september 2026 geldt een strikte meldplicht voor fabrikanten. Wordt u zich bewust van een actief uitgebuite kwetsbaarheid in uw product, of een ernstig incident dat de integriteit of beschikbaarheid aantast, dan moet u een drietrapsprotocol volgen.

De melding gaat gelijktijdig naar ENISA en het CCB via een centraal meldingsplatform. Het doel is niet om fabrikanten te bestraffen, maar om een Europees dreigingsbeeld op te bouwen waarmee instanties als het CCB andere sectoren tijdig kunnen waarschuwen.

Dit meldproces vertoont gelijkenissen met de NIS2-meldplicht (24 uur/72 uur/1 maand), maar richt zich op productkwetsbaarheden in plaats van organisatie-incidenten. Bedrijven die beide regelgevingen moeten naleven, doen er goed aan hun incidentresponsprocessen te stroomlijnen.

De risicoclassificatie: welke conformiteitsprocedure geldt voor uw product?

De CRA deelt producten in drie risicocategorieën in. De categorie bepaalt of u zelf mag beoordelen of een externe partij moet inschakelen.

Naar schatting 90% van alle producten valt in de standaardcategorie. Daarvoor volstaat een zelfbeoordeling: u toetst intern of uw product aan de eisen van Bijlage I voldoet. Denk aan consumentenapps, eenvoudige hardware en tekstverwerkingssoftware.

Voor de overige 10% geldt een strenger regime. Klasse I-producten (zoals browsers, wachtwoordbeheerders en routers) moeten aantonen dat ze voldoen aan geharmoniseerde normen, of anders een externe beoordeling ondergaan. Klasse II-producten (zoals firewalls, IDS-systemen en industriële routers) vereisen een verplichte beoordeling door een aangemelde instantie (Notified Body). Kritieke producten (zoals smart meter gateways en hardware security modules) moeten een Europese cybersecuritycertificering op substantieel niveau of hoger behalen.

Wat betekent dit voor Belgische softwarebedrijven? Als u standaardsoftware zonder specifieke beveiligingsfunctie ontwikkelt, kunt u waarschijnlijk volstaan met een interne beoordeling. Ontwikkelt u echter identiteitsbeheersoftware, netwerkcomponenten of beveiligingsoplossingen, dan zult u een externe audit door een geaccrediteerd CAB moeten doorlopen.

Wat riskeert u bij niet-naleving?

De CRA-boetes zijn gemodelleerd naar de structuur van de GDPR en kunnen aanzienlijk zijn.

Voor niet-naleving van de essentiële eisen: boetes tot 15 miljoen euro of 2,5% van de wereldwijde jaaromzet (het hoogste bedrag geldt). Voor andere overtredingen: tot 10 miljoen euro of 2% van de omzet. Voor het verstrekken van onjuiste informatie: tot 5 miljoen euro of 1% van de omzet.

Bij het bepalen van de boete houden toezichthouders rekening met de economische draagkracht van de onderneming. Maar naast de financiële sanctie kan een gedwongen recall of verkoopverbod voor een KMO minstens even ingrijpend zijn.

Hoe bereidt u zich voor op de CRA?

De weg naar CRA-compliance begint bij uw ontwikkelproces. Vier stappen die u vandaag kunt zetten:

1. Inventariseer uw productportfolio Breng in kaart welke producten onder de CRA vallen en in welke risicocategorie ze thuishoren. Vergeet niet dat cloudcomponenten die essentieel zijn voor een fysiek product ook meetellen.

2. Integreer een Secure Development Lifecycle Bouw security in vanaf het ontwerp. Dat betekent threat modeling bij elk nieuw product of feature, veilige coderingsrichtlijnen voor uw ontwikkelteam, en geautomatiseerde SBOM-generatie in uw CI/CD-pipeline.

3. Test uw producten structureel Een application pentest identificeert kwetsbaarheden voordat aanvallers dat doen. Test regelmatig tegen de OWASP Top 10 en documenteer de resultaten als onderdeel van uw conformiteitsdossier.

4. Richt uw meldproces in Zorg vóór 11 september 2026 voor een operationeel kanaal met ENISA en het CCB. Stel een vulnerability disclosure policy op en train uw team op de 24-uurs/72-uurs meldtermijnen.

Heeft uw bedrijf al een CyberFundamentals-traject doorlopen? Dan heeft u een voorsprong. De controlemaatregelen van CyFun sluiten nauw aan bij de CRA-eisen rond software-updates, toegangsbeheer en kwetsbaarheidsbeheer.

Veelgestelde vragen over de Cyber Resilience Act

Geldt de CRA ook voor software?

Ja. De CRA is van toepassing op elk product met digitale elementen, inclusief standalone software. Alleen pure SaaS-oplossingen die geen essentieel onderdeel vormen van een fysiek product vallen buiten de scope. Die worden behandeld onder NIS2.

Wat is de SBOM-verplichting precies?

Een Software Bill of Materials is een machineleesbare lijst van alle softwarecomponenten, bibliotheken en afhankelijkheden in uw product. De CRA verplicht fabrikanten om deze bij te houden, bij elke update te herzien en minimaal tien jaar te bewaren na de laatste marktplaatsing.

Wat zijn de boetes bij niet-naleving?

De maximale boete bedraagt 15 miljoen euro of 2,5% van uw wereldwijde jaaromzet voor schending van de essentiële eisen. Daarnaast kan een toezichthouder een verkoopverbod of product-recall opleggen.

Moet mijn KMO al actie ondernemen?

Ja. De meldplicht voor actief uitgebuite kwetsbaarheden geldt vanaf 11 september 2026. Dat is over minder dan 18 maanden. U heeft nu de tijd om uw processen in te richten, maar wachten tot 2027 is geen optie als u de meldplichtdeadline wilt halen.

Hoe verhoudt de CRA zich tot ISO 27001?

ISO 27001 richt zich op het managementsysteem voor informatiebeveiliging van uw organisatie. De CRA richt zich op de beveiliging van uw producten. Ze zijn complementair: ISO 27001-gecertificeerde processen helpen bij het structureel naleven van CRA-eisen, maar ISO 27001-certificering alleen is niet voldoende voor CRA-conformiteit.

Wat als mijn product open source componenten bevat?

Zodra u open source componenten integreert in een commercieel product, gelden de CRA-verplichtingen voor dat product. U moet die componenten opnemen in uw SBOM en kwetsbaarheden in die componenten actief monitoren en patchen.

Volgende stap: bereid uw bedrijf voor

De Cyber Resilience Act verandert de manier waarop digitale producten in Europa op de markt worden gebracht. De eerste operationele deadline van 11 september 2026 is dichterbij dan u denkt.

Cyberplan begeleidt softwarebedrijven en producenten bij elke stap: van Secure Development Lifecycle-integratie en threat modeling tot application pentesting en kwetsbaarheidsbeheer. Ons team van 22 gecertificeerde ethische hackers (OSCP, CISSP) spreekt zowel de taal van uw developers als die van uw directie.

Plan een kennismaking en ontdek hoe Cyberplan u helpt om CRA-compliant te worden, zonder uw ontwikkelsnelheid te vertragen.