Van kwetsbaarheid naar meldplicht: wat er op 11 september verandert

Er is een verschil tussen een kwetsbaarheid die u zelf oplost, een kwetsbaarheid waarover u uw klant informeert, en een kwetsbaarheid die u bij een toezichthouder moet melden. In gesprekken lopen die drie voortdurend door elkaar. Vanaf volgende week is dat verschil niet meer alleen netjes, maar juridisch.

Wat er op 11 september verandert, en wat niet

De Cyber Resilience Act, Verordening (EU) 2024/2847, is op 10 december 2024 in werking getreden. De verordening kent een gefaseerde invoering. De Europese Commissie geeft daarvoor twee data die er nu toe doen.

• De meldplichten gelden vanaf 11 september 2026 (melding van actief geëxploiteerde kwetsbaarheden en ernstige beveiligingsincidenten, inclusief de meldstappen van 24 en 72 uur).
• De hoofdverplichtingen gelden vanaf 11 december 2027 (cybersecurity-eisen voor producten, kwetsbaarhedenbeheer, technische documentatie, conformiteitsbeoordeling, EU-conformiteitsverklaring en CE-markering).

Dat onderscheid wordt vaak weggelaten en is precies de reden dat organisaties denken nog ruim een jaar te hebben. Dat klopt deels: voor het grootste deel van de productconformiteitseisen. CE-markering, conformiteitsbeoordeling, de EU-conformiteitsverklaring en de technische documentatie worden pas vanaf december 2027 van toepassing. De meldklok begint veel eerder te lopen.

Eerst de vraag die zelden gesteld wordt: welke rol heeft u?

De verplichtingen uit de verordening hangen aan een rol. Fabrikant, importeur en distributeur hebben elk andere plichten. Wie geen van drieën is, hoeft de rest van dit artikel niet te lezen.

Het addertje zit in de vertaling naar de wereld van industriële besturingssystemen. ISA/IEC 62443 werkt met asset owner, product supplier, service provider en integrator. Dat zijn nuttige rollen, maar het zijn niet de economische actoren uit het Europese productrecht en ze vallen daar niet op samen. Een organisatie die zichzelf al jaren asset owner noemt, kan onder de verordening fabrikant zijn, namelijk zodra zij een product met digitale elementen onder eigen naam op de EU-markt brengt.

Dat komt vaker voor dan het klinkt. Een machinebouwer die een besturingskast met eigen software levert. Een integrator die een gateway onder eigen merk verkoopt. Een leverancier die firmware van een derde herverpakt. Stel die vraag eerst, want zonder het antwoord is de rest van de analyse zonder betekenis.

Drie uitkomsten, en één ervan heeft een klok

Als de rolvraag is beantwoord, valt een gevonden kwetsbaarheid in een van de drie categorieën.

1. Een interne bevinding. U verhelpt hem volgens uw eigen proces en legt vast wat er is besloten, wanneer en door wie.
2. Een mededeling. U informeert uw klant en de keten, en maakt na het beschikbaar komen van de update publiek bekend wat er is verholpen.
3. Een wettelijke melding. Die gaat naar de nationale CSIRT en naar ENISA, en daarbij gaan termijnen lopen.

De derde categorie is nieuw voor de meeste fabrikanten. Volgens de samenvatting van de Europese Commissie gaat het om actief geëxploiteerde kwetsbaarheden en om ernstige incidenten met gevolgen voor de beveiliging, met een vroegtijdige waarschuwing binnen 24 uur, een melding binnen 72 uur en een eindverslag daarna. Laat de precieze termijn per meldingssoort en de exacte reikwijdte toetsen aan artikel 14 van de verordening zelf; dat is de operatieve tekst en niet de samenvatting.

De klok begint bij het moment waarop u ervan wist. Niet bij het moment waarop u het had geduid, en niet bij het moment waarop de patch klaar was. Dat is het punt waar draaiboeken in de praktijk stuklopen.

Wat uw IEC 62443-programma hier wél oplevert

Als u al met IEC 62443 werkt, staat u niet met lege handen. Het Joint Research Centre van de Europese Commissie en ENISA hebben de eisen uit de verordening naast bestaande standaarden gelegd. In die analyse is EN IEC 62443-4-1:2018 gekoppeld aan vier van de acht eisen voor de omgang met kwetsbaarheden uit Annex I deel II: kwetsbaarheden verhelpen, openbaar maken wat er is verholpen, updates veilig distribueren, en patches onverwijld en kosteloos verspreiden.

Dat is substantieel. Het is ook precies de helft, en het gat zit niet waar de meeste mensen het zoeken. Niet gekoppeld aan 62443-4-1 zijn in diezelfde analyse: het opstellen van een software bill of materials, het ritme van tests en reviews, een beleid voor gecoördineerde kwetsbaarheidsmelding, en het meldadres waarlangs een buitenstaander u kan bereiken. Voor die laatste twee wijst de analyse naar ISO/IEC 30111 en ISO/IEC 29147, en niet naar meer 62443.

Dezelfde analyse merkt op dat geen enkele standaard in zijn eentje alle eisen uit Annex I dekt, en dat de 62443-reeks nadrukkelijk is toegesneden op industriële besturingssystemen. Zodra uw product ergens anders wordt verkocht, verliest die onderbouwing een deel van haar zeggingskracht.

Dit is een mapping door Europese instellingen en geen oordeel van een toezichthouder. Een IEC 62443-implementatie levert geen CRA-conformiteit op, en een 62443-certificering toont onder de verordening niets aan. Dat zijn twee verschillende beoordelingen met een verschillende rechtsgrond.

Wat er deze week moet gebeuren

1. Stel per product vast welke rol u heeft. Fabrikant, importeur, distributeur of geen van drieën. Zet het op papier.
2. Wijs één persoon aan die mag besluiten dat iets meldplichtig is, en zorg dat die persoon bereikbaar is buiten kantooruren. Een meldtermijn van 24 uur loopt ook in het weekend.
3. Controleer of u een meldadres heeft dat een buitenstaander kan vinden, en of iemand dat leest.
4. Leg vast hoe u het moment registreert waarop u ergens van wist. Zonder dat moment kunt u achteraf niet aantonen dat u op tijd was.
5. Bepaal welke van uw producten überhaupt onder de verordening vallen. Die vraag is feitelijk werk en geen aanname.

Geen van deze vijf punten vraagt een project. Ze vragen een middag en een besluit, en ze zijn alle vijf gratis. Het verschil tussen een organisatie die op 11 september klaar is en een die dat niet is, zit hier en niet in een compliancetraject.

Waar dit op lijkt

Dit is dezelfde vraag als in de rest van deze reeks, in andere woorden. In OT vragen we wie het restrisico draagt als er niet gepatcht wordt. In AI-governance vragen we wie het systeem mag stilzetten. Onder de Cyber Resilience Act vragen we: wie is de fabrikant, wat is er beloofd, hoe lang geldt die belofte, en kunnen we laten zien dat we hem waarmaken.

Het patroon eronder is steeds hetzelfde: vraag, context, besluit, eigenaar, bewijs, review. Zie het hoeksteenartikel voor hoe die vraag in alle drie de domeinen terugkomt, en het stuk over patchen, mitigeren, monitoren of accepteren voor de OT-variant.

Tot slot, en dit hoort erbij

Dit artikel is geen juridisch advies en toont geen conformiteit aan. Het is een werkmodel om het gesprek te kunnen voeren. De verordening zelf staat op EUR-Lex, de fasering op de pagina van de Europese Commissie, de samenvatting van de wettekst hier, en de mapping van eisen op standaarden in de gezamenlijke analyse van JRC en ENISA. Laat de toepassing op uw eigen producten juridisch toetsen.

Praktisch advies

Begin deze week niet met een volledig CRA-complianceprogramma. Begin met vijf vragen:

1. Welke van onze producten vallen onder de Cyber Resilience Act?
2. Zijn wij per product fabrikant, importeur of distributeur?
3. Wie beslist of een kwetsbaarheid of incident meldplichtig is?
4. Kan die persoon dat besluit binnen 24 uur nemen, ook buiten kantooruren?
5. Kunnen we aantonen wanneer we voor het eerst van de kwetsbaarheid of het incident op de hoogte waren?

Als één van deze antwoorden onduidelijk is, dan is dat het eerste gat dat vóór 11 september moet worden opgelost.

De directe CRA-vraag is deze week niet: “zijn we compliant?”, maar: “kunnen we herkennen, besluiten en melden binnen de vereiste termijn?”

Meer de diepte in aan de engineeringkant?

Wie hier dieper in wil op de engineeringkant: de PECB ISA/IEC 62443 Lead Implementer behandelt de productbeveiliging en de levenscyclus waar dit op aansluit.