EU Cyber Resilience Act: de 24-uurs meldplicht voor kleine software-leveranciers

Vanaf 11 september heb je 24 uur

Ergens in jouw product zit op dit moment een dependency waar je sinds de sprint waarin je die toevoegde niet meer naar hebt omgekeken. Vanaf 11 september 2026 kan die dependency een klok laten lopen.

Op die dag treedt artikel 14 van de EU Cyber Resilience Act (CRA) in werking. Vanaf dat moment geldt: als een kwetsbaarheid in software die jij levert actief wordt misbruikt, moet je binnen 24 uur nadat je daarvan op de hoogte bent geraakt een eerste melding doen aan ENISA, het Europese agentschap voor cyberbeveiliging. Binnen 72 uur volgt een uitgebreidere melding en binnen 14 dagen een definitief rapport.

Niet alleen voor nieuwe producten. Ook voor producten die al op de markt zijn. De maximale boete bedraagt €15 miljoen of 2,5% van de wereldwijde jaaromzet, afhankelijk van welk bedrag hoger is.

De afgelopen week heb ik met oprichters van kleine Europese softwarebedrijven gesproken. Het patroon is opvallend consistent: de enterprise-wereld weet al twee jaar dat dit eraan komt, terwijl veel softwarebedrijven met tien medewerkers er nog nooit van hebben gehoord.

"Wij zijn te klein, dit geldt toch niet voor ons?"

Dat was ook mijn eerste reactie. En die blijkt op een interessante manier onjuist.

De CRA geldt voor producten met digitale elementen die in de EU worden verkocht: installeerbare software, firmware, verbonden apparaten en de software die daarin draait. Er bestaat geen uitzondering voor kleine leveranciers. Een bedrijf met twee medewerkers dat een desktopapplicatie verkoopt valt onder dezelfde regels als Siemens.

Eén belangrijke nuance, omdat je hierover tegenstrijdige uitspraken zult tegenkomen: of pure SaaS volledig onder de CRA valt, is nog onderwerp van discussie. De verordening richt zich op producten; pure cloudservices vallen grotendeels onder andere regelgeving, met name NIS2. Lever je echter iets dat een klant installeert of lokaal uitvoert (een agent, een on-premises component, een plugin of een apparaat) dan is die discussie voor jou nauwelijks relevant. Dan val je gewoon onder de CRA.

Ook de meldplicht binnen 24 uur is beperkter dan hij op het eerste gezicht lijkt, en juist daardoor uitvoerbaar. De verplichting geldt alleen voor kwetsbaarheden die actief worden misbruikt. Dus niet voor iedere CVE en ook niet voor iedere Dependabot-melding. Alleen voor kwetsbaarheden die daadwerkelijk door aanvallers worden gebruikt, het soort dat terechtkomt in de Known Exploited Vulnerabilities (KEV)-catalogus van CISA. Dat is geen eindeloze stroom meldingen, maar een relatief korte lijst met ernstige, daadwerkelijk misbruikte kwetsbaarheden.

Het echte probleem is niet rapporteren. Het is weten.

Een melding naar ENISA versturen is uiteindelijk niet meer dan een formulier invullen.

De echte uitdaging zit in alles wat daaraan voorafgaat: hoe weet je binnen 24 uur dat een component die jij drie jaar geleden hebt meegeleverd opeens actief wordt misbruikt?

Die vraag kun je pas beantwoorden als je eerst een eenvoudigere vraag kunt beantwoorden:

Wat zit er eigenlijk precies in jouw product?

Ik heb één van onze eigen oudere codebases, een CMS dat we jaren geleden ontwikkelden, langs die meetlat gelegd.

Een twintigtal dependencies. Een mailbibliotheek die vastgepind stond op een versie uit 2020 waarvoor inmiddels bekende CVE's bestaan. En er was zelfs helemaal geen lockfile opgenomen in de repository. Daardoor is achteraf niet eens meer aantoonbaar welke versies daadwerkelijk zijn uitgeleverd.

Dat laatste deed misschien nog wel het meeste pijn. Niet omdat het een kwetsbaarheid is, maar omdat het iets fundamentelers blootlegt: je kunt simpelweg niet bewijzen wat je hebt geleverd.

Zo zien de meeste codebases van kleinere softwareleveranciers eruit, ook die van goed georganiseerde bedrijven. Niemand reserveerde in 2019 tijd of budget voor een Software Bill of Materials (SBOM).

De CRA gaat er straks vanuit dat je die wél hebt.

Vanaf 11 december 2027 worden SBOM's, secure-by-design ontwikkelprocessen en CE-markering verplicht. De meldplicht van september is slechts de eerste voorbode.

Daarom heb ik in ongeveer 24 uur een radar gebouwd

De symboliek was te mooi om te laten liggen: een 24-uursregel verdiende een tool die in ongeveer 24 uur gebouwd werd.

CRAIR – CRA Incident Radar analyseert een repository of lockfile en genereert een tweepagina's tellende CRA Readiness Snapshot.

Daarin zie je:

• welke componenten jouw product bevat;

• welke daarvan bekende kwetsbaarheden hebben;

• welke kwetsbaarheden op dit moment actief worden misbruikt, gecontroleerd tegen de CISA KEV-lijst en voorzien van EPSS-scores die de kans op exploitatie aangeven;

• én alvast een conceptmelding die je, indien nodig, aan ENISA zou kunnen versturen.

Twee ontwerpkeuzes vormen de kern van de filosofie.

Actief misbruikt is belangrijker dan volledig

Een rapport met 200 CVE's leest niemand.

De Readiness Snapshot begint daarom met de kwetsbaarheden die op de KEV-lijst staan, omdat juist daarvoor de wettelijke klok begint te lopen. Alle overige bevindingen staan in de bijlage.

Een ontbrekende lockfile is óók een bevinding

Wanneer jouw project alleen versiebereiken bevat en geen lockfile, wordt dat expliciet vermeld.

Een lockfile committen is waarschijnlijk de goedkoopste stap die je vandaag kunt zetten om beter voorbereid te zijn op de CRA. Toch wordt die zelden vanuit dat perspectief bekeken.

Wat je deze week kunt doen, met of zonder tool

1. Commit je lockfiles. Denk aan composer.lock en package-lock.json. Zet ze vandaag nog in je repository. Reproduceerbare builds vormen de basis voor alles wat daarna komt.

2. Genereer een SBOM voor één product. Welke generator je gebruikt maakt minder uit. De eerste keer voelt ongemakkelijk en juist dat is waardevol.

3. Controleer je software tegen de CISA KEV-lijst. Deze is openbaar beschikbaar als JSON-bestand. Staat een component die jij levert erop? Dan heb je alvast geoefend voor 11 september.

4. Wijs een verantwoordelijke aan. De 24-uursperiode begint zodra jouw organisatie zich bewust wordt van een actief misbruikte kwetsbaarheid. Zorg dat duidelijk is wie daarvoor verantwoordelijk is, en leg dat schriftelijk vast.

Of laat de radar dit allemaal voor je doen.

CRAIR biedt gratis een Readiness Snapshot aan voor iedere publieke repository of geüploade lockfile. De analyse duurt ongeveer een minuut. Continue monitoring, waarbij de KEV-lijst automatisch wordt gevolgd zodat jij dat niet hoeft te doen, kost €99 per maand.

Nog 56 dagen, op het moment dat ik dit schrijf.

Een Readiness Snapshot is een geautomatiseerde analyse op basis van openbare kwetsbaarheidsbronnen, waaronder OSV, CISA KEV en FIRST EPSS. Het is geen juridisch advies en vormt geen officiële conformiteitsbeoordeling onder de Cyber Resilience Act.