Antwoorden over de Cyber Resilience Act verwijzen nu naar het artikel

Op 11 september 2026 trad de rapportageplicht uit Artikel 14 van de Cyber Resilience Act in werking. Vanaf die datum is een fabrikant van een product met digitale elementen dat op de hoogte raakt van een actief uitgebuite kwetsbaarheid in dat product, verplicht tot:

• een vroege waarschuwing binnen 24 uur,
• een volledige melding binnen 72 uur,
• een eindrapportage na afloop van deze termijnen: 14 dagen voor een kwetsbaarheid zodra een corrigerende maatregel beschikbaar is, of één maand voor een ernstig incident (Verordening (EU) 2024/2847, Artikelen 14 en 71).

Een plicht met een 24-uursklok verandert een ongeveer juist antwoord in een aansprakelijkheidsrisico. De vragen die na de start van deze klok binnenkomen, zijn specifiek, niet thematisch. Telt het product überhaupt als een product met digitale elementen? Tot welke klasse behoort het, en welke conformiteitsroute volgt daaruit? Wie is de coördinerende CSIRT en waar moet de melding worden ingediend? Een plausibel klinkend antwoord dat de bepaling verkeerd interpreteert, is erger dan geen antwoord, omdat je daarop handelt.

De Cyber Resilience Act is ook precies waar een algemene assistent het slechtst presteert. De verordening trad in werking op 10 december 2024, recent genoeg dat de modelkennis over de tekst beperkt is. Bovendien is de toepassing ervan gestaffeld volgens Artikel 71, wat zelfs professionals in het veld in de war brengt door zich te richten op de verkeerde datum: de hoofdtoepassingsdatum van 11 december 2027, wanneer de essentiële eisen, conformiteitsbeoordeling en CE-markering ingaan, is de datum die de meeste roadmaps noemen en ligt meer dan een jaar na de rapportageplicht die fabrikanten al bindt.

Voorheen, en nu

Tot deze release was de Cyber Resilience Act niet opgenomen in de curated framework packs van de assistent. Een vraag over de CRA werd beantwoord via hetzelfde algemene pad als elke andere vraag: modelkennis, zonder artikelverwijzingen. Voor de AVG, DORA, UK GDPR en CCPA/CPRA hadden we dit al opgelost met packs die paragrafen en punten citeren. De CRA was het ontbrekende onderdeel, en dat ontbrekende onderdeel viel precies samen met de klok die al liep.

Wat in september 2026 is uitgerold, is een curated knowledge pack voor Verordening (EU) 2024/2847, geverifieerd aan de hand van de officiële tekst. Het dekt alle 71 artikelen op artikelniveau, met puntverwijzingen waar de adviezen daarvan afhankelijk zijn:

• Artikel 13: de plichten van de fabrikant, zoals de ondersteuningsperiode en de verplichtingen voor beveiligingsupdates, een enkel contactpunt en een gecoördineerd beleid voor kwetsbaarheidsdisclosure.
• Artikel 14: de rapportagemelding en de bijbehorende termijnen, inclusief wat als een ernstig incident telt.
• Artikelen 15 tot 17: vrijwillige meldingen en het ENISA-eenloket voor meldingen.
• Artikelen 18 tot 26: invoerders, distributeurs, wezenlijke wijzigingen en beheerders van open-source software.
• Artikelen 27 tot 34: de conformiteitsroutes en de routing tussen klasse I, klasse II en kritieke producten.
• Artikel 64: de boetebanden, die oplopen tot €15 miljoen of 2,5% van de totale wereldwijde jaaromzet voor de meest ernstige overtredingen.
• Aanhangsels: Aanhangsel I (essentiële eisen en verplichtingen voor kwetsbaarheidsafhandeling), Aanhangsel II (gebruikersinformatie), Aanhangsel III (productklassen en lijst met kritieke producten in Aanhangsel IV) en Aanhangsel VII (technische documentatie).

Elke regel bevat de actor waarop deze van toepassing is, volgens de taxonomie van de verordening zelf: fabrikant, invoerder, distributeur, beheerder van open-source software, gemachtigde vertegenwoordiger, aangemelde instantie, markttoezichthouder, CSIRT, ENISA. Een invoerder die vraagt of een plicht op hem van toepassing is, krijgt een antwoord dat het artikel noemt en aangeeft wie de plicht draagt, in plaats van een samenvatting vanuit het perspectief van de fabrikant.

Wat "CRA" niet activeert

Een detail uit dezelfde week laat zien hoe het pack in de praktijk werkt. CRA is geen veilige afkorting: het kan ook staan voor credit rating agency, de Amerikaanse Community Reinvestment Act of de Canadese Canada Revenue Agency. De assistent laadt het EU-pack niet op een losse verwijzing naar CRA; de vraag zelf moet een duidelijke aanwijzing bevatten dat het om een EU-product gaat. Zo krijgt een bank die vraagt naar haar kapitaalratio's of een belastingvraag over de Canadese belastingdienst geen Europees productveiligheidspack in het antwoord geïnjecteerd. Deze botsingsbeveiliging werd dezelfde week als het pack zelf uitgerold.

Voor wie is dit bedoeld

Fabrikanten van producten met digitale elementen die in de EU worden verkocht, invoerders en distributeurs die deze producten aanvoeren, en beheerders van open-source software die moeten bepalen of de verordening op hen van toepassing is. Ook de GRC-verantwoordelijken en adviseurs die hun vragen beantwoorden, inclusief teams wier ISO 27001-scope nooit productrecht raakte en die nu een rapportageplicht op de kalender zien verschijnen. Het pack staat in de gedeelde framework-registratie, zodat dezelfde verwijzingen via de API en in embeds terugkomen, en heyGRC beantwoordt CRA-vragen met dezelfde verwijzingen.

Twee grenzen blijven in stand. Dit is referentiekennis voor begeleiding, geen juridisch advies, en de antwoorden verwijzen naar de bepalingen waarop ze zijn gebaseerd. En deze post is niet de referentie zelf: het strategische argument, waarom de klok van 2026 de datum van 2027 in jouw planning overtreft, staat in De Cyber Resilience Act is een 2026-probleem, geen 2027-probleem. De volledige verplichtingen en tijdlijn, inclusief de klok van Artikel 71 en de rapportagetabel van Artikel 14, staan in de gids met verplichtingen en tijdlijn van de Cyber Resilience Act. De vraag "is dit überhaupt van toepassing op ons" wordt beantwoord door de CRA-toepassingschecker.