Cyber Resilience Act: uw 24-uurs meldplicht
Bram SuurdTechnologie
Bereid uw productinventaris, SBOM en incidentroute voor op de CRA-meldplicht die vanaf 11 september 2026 voor bepaalde fabrikanten geldt.
In dit artikel
Weet u binnen 24 uur wat u moet doen als een actief uitgebuite kwetsbaarheid een product met digitale elementen raakt dat u als fabrikant op de markt brengt? Vanaf 11 september 2026 krijgt die vraag gewicht onder de Cyber Resilience Act. U hoeft dan nog niet elk technisch detail zeker te weten, maar u moet wel tijdig kunnen opschalen, voorlopig beoordelen en een vroege waarschuwing doen.
Dit gaat niet over iedere onderneming die software gebruikt. De Cyber Resilience Act richt zich op producten met digitale elementen, waaronder software, die onder eigen naam of merk op de markt worden gebracht. Brengt u software of een digitaal product onder eigen naam of merk op de markt, onderzoek dan of u als fabrikant en het product binnen de CRA-reikwijdte vallen.
Wat u vóór 11 september 2026 geregeld moet hebben
De meeste verplichtingen uit de Europese verordening gelden vanaf 11 december 2027. De meldverplichtingen voor fabrikanten uit artikel 14 starten echter al op 11 september 2026. Bij een actief uitgebuite kwetsbaarheid moet een fabrikant zonder onnodige vertraging een vroege waarschuwing doen, uiterlijk 24 uur nadat deze ervan op de hoogte is. Uiterlijk 72 uur daarna volgt een kwetsbaarheidsmelding. Artikel 14 omvat ook ernstige incidenten die gevolgen hebben voor de beveiliging van het product.
Zonder versie-overzicht, componentenlijst en escalatiehouder verliest u de eerste uren. Iemand moet kunnen vaststellen welk product en welke releases geraakt kunnen zijn, wie namens uw organisatie besluit en welke tijdelijke maatregel beschikbaar is.
Maak per product een korte productkaart
Maak per product een korte kaart met de productnaam, eigenaar, actieve versies, releaseproces, hostingpartij en contactpunt voor securitymeldingen. Neem ook software mee die door een externe partij is gebouwd maar onder uw naam wordt verkocht. De partij die een product onder eigen naam of merk op de markt brengt, kan als fabrikant gelden.
Dit overzicht is ook nuttig buiten de CRA. Verschijnt er een ernstig lek in een veelgebruikte library, dan wilt u niet eerst moeten uitzoeken welke applicatie die library gebruikt of wie toegang heeft tot de productieomgeving.
Een SBOM maakt de eerste beoordeling sneller
De CRA verlangt dat fabrikanten componenten identificeren en documenteren, onder meer via een software bill of materials, of SBOM, in een gangbaar machineleesbaar formaat voor ten minste de directe afhankelijkheden. Een SBOM is geen los bestand dat u aan het eind van een project maakt. Hij hoort bij de release.
Leg daarom per release vast welke packages, versies en herkomst erin zitten. Koppel die lijst aan een release-tag en bewaar hem op een plek waar het ontwikkelteam en de incidentverantwoordelijke bij kunnen. Dan kunt u gericht zoeken wanneer een kwetsbaarheid wordt gemeld, in plaats van alle repositories handmatig door te lopen.
Oefen uw eerste 24 uur
- Herkenning: bepaal wie securitymeldingen van leveranciers, onderzoekers en gebruikte componenten volgt.
- Beoordeling: wijs aan wie onderzoekt of uw product geraakt is en of er aanwijzingen zijn voor actieve uitbuiting.
- Besluit: leg vast wie namens uw organisatie een vroege waarschuwing of CRA-melding mag indienen.
- Herstel: test of u een kwetsbare functie kunt uitschakelen, een configuratie kunt aanpassen of een patch kunt uitrollen.
- Klantcommunicatie: bepaal wie klanten informeert over impact, tijdelijke maatregelen en een update.
Plan vóór september 2026 een tabletop-oefening met uw technische team, producteigenaar en iemand die klanten te woord staat. Kies een kwetsbaarheid in een dependency die in meerdere productversies zit. Meet hoe lang het duurt voordat u antwoord heeft op drie vragen: gebruiken we dit onderdeel, welke klanten raken we en welke maatregel kunnen we vandaag nemen?
Leg afspraken met externe partijen vast
Veel MKB-software bevat code, hosting of monitoring van andere partijen. Leg vast wie beveiligingsmeldingen ontvangt, hoe snel een leverancier een mogelijke kwetsbaarheid doorgeeft en wie een patch uitrolt. Een supportadres dat alleen tijdens kantooruren wordt gelezen, is geen incidentproces.
Vraag ook om een contactpersoon voor urgente meldingen. Leg vast welke informatie u bij een incident krijgt: betrokken component, getroffen versies, bekende tijdelijke maatregel en verwachte hersteltijd.
Begin klein, maar maak het aantoonbaar
Kies één product, maak de productkaart, verzamel een componentenlijst en oefen de eerste 24 uur. Daarmee bewijst u niet automatisch dat u volledig aan de CRA voldoet. U ziet wel waar uw incidentproces nog leunt op losse kennis of onduidelijke afspraken.
BLB Solutions kan in een technische werksessie uw productinventaris, SBOM-aanpak en incidentroute toetsen. Het resultaat is een korte prioriteitenlijst met concrete verbeterpunten voor uw team.
