CRA-normen in 2026: wat de vertraging betekent voor uw SBOM en kwetsbaarheidsafhandeling
| Interlynk
De geharmoniseerde normen van de CRA zijn vertraagd, maar uw SBOM- en kwetsbaarheidsverplichtingen niet. Dit is de actuele stand van zaken en wat u kunt doen terwijl de normen bijtrekken.
Overzicht
De EU Cyber Resilience Act is van kracht en ver in zijn uitvoeringsfase. De meldplichten gelden sinds 11 september 2026, en de volledige essentiële eisen met CE-markering gelden vanaf 11 december 2027. Daartussen zit de machinerie die compliance voorspelbaar moet maken: de geharmoniseerde normen die fabrikanten een vermoeden van conformiteit geven. Die machinerie loopt achter.
Per oktober 2026 is er geen geharmoniseerde CRA-norm in het Publicatieblad vermeld, en de conceptdeadlines zijn al een keer verschoven. Het is verleidelijk om een normvertraging als ademruimte te lezen. Voor de delen van de CRA die softwareteams het meest raken, de SBOM- en kwetsbaarheidsverplichtingen, is dat niet zo. Die eisen hangen niet af van een afgeronde norm, de meldklok loopt al, en het werk om eraan te voldoen kost maanden.
Dit artikel zet uiteen waar de normen werkelijk staan en wat u kunt afronden terwijl ze bijtrekken.
Waar de CRA staat in oktober 2026
Een korte oriëntatie, want de data voeren het argument.
Hoofdstuk IV, dat de aanmelding van conformiteitsbeoordelingsinstanties regelt, geldt sinds 11 juni 2026. De meldplichten volgden op 11 september 2026: fabrikanten moeten nu actief misbruikte kwetsbaarheden en ernstige incidenten melden aan ENISA en hun nationale CSIRT, en ENISA's centrale meldplatform is live.
De volledige toepassing begint op 11 december 2027. Vanaf die datum moeten producten die op de EU-markt worden aangeboden aan de essentiële eisen voldoen en de CE-markering dragen.
De essentiële eisen zelf staan in de verordening, in Bijlage I. Zij zijn het vaste punt in dit alles. De geharmoniseerde normen scheppen die eisen niet. Ze bieden één ingeslepen route om aan te tonen dat u eraan hebt voldaan.
De vertraging bij de normen
In juli 2026 publiceerde de Commissie een conceptwijziging van het normalisatieverzoek achter de CRA, mandaat M/606, met het voorstel om de conceptdeadlines met ongeveer twee maanden op te schuiven. Volgens het voorstel schuiven de eerste horizontale kernnormen over veilige ontwikkeling en kwetsbaarheidsafhandeling van 30 augustus naar 31 oktober 2026, de productspecifieke verticale normen van 30 oktober naar 31 december 2026, en een verdere set horizontale normen wordt verwacht in oktober 2027.
Behandel deze als voorgestelde, herziene data en niet als vaststaande, en controleer de status van de wijziging voordat u erop plant.
Twee punten tellen meer dan de exacte data. Ten eerste zijn dit deadlines voor normalisatie-instellingen om concepten aan de Commissie te leveren, niet de data waarop een norm bruikbaar wordt voor compliance. Een geleverd concept moet nog worden beoordeeld en dan in het Publicatieblad worden vermeld voordat het iets voor u doet. Ten tweede doorlopen de door ETSI ontwikkelde verticale productnormen nog de openbare raadpleging, waarvan de commentaarvensters sluiten tot medio november 2026. Het beeld is er een van actieve conceptvorming, niet van afgeronde normen.
Wat het vermoeden van conformiteit echt vereist
Dit is het mechanisme dat de vertraging raakt, en de reden waarom het minder dramatisch is dan het klinkt.
Onder Artikel 27 krijgt een fabrikant een vermoeden van conformiteit alleen voor eisen die worden gedekt door een geharmoniseerde norm waarvan de referentie in het Publicatieblad is bekendgemaakt. Geen CRA-norm heeft dat punt bereikt. Totdat er een is, is er geen vermelde norm om conformiteit tegen te veronderstellen, wat een praktisch gevolg heeft voor hoe sommige producten conformiteit aantonen.
Voor belangrijke producten in Klasse I steunt de zelfbeoordelingsroute in Artikel 32 op het toepassen van een geharmoniseerde norm, een gemeenschappelijke specificatie of een kwalificerend Europees cyberbeveiligingscertificeringsschema dat de essentiële eisen dekt. Een geharmoniseerde norm is slechts een van die grondslagen, zodat het ontbreken van een vermelde norm die route beperkt zonder elke Klasse I-fabrikant automatisch naar beoordeling door derden te dwingen. Waar geen van die grondslagen voor een product beschikbaar is, kan in plaats daarvan een route van conformiteitsbeoordeling door derden nodig zijn.
Vallen uw producten in een belangrijke of kritieke categorie, bevestig dan nu uw classificatie en uw beoogde conformiteitsroute, want het antwoord bepaalt uw tijdlijn, kosten en bewijs. Houd zowel het Publicatieblad als de CRA-normalisatiepagina van de Commissie in de gaten voor de vermelding die uw opties daadwerkelijk verandert.
Waarom de vertraging uw SBOM-werk niet stillegt
Een ontbrekende norm verandert hoe u conformiteit aantoont. Het verandert niet wat de verordening u vraagt te bouwen.
De essentiële eisen van de CRA vragen al om de componenten in uw producten te identificeren en te documenteren. Bijlage I, deel II, punt 1 vraagt om een software bill of materials in een gangbaar, machineleesbaar formaat dat ten minste de afhankelijkheden op het hoogste niveau dekt. Deel II vereist ook dat u kwetsbaarheden zonder vertraging afhandelt, mede via beveiligingsupdates, en dat u gecoördineerde kwetsbaarheidsonthulling op orde hebt.
Niets daarvan wacht op een EN-genummerde norm. De normen zullen beschrijven hoe u het uitvoert op een manier die het vermoeden van conformiteit oplevert, maar de verplichting om het te doen staat vandaag al in de verordening.
Hier loont het de formulering "ten minste de afhankelijkheden op het hoogste niveau" zorgvuldig te lezen. Het is een ondergrens, geen doel. Een SBOM die stopt bij de afhankelijkheden op het hoogste niveau haalt het letterlijke minimum en mist toch het meeste wat een aanvaller kan bereiken, omdat de kwetsbare component meestal dieper in de afhankelijkheidsboom zit. Teams die het CRA-minimum als doel behandelen, produceren conforme SBOM's die de kwetsbaarheidsafhandeling niet echt ondersteunen, de andere verplichting pal ernaast.
Het werk dat normonafhankelijk is en daarom nu veilig te doen, is het inhoudelijke werk: productrisicobeoordeling, nauwkeurige SBOM-generatie, technische documentatie en een werkend proces voor kwetsbaarheidsafhandeling en melding. Er vroeg mee beginnen is de enige manier om klaar te zijn, want niets daarvan laat zich opbouwen in de weken voor december 2027.
De meldplicht geldt al
De ene CRA-verplichting die helemaal geen uitstel biedt, is melding. Sinds 11 september 2026 activeert een actief misbruikte kwetsbaarheid in uw product een meldplicht aan ENISA en uw nationale CSIRT, op een krappe klok, via het ENISA-platform.
Die plicht onder druk nakomen hangt af van snel weten of een nieuw bekendgemaakte kwetsbaarheid aanwezig en misbruikbaar is in een geleverd product en welke versies getroffen zijn. Dat is een SBOM-vraag en een misbruikbaarheidsvraag voordat het een meldvraag is. Een onderhouden SBOM samen met misbruikbaarheidsbeoordelingen, vastgelegd als VEX, is wat u in staat stelt om in uren te antwoorden in plaats van de analyse vanaf nul te reconstrueren terwijl de klok al loopt.
De inventaris en de beoordelingen ondersteunen de analyse. U hebt nog steeds een proces nodig dat bepaalt wanneer Artikel 14 wordt geactiveerd, verantwoordelijkheid toewijst en de melding op tijd indient.
Wat u nu moet doen
Terwijl de normen worden afgerond, zijn de productieve stappen de stappen die standhouden ongeacht de uiteindelijke tekst:
Bouw een nauwkeurige SBOM voor elk product in scope en ga voorbij de ondergrens van het hoogste niveau naar de transitieve componenten waar de echte blootstelling zit.
Zet een kwetsbaarheidsafhandelingsproces op en koppel het aan het reeds actieve ENISA-meldpad.
Houd misbruikbaarheidsbeoordelingen actueel zodat een nieuwe CVE geen brandoefening wordt.
Bekijk de verticale ETSI-concepten en dien commentaar in voordat de raadplegingsvensters sluiten, als uw producten worden geraakt.
Bevestig uw productclassificatie en beoogde conformiteitsroute.
Volg het Publicatieblad in plaats van de conceptkalender, want de vermelding is het moment waarop uw opties veranderen.
Waar Interlynk past
Interlynk werkt aan de twee delen hiervan die het lastigst goed te doen en het meest tijdrovend op te bouwen zijn.
Het eerste is generatie. lynkctl genereert build-bewuste SBOM's voor embedded en firmware software en legt de ingevoegde, statische en SDK-componenten vast die een manifest op het hoogste niveau nooit registreert. Die diepte is wat een CRA-minimum-SBOM omzet in een die de kwetsbaarheidsafhandeling echt kan ondersteunen.
Het tweede is operatie. Het Interlynk-platform neemt SBOM's en CBOM's op, beoordeelt ze op volledigheid en kwaliteit, voert een risicobeoordeling van componenten uit tegen kwetsbaarheidsdata, beheert VEX-uitspraken en stelt belanghebbenden op de hoogte wanneer de blootstelling verandert. Dat is de capaciteit die de meldplicht uit Artikel 14 stilzwijgend veronderstelt.
Het platform werkt met de SBOM en CBOM die het krijgt aangereikt en houdt generatie en beoordeling netjes gescheiden.
Conclusie
De geharmoniseerde normen van de CRA lopen achter, en dat telt voor de mechaniek van het aantonen van conformiteit. Het verandert niet de inhoud van wat de verordening softwareteams vraagt, en het legt geen meldplicht stil die al van kracht is.
De fabrikanten die de komende veertien maanden goed doorkomen, zijn degenen die de vertraging gebruikten om het fundamentele werk goed te leggen: volledige SBOM's, echte kwetsbaarheidsafhandeling, een werkend meldpad. De normen zullen komen en de voorkeursmanier beschrijven om het aan te tonen. Het werk dat ze beschrijven, is werk dat het waard is nu te beginnen.
Bronnen
Verordening (EU) 2024/2847 (Cyber Resilience Act), Publicatieblad
cyberresilienceact.eu, "Current State of Play and Timeline (2026)"
cyberresilienceact.eu, "CRA standardisation deadlines pushed back two months"
Over Interlynk. Interlynk helpt teams SBOM's te genereren, te beheren en te operationaliseren in de software-toeleveringsketen. lynkctl genereert build-bewuste SBOM's voor embedded en firmware software en legt ingevoegde, statische en SDK-componenten vast met precieze identifiers. Het Interlynk-platform neemt SBOM's en CBOM's op, beoordeelt ze op volledigheid en kwaliteit, voert risicobeoordelingen van componenten uit, beheert VEX-uitspraken en stelt teams op de hoogte wanneer de blootstelling verandert.
Dit artikel is informatief en vormt geen juridisch of compliance-advies. De uitvoering, normen en officiële richtsnoeren van de CRA evolueren; verifieer de actuele eisen, deadlines en uw productclassificatie aan de hand van de primaire bronnen en uw eigen juridisch adviseur.