De Cyber Resilience Act (EU) 2024/2847 is de eerste Europese verordening die bindende cybersecurityeisen stelt aan alle producten met digitale elementen die op de EU-markt worden gebracht, inclusief software voor soevereine werkplekken. Voor compliance officers en IT-beslissers in de publieke sector, de juridische sector en andere gereguleerde sectoren verandert de wet niet alleen de verplichtingen van leveranciers, maar ook de manier waarop inkoop moet worden ingericht.
Wat de Commissieguidance van 27 juli 2026 concreet verandert voor inkopers
De Commissieguidance gepubliceerd op 27 juli 2026 verduidelijkt hoe de CRA-verplichtingen in de praktijk worden toegepast, specifiek voor organisaties die soevereine software inkopen. De guidance maakt duidelijk dat conformiteitsdocumentatie, inclusief de Software Bill of Materials (SBOM) en bewijsstukken voor beveiligingsupdatebeleid, beschikbaar moet zijn vóór contractsluiting, niet achteraf op verzoek.
Voor inkopers van soevereine werkplekoplossingen, denk aan Nextcloud als vervanging voor Microsoft 365, lokale AI-tools of versleutelde on-premise opslagoplossingen, betekent dit dat het inkoopproces een technische beoordelingsfase vereist. De leverancier moet kunnen aantonen dat zijn product voldoet aan CRA Annex I essentiële beveiligingseisen: standaard veilige configuratie, minimale aanvalsoppervlakte, bescherming van vertrouwelijkheid en integriteit van gegevens, en aantoonbaar patchbeleid gedurende de gehele levenscyclus van het product.
Meldplicht per 11 september 2026: verificatie door inkopers
Fabrikanten zijn per 11 september 2026 verplicht actief misbruikte kwetsbaarheden binnen 24 uur na ontdekking te melden bij ENISA, gevolgd door een gedetailleerd rapport binnen 72 uur. Dit geldt voor alle producten met digitale elementen die op de EU-markt beschikbaar zijn, ongeacht of de volledige verordening al van toepassing is.
Inkopers kunnen de naleving hiervan op twee manieren verifiëren. Ten eerste contractueel: neem in de verwerkersovereenkomst of leverancierscontract een bepaling op die de leverancier verplicht u onverwijld te informeren zodra hij een melding bij ENISA doet die betrekking heeft op producten die u gebruikt. Ten tweede via publieke registers: ENISA publiceert gemelde kwetsbaarheden in geaggregeerde vorm, en inkopers kunnen dit koppelen aan hun eigen asset management om snel te bepalen of een melding relevant is voor hun omgeving.
Statistisch onderbouwing voor de urgentie: ENISA rapporteerde in zijn Threat Landscape 2023 dat supply chain-aanvallen op softwarecomponenten met 40 procent zijn toegenomen ten opzichte van het voorgaande jaar. Dit maakt vroegtijdige kwetsbaarheidsmelding niet alleen een wettelijke verplichting, maar een operationeel belang.
SBOM en beveiligingseisen als inkoopcriterium
Compliance officers kunnen de CRA-vereisten direct vertalen naar concrete selectiecriteria in aanbestedingen en leveranciersevaluaties. De drie voornaamste criteria zijn de SBOM, het beveiligingsupdatebeleid en de aantoonbare meldplichtprocedure.
SBOM als due-diligence instrument
Een SBOM geeft een volledig overzicht van alle softwarecomponenten in een product, inclusief versienummers, licenties en bekende kwetsbaarheden via CVE-identifiers. Voor soevereine werkplekcomponenten is de SBOM bijzonder waardevol: het stelt de inkopende organisatie in staat te controleren of derde-partijcomponenten afkomstig zijn uit jurisdicties met geopolitieke risico’s, zoals landen die vallen onder de extraterritoriale werking van de Amerikaanse CLOUD Act of Patriot Act.
Bij de evaluatie van Nextcloud als soevereine samenwerkingsomgeving kan de inkoper de SBOM van de enterprise-editie vergelijken met die van de community-editie. Componenten met bekende onopgeloste kwetsbaarheden of componenten afkomstig van leveranciers zonder EU-vestiging verdienen extra aandacht in de risicoafweging.
Beveiligingsupdatebeleid als contractuele eis
CRA Annex I vereist dat fabrikanten beveiligingsupdates beschikbaar stellen gedurende de gehele verwachte levensduur van het product, met een minimum van vijf jaar. Inkopers moeten in het contract vastleggen welke levensduur is overeengekomen, wat de maximale reactietijd is op kritieke kwetsbaarheden, en hoe updates worden geleverd in een on-premise of air-gapped omgeving.
Open-source versus commerciële software: verschil in CRA-verplichtingen
De CRA maakt een belangrijk onderscheid dat direct invloed heeft op de soevereine inkoopstrategie.
| Kenmerk | Open-source (gratis, niet-commercieel) | Commerciële of enterprise software |
|---|---|---|
| CRA-fabriканtenverplichtingen | Niet van toepassing bij zuiver niet-commerciële distributie | Volledig van toepassing |
| SBOM-vereiste | Niet verplicht, maar aanbevolen | Verplicht onder CRA Annex I |
| Meldplicht kwetsbaarheden | Niet verplicht voor beheerder zonder commercieel belang | Verplicht per 11 september 2026 |
| Inkooprisico | Eigen verantwoordelijkheid voor verificatie en patching | Leverancier draagt primaire verantwoordelijkheid |
Nextcloud GmbH biedt naast de open-source community-editie een commerciële enterprise-editie aan met SLA-ondersteuning. Die enterprise-editie valt wel degelijk onder de volledige CRA-verplichtingen. Organisaties in gereguleerde sectoren die behoefte hebben aan aantoonbare compliance, doen er verstandig aan de enterprise-editie te kiezen, juist omdat de leverancier dan wettelijk verantwoordelijk is voor SBOM, patchbeleid en meldplicht.
CRA-meldplicht versus NIS-2 artikel 23: voorkomen van dubbele lasten
Veel organisaties in de publieke sector en gereguleerde sectoren vallen zowel onder de NIS-2-richtlijn (EU) 2022/2555 als, via hun leveranciers, indirect onder de CRA. Beide regelingen kennen een meldplicht, maar met een ander toepassingsbereik en andere adressanten.
NIS-2 artikel 23 verplicht essentiële en belangrijke entiteiten significante incidenten te melden bij de bevoegde nationale autoriteit, in Nederland het Nationaal Cyber Security Centrum (NCSC) of een sectorale toezichthouder, binnen 24 uur voor een vroege waarschuwing en binnen 72 uur voor een volledig incidentrapport. De CRA-meldplicht richt zich op de fabrikant en betreft kwetsbaarheden, niet per se een volledig incident bij de gebruiker.
ENISA stelt hierover: “Organisations should align their internal processes with both CRA and NIS-2 reporting timelines to avoid duplication.” In de praktijk betekent dit dat compliance officers één geïntegreerd meldproces inrichten dat beide tijdlijnen dekt. Wanneer een leverancier een CRA-melding doet bij ENISA over een kwetsbaarheid in een product dat de organisatie gebruikt, en die kwetsbaarheid leidt tot een significant incident, dan triggert dat vervolgens de NIS-2-meldplicht voor de organisatie zelf. Door een interne escalatieprocedure te koppelen aan de CRA-meldingen van leveranciers, vermijdt u dat u reactief en dubbel rapporteert.
De Europese Commissie schat dat de CRA de kosten van beveiligingsincidenten voor Europese organisaties met tot 20 procent kan terugdringen door vroegtijdige kwetsbaarheidsmelding en verplichte beveiligingsupdates (Europese Commissie, Impact Assessment CRA, SWD(2022) 282). Die kostenreductie realiseert zich echter alleen als inkopers de CRA-conformiteit ook daadwerkelijk contractueel en procesmatig borgen.
CRA en ENISA EUCS: de bredere soevereine cloudstrategie
De CRA staat niet op zichzelf. In combinatie met het ENISA European Union Cybersecurity Certification Scheme for Cloud Services (EUCS) vormt zij het normatieve kader voor organisaties die publieke cloudafhankelijkheid willen afbouwen. Het EUCS stelt eisen aan de vestiging en jurisdictie van cloudaanbieders: op het hoogste assuranceniveau (hoog) mogen geen gegevens worden verwerkt buiten de EU, en moeten aanbieders aantonen dat zij niet onderworpen zijn aan wetgeving van derde landen die toegang tot EU-gegevens kan afdwingen, zoals de Amerikaanse CLOUD Act.
Voor organisaties die migreren van Microsoft 365 naar een soevereine Nextcloud-werkplek, biedt de combinatie van CRA-conformiteit en EUCS-certificering een aantoonbaar juridisch en technisch kader richting toezichthouders. Dit is relevant omdat de wereldwijde schade door ransomware-aanvallen in 2023 naar schatting meer dan 1 biljoen dollar bedroeg (Cybersecurity Ventures, 2023), en publieke cloudinfrastructuur een toenemend doelwit vormt.
Margrethe Vestager, voormalig Uitvoerend Vicevoorzitter van de Europese Commissie, verwoordde de intentie van de CRA als volgt: “The Cyber Resilience Act will make connected products more secure for consumers and businesses across the EU by ensuring manufacturers take cybersecurity seriously from the design phase all the way to the end of a product’s lifecycle.” Voor inkopers is dit de kern: de wet verschuift de verantwoordelijkheid voor basisbeveiliging van de gebruiker naar de fabrikant, maar de inkoper moet die verschuiving contractueel en procesmatig afdwingen.
Praktische stappenplan voor compliance officers en IT-beslissers
Een effectieve CRA-inkoopstrategie voor soevereine werkplekcomponenten omvat de volgende stappen. Begin met een inventarisatie van alle softwareproducten in de soevereine werkplek en stel per product vast of de leverancier als fabrikant onder de CRA valt. Vraag vervolgens bij elke potentiële leverancier vóór contractsluiting de SBOM op en toets deze op componenten met openstaande CVE’s en op jurisdictionele risico’s. Leg in het contract vast dat de leverancier u binnen 24 uur informeert bij een CRA-melding bij ENISA die uw producten betreft. Koppel dit aan uw interne NIS-2-escalatieprocedure zodat u bij een significant incident direct de juiste nationale autoriteit kunt informeren zonder dubbele administratieve handelingen. Controleer tot slot jaarlijks of de leverancier zijn CRA-conformiteitsdocumentatie heeft bijgewerkt, met name na grote versie-updates van de software.
FAQ: Cyber Resilience Act praktijkgids 2026 voor inkopers
Geldt de Cyber Resilience Act ook voor organisaties die software uitsluitend intern gebruiken en niet verkopen?
De CRA richt zich primair op fabrikanten die producten met digitale elementen op de markt brengen. Organisaties die software intern ontwikkelen voor eigen gebruik vallen buiten de directe verplichtingen als fabrikant, maar zijn als inkoper verantwoordelijk voor het contractueel afdwingen van CRA-conformiteit bij hun leveranciers.
Wat moet een SBOM minimaal bevatten om aan CRA Annex I te voldoen?
Een SBOM moet conform CRA Annex I ten minste alle softwarecomponenten, hun versies, licenties en bekende kwetsbaarheden via CVE-identifiers bevatten, zodat inkopers de volledige componentketen kunnen doorlichten op risico’s.
Hoe lang heeft een fabrikant de tijd om een actief misbruikte kwetsbaarheid te melden na ontdekking?
Onder de CRA-meldplicht die per 11 september 2026 van kracht is, dient een fabrikant een actief misbruikte kwetsbaarheid binnen 24 uur na ontdekking te melden bij ENISA, gevolgd door een uitgebreider rapport binnen 72 uur.
Hoe verschilt de CRA-meldplicht van de NIS-2-meldplicht onder artikel 23?
NIS-2 artikel 23 verplicht essentiële en belangrijke entiteiten significante incidenten te melden bij de nationale toezichthouder. De CRA verplicht fabrikanten tot melding van kwetsbaarheden bij ENISA. Bij een incident dat beide triggers raakt, kunnen organisaties via gecoördineerde rapportage dubbele lasten beperken, mits interne processen hierop zijn afgestemd.
Is Nextcloud CRA-plichtig als open-source product?
Open-source software die gratis en zonder commerciële ondersteuning wordt aangeboden, valt buiten de directe CRA-fabriканtenverplichtingen. Nextcloud GmbH biedt echter commerciële enterprise-edities aan en valt daarmee wel onder de CRA-verplichtingen voor die varianten. Inkopers dienen in hun contract vast te leggen welke editie wordt geleverd en welke CRA-documentatie de leverancier beschikbaar stelt.
