De meldplicht van de Cyber Resilience Act loopt. Weet jij wat er in je PLC's draait?

In de schakelkast van lijn 3 zit een PLC waar niemand in het gebouw nog volledig verantwoording over kan afleggen. De firmware is de versie waarmee de machinebouwer hem ooit in bedrijf stelde. Het programma gaat alleen open in de tool van één leverancier, op een laptop die niemand durft bij te werken. De machinebouwer is sindsdien twee keer overgenomen en op de laatste supportmail kwam geen antwoord. De machine zelf draait prima.

Op 11 september 2026 is een klok gaan lopen die precies die kast tot een probleem maakt. Niet eerst voor jou, maar voor wie de besturing en de machine eromheen heeft gebouwd.

Wat de Cyber Resilience Act sinds 11 september eist

Sinds 11 september 2026 geldt artikel 14 van de Cyber Resilience Act. Fabrikanten van producten met digitale elementen moeten twee dingen melden: een kwetsbaarheid die actief wordt uitgebuit, en een ernstig incident dat de beveiliging van het product raakt. De termijnen zijn krap:

• 24 uur nadat de fabrikant ervan weet: een vroegtijdige waarschuwing.
• 72 uur: een volledige melding met de aard van de kwetsbaarheid en de exploit, en de maatregelen die genomen of beschikbaar zijn.
• 14 dagen nadat een fix beschikbaar is: een eindrapport. Bij een ernstig incident moet het eindrapport binnen een maand liggen.

De melding gaat tegelijk naar het CSIRT van het land waar de fabrikant zijn hoofdvestiging heeft en naar ENISA, via het Single Reporting Platform dat dezelfde dag openging. In Nederland komen de meldingen binnen bij het NCSC, met de RDI als markttoezichthouder; in Polen bij CERT Polska. De fabrikant moet ook de gebruikers van het getroffen product informeren.

Twee details wegen zwaarder dan de termijnen. De klok start op het moment dat de fabrikant ervan weet, niet wanneer de analyse klaar is. En artikel 69 van de verordening stelt producten die al op de markt zijn vrij van de hoofdeisen zolang ze niet ingrijpend worden gewijzigd, maar houdt de meldplicht uitdrukkelijk van toepassing op al die producten. Een besturing die in 2019 is geleverd, valt vandaag onder de meldplicht; de rest van de CRA volgt op 11 december 2027.

Voor wie loopt de klok?

De verplichting ligt bij de fabrikant: wie een product met digitale elementen ontwikkelt of produceert en het onder eigen naam op de markt brengt. Op een werkvloer zijn dat meer partijen dan alleen de PLC-leverancier:

• De leveranciers van PLC's en drives, voor hun besturingen, firmware en engineeringsoftware.
• De machinebouwer, voor de digitale elementen in de machine als geheel: PLC, HMI, router voor toegang op afstand en de software die alles verbindt.
• Iedereen die zo'n product ingrijpend wijzigt en het opnieuw op de markt aanbiedt. Artikel 22 maakt die partij fabrikant voor het gewijzigde deel, of voor het hele product als de wijziging de beveiliging van het geheel raakt.

Heb jij een fabriek en verkoop je nooit apparatuur, dan is de CRA-klok niet van jou maar van je leverancier. Maar jij bent de gebruiker die de fabrikant moet informeren, en zodra je onder NIS2 valt heb je je eigen 24 en 72 uur voor incidenten in je eigen bedrijf. Dus als je PLC-leverancier een uitgebuite kwetsbaarheid bij ENISA meldt, is de vraag aan jouw kant direct: staat die besturing bij ons, welke versie, in welk netwerk, en wat kan hij bereiken?

Die vraag moet in uren beantwoord zijn. In de meeste fabrieken kost het weken.

Je kunt alleen melden wat je ziet

De CRA vraagt fabrikanten hun eigen product te kennen. Bijlage I verplicht hen de componenten erin te identificeren en te documenteren, inclusief een software bill of materials in een machineleesbaar formaat dat minstens de bovenste laag afhankelijkheden dekt. De ondersteuningsperiode moet minimaal vijf jaar duren, tenzij het product korter in gebruik zal zijn.

Leg die lijst naast de besturing van lijn 3. Gesloten firmware: niemand buiten de leverancier weet welke netwerkstack, webserver en realtime kernel erin zitten. Geen stuklijst, dus als een kwetsbaarheid in een bibliotheek wordt gepubliceerd kan niemand zeggen of die van toepassing is. Een programma dat alleen de tool van de leverancier kan lezen, van een leverancier die er misschien niet meer is.

Daarom is de 24-uursklok onwerkbaar voor ondoorzichtige apparatuur, van wie die klok formeel ook is. Je kunt alleen een kwetsbaarheid melden waarvan je weet dat ze bestaat. En een fabriek die niet kan opsommen wat er in haar kasten draait, kan niets met de waarschuwing van de leverancier als die binnenkomt.

Drie vragen voor je PLC en machineleveranciers

Stel elke leverancier met digitale apparatuur op je werkvloer drie vragen:

1. Kun je ons de software bill of materials van de besturing en de firmware geven? Al is het alleen de bovenste laag afhankelijkheden. Is het antwoord nee, dan weet je hoe ze het onder artikel 14 gaan doen.
2. Hoe informeer je ons over een actief uitgebuite kwetsbaarheid, en binnen hoeveel uur? Welk adres, welke contactpersoon bij ons, welk kanaal? Een accountmanager die "erop terugkomt" is geen kanaal.
3. Tot wanneer zit dit product in zijn ondersteuningsperiode, en wat gebeurt er daarna? Een besturing buiten de ondersteuningsperiode krijgt geen beveiligingsupdates meer. Dat is de datum waarna de machine geïsoleerd of de besturing vervangen moet worden.

Schrijf de antwoorden per machine op, naast de firmwareversie die er werkelijk draait. Die tabel is het begin van het OT-assetregister waar NIS2 om vraagt. De besturingen waarvan de leverancier geen antwoord heeft, horen in een eigen netwerkzone met gelogde toegang tot ze vervangen zijn. Dat is het eerlijke tussenantwoord.

Waarom een open besturing de meldplicht haalbaar maakt

Jarenlang was het argument voor open PLC-modernisering engineering en onafhankelijkheid: houd de machine, vervang de besturing, zet de logica in IEC 61131-3 op een runtime die je zelf kunt lezen. Sinds 11 september staat er een compliance-argument naast.

Een gesloten besturing is wat je kent van de grote fabrikanten: eigen hardware, eigen firmware als één ondertekend pakket, een eigen engineeringtool. Wat er in die firmware zit, welke netwerkstack, welke bibliotheken, welke versies, weet alleen de fabrikant. Jij ziet misschien één versienummer. Wordt er ergens een kwetsbaarheid gepubliceerd, dan kun je zelf niet nagaan of die jouw besturing raakt dan wacht je op het advisory van de fabrikant, dan op de patch, dan op het onderhoudsvenster waarin je die patch mag installeren. Je grip reikt precies zo ver als de fabrikant je laat kijken.

Een open besturing is gebouwd zoals een IT-systeem: een industriële computer of edge-controller met bijvoorbeeld een Linux-kernel, een runtime die IEC 61131-3 uitvoert, een veldbusstack en bibliotheken die elk een naam en een openbaar versienummer hebben. Die componenten staan in dezelfde openbare kwetsbaarheidsregisters (CVE) die je IT-afdeling al dagelijks volgt. De software bill of materials is dan geen document dat iemand achteraf schrijft: hij rolt uit de build. Wordt er een kwetsbaarheid in een van die componenten gepubliceerd, dan controleer je binnen het uur zelf of hij in jouw besturing zit, en je bepaalt zelf wanneer je de patch uitrolt, zonder te wachten op één fabrikant.

Hetzelfde geldt voor besturingshardware en edge-apparaten die voor jou zijn gebouwd. Bij onze hardware- en PCB-ontwikkeling komt de firmware uit hetzelfde huis als de printplaat, met ondertekende over-the-air updates en een bijgehouden software-inventaris vanaf de eerste schemalijn. Alleen zo krijg je een beveiligingsupdate op een apparaat in het veld zonder er naartoe te rijden. En de besturing is geen eiland meer: ze meldt haar firmwareversie, verbindingen en updatestatus aan dezelfde datalaag die je productiedata draagt, de laag waar IT-OT-integratie over gaat. Het assetregister is dan live, en het beantwoordt de waarschuwing van een leverancier in minuten.

Wat een open besturing niet oplost

Drie dingen horen op tafel voordat iemand je "CRA-compliance" verkoopt.

Een besturing maakt je niet compliant. Binnen 24 uur melden is een proces: iemand die bereikbaar is, iemand die weet welk CSIRT, iemand die de melding kan lezen en de fabriek kan controleren. De besturing maakt alleen het controleren snel.

Open is niet automatisch veilig. Een leesbare stack is een stack die je kunt auditen en patchen. Veilig wordt hij als iemand dat doet, en blijft doen zolang de machine leeft. Dat is werk, en het moet begroot worden.

Een modernisering kan de klok bij jou leggen. Wijzig je de besturing van een machine ingrijpend en gebruik je haar alleen in je eigen fabriek, dan breng je niets op de markt. Maar een machinebouwer of integrator die hetzelfde doet en de machine aan een klant levert, wordt onder artikel 22 fabrikant voor dat deel, met de volledige meldplicht. En dit artikel is geen juridisch advies.

Veelgestelde vragen over de CRA-meldplicht

Geldt de CRA-meldplicht voor een fabriek die alleen PLC's gebruikt?

Nee. De 24-uursplicht ligt bij de fabrikant van het product met digitale elementen, niet bij de gebruiker. Een fabriek voelt hem op twee manieren: als gebruiker die de fabrikant moet informeren, en via NIS2, dat zijn eigen vroegtijdige waarschuwing binnen 24 uur oplegt aan essentiële en belangrijke entiteiten, de maakindustrie inbegrepen.

Wat zijn de boetes?

Het schenden van de meldplicht van artikel 14 of van de essentiële eisen kan volgens artikel 64 oplopen tot 15 miljoen euro of 2,5 procent van de wereldwijde jaaromzet, het hoogste van de twee. Onjuiste informatie aan de autoriteiten kost tot 5 miljoen euro of 1 procent.

Wat is het verschil tussen de meldplicht van de CRA en die van NIS2?

Wie meldt, en waarover. De CRA legt de plicht bij de fabrikant van een product, over uitgebuite kwetsbaarheden en ernstige incidenten in dat product, aan ENISA en het nationale CSIRT. NIS2 legt de plicht bij de exploitant van essentiële of belangrijke diensten, over significante incidenten in de eigen bedrijfsvoering, aan de nationale autoriteit. Een productiebedrijf dat ook apparatuur met digitale elementen verkoopt, heeft beide.

Weet jij wat er in je kasten draait?

De besturingen die de drie vragen niet kunnen beantwoorden, zijn dezelfde waarover we schreven toen Siemens einddata prikte voor de S7-300 en de S7-1200 G1. De CRA geeft een tweede reden om ze aan te pakken, en een deadline die jij niet kunt verschuiven. Elk project begint met de inventaris. Vertel ons welke kast je wakker houdt.