Op 11 september 2026 begint voor fabrikanten van producten met digitale elementen een van de eerste operationele verplichtingen van de Cyber Resilience Act (CRA): actief uitgebuite kwetsbaarheden en ernstige beveiligingsincidenten moeten via het nieuwe centrale meldplatform worden gemeld. Dit is meer dan een nieuwe compliance-deadline. Binnen enkele uren moeten productidentiteit, getroffen markten, technische beoordeling en maatregelen worden samengebracht.
Een digitaal productpaspoort of een productpagina die via een QR-code is gekoppeld, kan helpen om een apparaat eenduidig toe te wijzen en gebruikers later over een update te informeren. Het is echter noch de wettelijke meldroute, noch de juiste opslagplaats voor vertrouwelijke exploitdetails. Fabrikanten moeten daarom nu drie gegevensstromen scheiden: de melding aan autoriteiten, de openbare productinformatie en de interne updategeschiedenis.
De nieuwe aanleiding: richtsnoeren van 27 en 31 juli
De Europese Commissie publiceerde op 27 juli 2026 haar eerste uitgebreide CRA-richtsnoer. Het behandelt onder meer meldplichten, risicobeoordeling, ondersteuningsperioden en wezenlijke wijzigingen. Het richtsnoer is niet bindend, maar concretiseert met 67 voorbeelden hoe bedrijven de verordening in de praktijk kunnen toepassen.
Vier dagen later, op 31 juli, actualiseerde ENISA haar informatie over het Single Reporting Platform. Daarin staan inmiddels de geplande procedure, de voorziene invoervelden en aanwijzingen voor registratie. Het platform moet uiterlijk op 11 september 2026 operationeel zijn; volgens de Commissie lopen de functionele en beveiligingstests al.
De fasering in de tijd is belangrijk: de belangrijkste verplichtingen van de CRA gelden in principe vanaf 11 december 2027. Artikel 14 met de meldplichten geldt echter al vanaf 11 september 2026. Dat wordt zowel bevestigd door artikel 71 van Verordening (EU) 2024/2847 als door het op 31 juli geactualiseerde overzicht van de Commissie over de CRA-meldprocedure.
Drie gegevensruimten in plaats van één overbelast productpaspoort
De CRA-melding en een openbare productpagina dienen verschillende doelen. Wie beide in één dataset afbeeldt, loopt het risico dat het incidentteam te weinig informatie krijgt of dat er te veel gevoelige details op het openbare web terechtkomen.
1. Vertrouwelijke melding aan SRP, CSIRT en ENISA
Het Single Reporting Platform is het wettelijke toegangskanaal. Er moeten twee soorten gebeurtenissen worden gemeld: een actief uitgebuite kwetsbaarheid waarvoor betrouwbare aanwijzingen voor ongeoorloofde exploitatie bestaan, en een ernstig incident dat de beschikbaarheid, authenticiteit, integriteit of vertrouwelijkheid van gegevens of functies aantast.
De melding bevat niet alleen een productaanduiding. ENISA noemt onder meer getroffen lidstaten, een eerste beoordeling, al genomen tegenmaatregelen, mogelijke gebruikersmaatregelen en de gevoeligheid van de informatie als velden. In latere fasen kunnen ernstniveau, gevolgen, informatie over de aanvaller en technische details over de beveiligingsupdate worden opgenomen. Dergelijke informatie hoort niet automatisch op een vrij toegankelijke DPP-pagina te staan.
2. Openbare product- en veiligheidsinformatie
De openbare gegevensstroom beantwoordt andere vragen: Welk product en welke versie heb ik? Wordt die nog ondersteund? Is er een beveiligingsupdate beschikbaar? Wat moet ik als gebruiker concreet doen? Daarvoor kan een stabiele productpagina achter een QR-code of een andere gegevensdrager zinvol zijn.
De openbare pagina moet alleen vrijgegeven informatie tonen: getroffen model- en versiebereiken, beschikbare veilige versie, installatie-instructies, contact voor ondersteuning en publicatietijdstip. Exploitdetails, interne detectieregels, ongepatchte aanvalsroutes of persoonsgegevens over incidenten blijven binnen de beschermde procedure. De beslissing over een openbare waarschuwing ligt niet bij de QR-code: op grond van artikel 17 CRA kan het coördinerende CSIRT het publiek informeren of de fabrikant daartoe verzoeken als dat voor preventie of indamming noodzakelijk is.
3. Interne update- en bewijsgeschiedenis
De derde stroom is het traceerbare werkdossier. Het verbindt product-ID, hardware- en softwareversie, softwarestuklijst, tijdstip waarop de kennis werd verkregen, triagebeslissingen, meldingsfasen, vrijgave van de patch en openbare mededeling. Deze geschiedenis moet wijzigingen versieneren in plaats van eerdere beoordelingen stilzwijgend te overschrijven.
Voor een DPP-bedrijf is dit verschil essentieel: de openbare weergave toont de actuele vrijgegeven toestand; de interne geschiedenis bewijst hoe die tot stand is gekomen. Wie productgegevens al gebeurtenisgestuurd beheert, kan daarvoor hetzelfde principe gebruiken als bij DPP-updates en webhooks: een gebeurtenis start vervolgprocessen, maar elke ontvanger krijgt alleen de velden die voor zijn rol bestemd zijn.
De CRA-klok begint zodra de kennis is verkregen
Artikel 14 werkt met gefaseerde termijnen. Voor een actief uitgebuite kwetsbaarheid is zonder onnodige vertraging, uiterlijk binnen 24 uur nadat de kennis is verkregen, een vroegtijdige waarschuwing vereist. Binnen 72 uur volgt de uitgebreidere kwetsbaarheidsmelding. Het eindverslag moet uiterlijk 14 dagen beschikbaar zijn nadat een corrigerende of beperkende maatregel beschikbaar is.
Bij een ernstig beveiligingsincident gelden eveneens 24 uur voor de vroegtijdige waarschuwing en 72 uur voor de incidentmelding. Het eindverslag volgt binnen één maand na de 72-uursmelding. De termijnen lopen dus niet vanaf de publicatie van een CVE en ook niet vanaf de volgende reguliere release, maar vanaf het moment waarop de fabrikant als geïnformeerd geldt.
Voor de praktijk is een duidelijke procedure aan te bevelen:
- Invoer uit ondersteuning, monitoring, onderzoek of de toeleveringsketen met tijdstempel registreren.
- Product en versie koppelen aan een stabiele interne product-ID.
- Exploitatie of de ernst van het incident laten beoordelen door het verantwoordelijke team.
- De 24-uursdataset met bevestigde minimumgegevens opstellen en via de SRP indienen.
- Technische inzichten tot de 72-uursfase aanvullen zonder de oorspronkelijke stand te verliezen.
- Patch, gebruikersmaatregel en openbare informatie afzonderlijk vrijgeven.
- Eindverslag en interne geschiedenis met elkaar verbinden.
Deze keten moet vóór september als oefening worden doorlopen. ENISA wijst erop dat organisaties hun interne processen en databases kunnen automatiseren, maar dat het platform bij de start geen API zal aanbieden. Daarom is een export- en vierogenproces realistischer dan een ongecontroleerde rechtstreekse integratie.
Eén gemeenschappelijke product-ID, maar gescheiden toegangsrechten
Scheiding betekent niet dat er drie niet-verbonden kopieën moeten worden bijgehouden. De betere aanpak is een gemeenschappelijke, onveranderlijke productreferentie met rolafhankelijke weergaven.
Minimaal moeten de volgende koppelingen beschikbaar zijn:
- interne product-ID en verwijzing naar model, batch of serienummer;
- hardware-, firmware- en softwareversie;
- lidstaten waarin de getroffen uitvoering beschikbaar is gesteld;
- status van de veiligheidsbeoordeling en tijdstip waarop de kennis is verkregen;
- verwijzingen naar de 24- en 72-uursmelding en het eindverslag;
- vrijgegeven gebruikersmaatregel en veilige doelversie;
- publicatiestatus van de openbare productpagina.
De autorisatie moet per veld worden opgevat. Het incidentteam en de CRA-verantwoordelijken hebben het volledige dossier nodig. Ondersteuning en verkoop hebben een vrijgegeven werkinstructie nodig. Gebruikers zien alleen de openbare melding. Een QR-code verwijst daarbij idealiter uitsluitend naar een stabiel productadres; het achterliggende platform bepaalt op basis van status en rol welke informatie wordt verstrekt.
Wat fabrikanten vóór september moeten testen
Een zinvol testscenario vereist geen echte kwetsbaarheid. Kies een verbonden product, een getroffen firmwareversie en drie lidstaten. Simuleer het moment waarop de kennis wordt verkregen op een werkdag en controleer:
- Kan het team binnen 24 uur de productdekking en minimumgegevens bevestigen?
- Is duidelijk wie als vertegenwoordiger via EU Login toegang tot de SRP moet krijgen?
- Kunnen 72-uursgegevens worden toegevoegd zonder vertrouwelijke details openbaar te maken?
- Leidt de vrijgave van de patch tot gecontroleerde gebruikersinformatie in alle vereiste talen?
- Blijft de openbare URL stabiel wanneer versie en maatregelen wijzigen?
- Is traceerbaar wie welke stand wanneer heeft vrijgegeven?
Voor het laatste punt helpt consequente, versiegebaseerde gegevensregistratie. Het qr3-artikel over doorlopende DPP-actualisering toont het basisidee: de identiteit blijft stabiel, terwijl vakinhoudelijke gegevens gecontroleerd worden bijgewerkt. In het CRA-proces komt daar een strengere laag voor vertrouwelijkheid en vrijgave bij.
Conclusie: het productpaspoort is een doorgeefluik, geen meldpunt
De nieuwe richtsnoeren maken de septemberdeadline operationeel concreet. Fabrikanten hoeven geen vertrouwelijke kwetsbaarhedendatabase in hun digitale productpaspoort op te nemen. Ze hebben veeleer een betrouwbare overgang nodig tussen drie duidelijk gescheiden gebieden: melding aan autoriteiten, intern bewijs en vrijgegeven gebruikersinformatie.
Een gemeenschappelijke product-ID houdt deze gebieden bij elkaar. Rollen, vrijgaven en versiebeheer voorkomen dat vertrouwelijke details naar buiten komen of dat gebruikers te laat over een beschikbare maatregel worden geïnformeerd. De QR-code blijft daarbij nuttig, maar bewust onopvallend: hij leidt permanent naar de juiste productcontext. De eigenlijke CRA-compliance ontstaat in de processen daarachter.
