CRA-conformiteit: Lessen uit ENISA's EUDI Wallet-schema [2026]

Op 3 april 2026 publiceerde ENISA concept v0.4.614 van het EU Digital Identity Wallet-certificeringsschema: 110 pagina's, een openbare consultatie die sluit op 30 april en een webinar op 8 april. Dit is het eerste cyberbeveiligingscertificeringsschema voor ICT-diensten dat ooit is opgesteld in het kader van de EU Cybersecurity Act. Het EUCC dekt al ICT-producten; dit schema breekt nieuw terrein door hetzelfde kader toe te passen op diensten. Het richt zich op digitale identiteitswallets, niet op producten in het algemeen. Maar de bewijs­normen, verplichtingen voor de toeleveringsketen en de conformiteitsinfrastructuur die het vastlegt, zullen bepalend zijn voor de manier waarop alle EU-cyberbeveiligingscertificering werkt, inclusief de schema's die uiteindelijk CRA-producten zullen reguleren. Hier leest u wat het schema vereist, waar CRA expliciet wordt aangehaald, en wat fabrikanten van producten in de gaten moeten houden.

Samenvatting

• Concept v0.4.614 gepubliceerd op 3 april 2026; openbare consultatie open tot 30 april, webinar op 8 april
• Eerste CSA-certificeringsschema voor ICT-diensten binnen het kader van de EU Cybersecurity Act (het EUCC dekt al ICT-producten; dit is het eerste schema voor diensten)
• Uitsluitend zekerheidsgraad "hoog": zelfbeoordeling is expliciet verboden voor alle wallet-aanvragers
• SBOM verplicht in machineleesbaar formaat als onderdeel van het evaluatiebewijs­pakket
• CRA Bijlage I expliciet aangehaald voor vereisten inzake kwetsbaarheidsbeheer
• ISO 27001 onvoldoende verklaard als enig bewijs van conformiteit
• Jaarlijkse surveillance inclusief penetratietesten; maximale certificaatgeldigheidsduur van 5 jaar zonder afwijkingsmogelijkheid
• Mobiele wallet-apps zijn CRA-producten wanneer zij door een commerciële entiteit op de markt worden gebracht (p.9)

Waarom een Wallet-schema relevant is voor fabrikanten van producten

Het EUDI Wallet-schema en de CRA opereren op verschillende juridische objecten. De CRA reguleert producten met digitale elementen die op de EU-markt worden gebracht. Het wallet-schema reguleert een specifiek type dienst: de EUDI Wallet-oplossing. Dit zijn niet dezelfde regelgeving.

Maar ze delen dezelfde juridische basis.

Artikel 24 en artikel 27 van de CRA verwijzen beide naar EU-cyberbeveiligingscertificeringsschema's in het kader van de Cybersecurity Act als alternatieve conformiteitsroute. Een product dat valt onder een toepasselijk CSA-schema kan certificering onder dat schema gebruiken om conformiteit met de overeenkomstige essentiële CRA-eisen aan te tonen. Een dergelijk schema dat CRA-producten dekt, bestaat nog niet. Het EUDI Wallet-schema is het eerste dat wordt opgesteld, en de keuzes die ENISA hier maakt, op het gebied van bewijs­formaten, vereisten voor de toeleveringsketen en evaluatiemethodologie, zullen worden overgenomen.

Het schema trekt op pagina 9 een duidelijke jurisdictionele grens. De tekst is direct: de CRA "is niet rechtstreeks van toepassing op EUDI-wallets zoals die gecertificeerd worden in het kader van het onderhavige schema, omdat zij gecertificeerd worden als ICT-diensten, niet als ICT-producten." Voor de meeste EUDIW-deelnemers is de CRA geen parallelle verplichting. Het schema heeft selectief geleend van de CRA-methodologie, maar dat lenen strekt de reikwijdte van de verordening niet uit.

De uitzondering is mobiel. Wanneer de wallet-instantie een mobiele applicatie is die door een commerciële entiteit op de markt wordt gebracht, is de CRA van toepassing op die applicatie als een product met digitale elementen. Voor bedrijven die een mobiele wallet-app commercieel distribueren, zijn twee regimes tegelijkertijd van toepassing. De CRA regelt de conformiteitsverplichtingen vóór het op de markt brengen en de kwetsbaarheidsbeheerverplichtingen na het op de markt brengen van het product. Het wallet-schema regelt de continue servicecertificering. Ze stapelen zich op, maar uitsluitend in dit specifieke scenario. Een organisatie die een wallet-oplossing puur als ICT-dienst aanbiedt, heeft via dit schema geen CRA-verplichting.

Het gedeelde raamwerk omvat de CSA en het European Common Criteria-gebaseerde evaluatiekader (ECCF), CEN TS 18072 voor wallet-servicevereisten en het EUCC (EU Common Criteria-gebaseerd cyberbeveiligingscertificeringsschema) als compositionele basis voor hardware- en platformcomponenten. Die infrastructuur is niet uitsluitend voor wallets gebouwd. Het is het skelet dat toekomstige CRA-gerelateerde schema's zullen gebruiken.

Een verdere grens: het schema stelt dat EUDIW-certificaten "niet geschikt zullen zijn voor de veronderstelling van conformiteit" onder de CRA (p.9). Zelfs voor mobiele wallet-apps waarbij de CRA wel van toepassing is, voldoet het EUDIW-certificaat niet aan de CRA-conformiteit. De twee compliance-trajecten zijn afzonderlijk en moeten elk onafhankelijk worden doorlopen.

Commerciële distributeurs van mobiele wallets: twee onafhankelijke compliance-trajecten. Als u een commerciële entiteit bent die een mobiele wallet-app op de EU-markt brengt, is de CRA van toepassing op die app als een product met digitale elementen. U heeft een CRA-conformiteitsbeoordeling nodig voor het product en een EUDIW-certificering voor de wallet-dienst. Geen van beide voldoet aan de andere. Beide moeten onafhankelijk worden doorlopen en worden onderhouden onder afzonderlijke toezichtscycli. Als u de wallet puur als ICT-dienst aanbiedt zonder afzonderlijk gedistribueerde mobiele app, is de CRA via dit schema niet op u van toepassing.

Als uw producten uiteindelijk onderworpen zullen zijn aan een CSA-certificeringsschema via de route van artikel 27 van de CRA, is het wallet-schema uw duidelijkste vooruitblik op hoe die evaluatie eruit zal zien. De methodologieën die hier worden gevalideerd, zijn de methodologieën waarmee u te maken krijgt.

Raadpleeg de besliswijzer voor conformiteitsbeoordeling voor de huidige CRA-module-opties zolang CSA-schema's nog in voorbereiding zijn.

De certificeringsinfrastructuur vandaag

Het CRA-conformiteitslandschap kent momenteel vier niveaus. Standaardproducten (de meerderheid) kunnen gebruik maken van Module A-zelfbeoordeling. Belangrijke Klasse I-producten kunnen Module A gebruiken als zij geharmoniseerde normen toepassen, of naar een aangemelde instantie gaan. Belangrijke Klasse II- en kritieke producten vereisen evaluatie door derden, waarbij kritieke producten ook een toepasselijk CSA-schema vereisen als dat bestaat.

Het hiaat: er bestaat momenteel geen CSA-schema dat de essentiële CRA-vereisten dekt. Dat betekent dat de route van artikel 27, waarbij CSA-certificering de veronderstelling van conformiteit met de CRA triggert, voor geen enkel product nog begaanbaar is. Het bestaat in de verordening, maar niet in de praktijk.

Het EUDI Wallet-schema dicht dat hiaat niet. Maar het stelt het model vast.

Het schema verplicht uitsluitend de zekerheidsgraad "hoog", zonder lagere niveaus toe te staan. De redenering in het document is direct: "alle functies van EUDI-wallets zijn beveiligingsfuncties, sommige van kritieke gevoeligheid" (p.17). Het schema oordeelt dat geen enkele wallet-functie laagdrempelig genoeg is om zelfbeoordeling toe te staan.

Zelfbeoordeling wordt niet alleen ontmoedigd. Het is geblokkeerd: "Een conformiteitszelfbeoordeling... mag niet worden toegestaan" (p.18).

De redenering loopt parallel aan de CRA-aanpak voor Belangrijke en Kritieke producten. Hogere inzet rechtvaardigt strengere conformiteitsroutes. De specifieke drempel verschilt per regime, maar het principe is identiek. Wanneer ENISA toekomstige CSA-schema's opstelt voor CRA-productcategorieën, verwacht u dezelfde redenering toegepast op producten uit Bijlage III en IV.

Belangrijk: De koppeling tussen CRA-productcategorieën en toekomstige CSA-schema's is onze analytische gevolgtrekking, geen expliciete uitspraak in het EUDIW-schema. Het schema dekt uitsluitend wallets.

Zie de productclassificatiegids voor de huidige classificatieregels voor producten onder de CRA.

Wat het schema vereist van particuliere bedrijven

Het schema definieert een levenscyclus van vier fasen voor aanvragers.

Voorbereiding omvat het samenstellen van documentatie, risicoanalyse en het verzamelen van zekerheids­bewijs voor componenten. Dit is waar uw toeleveringsketen­bewijs een harde vereiste wordt, niet een inspanning naar beste vermogen.

Eerste evaluatie omvat ontwerpbeoordeling en afhankelijkheidsanalyse. Een IT Security Evaluation Facility (ITSEF) beoordeelt uw architectuur, uw vertrouwensmodel en de conformiteitsstatus van elke component waarvan uw wallet afhankelijk is.

Tweede evaluatie omvat functionele tests, penetratietesten en kwets­baarheids­beoordeling van de opgegeven beveiligingsfuncties van de wallet. Dit is geen documentatiebeoordeling. Testers onderzoeken het systeem actief.

Onderhoud gaat door na afgifte van het certificaat. Jaarlijkse surveillance is verplicht, inclusief penetratietesten op elk jubileum. Dit is geen afvinkpunt. Het zijn terugkerende evaluatiekosten die zijn ingebouwd in de levenscyclus van het certificaat.

Het certificaat is 5 jaar geldig. De limiet is hard. Het schema stelt dat geen afwijking mogelijk is (p.26). Wanneer het certificaat verloopt, moet de wallet worden gedeactiveerd. Er is geen respijtperiode om over te onderhandelen.

De verplichting inzake informatie-integriteit is scherper dan de meeste compliance-raamwerken. Het verstrekken van onjuiste of onvolledige informatie aan de certificeringsinstantie wordt geclassificeerd als niet-naleving, niet als non-conformiteit (p.23-24). Het onderscheid doet ertoe: non-conformiteit leidt tot een herstelproces. Niet-naleving kan leiden tot schorsing of intrekking op andere gronden.

Na kennisgeving van een non-conformiteit heeft u 30 dagen om te beoordelen of de bevinding materieel is (p.38). Die termijn begint niet wanneer u het probleem ontdekt. Ze begint wanneer de certificeringsinstantie u hierover informeert. Organisaties die geen intakeprocedures hebben voor conformiteitskennisgevingen, verbranden dat venster voordat iemand de e-mail heeft gelezen.

Schorsing is openbaar. Het schema vereist verplichte publieke bekendmaking wanneer een certificaat wordt geschorst (p.40). De maximale schorsingsperiode is 42 dagen, verlengbaar tot 1 jaar door de nationale cyberbeveiligingscertificeringsautoriteit (NCCA). Dit is geen interne aangelegenheid. Uw klanten en vertrouwende partijen zullen het zien.

Documentenbewaring strekt zich uit tot 5 jaar na het verstrijken van het certificaat, inclusief fysieke productexemplaren waar van toepassing (p.49). Voor softwareproducten met een certificaat van 5 jaar betekent dat een minimale bewijs­keten van 10 jaar.

Het CRA-model vereist conformiteitsbeoordeling vóór het op de markt brengen en kwetsbaarheidsbeheer na het op de markt brengen. Het wallet-schema vereist continue conformiteit met jaarlijkse penetratietesten en surveillance gedurende de volledige levensduur van het certificaat. Voor bedrijven die aan beide zijn onderworpen, zijn de post-certificerings­verplichtingen van het wallet-schema veeleisender dan die van de CRA in omvang en frequentie.

Uw toeleveringsketen zit nu in de certificeringsketen

Het wallet-schema maakt gebruik van een compositioneel evaluatiemodel met drie afzonderlijke lagen.

De Wallet Secure Cryptographic Application (WSCA) en het onderliggende hardwareplatform worden geëvalueerd onder EUCC, het EU Common Criteria-schema. Dit dekt de hardware-beveiligingsmodules, beveiligde elementen en vertrouwde uitvoeringsomgevingen waarvan de wallet afhankelijk is.

De wallet-instantie (de software die op het apparaat van de gebruiker draait) wordt geëvalueerd onder FiTCEM, de Functional IT Common Evaluation Method, die software-evaluatie afhandelt waar hardware-scheiding niet haalbaar is.

Wallet-services (server­zijdige componenten, identiteitsuitgifte, vertrouwende partij-interfaces) worden beoordeeld aan de hand van CEN TS 18072-vereisten.

Elke laag heeft zijn eigen evaluatietraject. Uw certificaat is afhankelijk van de certificaten eronder.

Het schema is expliciet over de last die dit op aanvragers legt: u moet "de zekerheids­documentatie voor de componenten verzamelen, wat kan inhouden dat sommige ervan gecertificeerd moeten worden" (p.14). "Kan inhouden" is een understatement. Als een component de vereiste zekerheids­documentatie mist, kan uw evaluatie niet worden afgerond.

Openbaarmaking van onderaannemers is uitputtend. Elke onderaannemer moet worden vermeld, samen met de mate van conformiteitsbeoordeling die op zijn bijdrage is toegepast (p.78). Er is geen generieke categorie "wij werken met gerenommeerde leveranciers". Elke derde partij heeft gedocumenteerd conformiteits­bewijs of niet, en dat hiaat is uw probleem bij de evaluatie.

Meldingen van upstream-kwetsbaarheden zijn in beide richtingen verplicht. Wanneer een kwetsbaarheid een ICT-product treft dat ten grondslag ligt aan een samengestelde ICT-dienst, moet de houder van het EUCC-certificaat afhankelijke EUDIW-certificaathouders informeren (p.43). Dit is een specifieke verplichting die gekoppeld is aan kwetsbaarheidsmeldingen, niet een algemene melding voor elke certificaatwijziging. Als uw leverancier van componenten een kwetsbaarheid identificeert en u daarvan niet op de hoogte stelt, handelen zij in strijd hiermee. Als zij u wel informeren, heeft u een beoordelingsvenster van 30 dagen om te beoordelen of de bevinding materieel is.

Continue monitoring stopt niet bij uw organisatiegrenzen. Wanneer een basiscomponentcertificaat wordt bijgewerkt of vervangen, moet de CAB een differentiële afhankelijkheidsanalyse uitvoeren op de wijzigingen (p.84). Een significante update van een afhankelijkheid leidt tot een formele CAB-beoordeling of uw certificeringsomvang is beïnvloed.

Cloudproviders zijn niet vrijgesteld. Het schema classificeert infrastructuur "geleverd door provider" (p.61) als een component die in aanmerking komt voor beoordeling van de toeleveringsketen. Als uw wallet-service op een cloudplatform draait, is de conformiteitsstatus van dat platform onderdeel van uw bewijs­pakket.

De propagatieregel is significant: als er een correctie van een non-conformiteit uitstaat in het certificeringsrapport van een basiscomponent, moet de CAB de impact ervan op de samengestelde ICT-dienst beoordelen (p.84). Als die impact materieel is, kan de samengestelde evaluatie niet worden afgerond totdat de non-conformiteit is opgelost. Dit is niet automatisch — het hangt ervan af of de non-conformiteit als materieel voor uw dienst wordt beschouwd. Maar een ernstige openstaande non-conformiteit in het certificeringsrapport van uw WSCA-leverancier kan uw evaluatie blokkeren.

Dit is geen hypothetisch toekomstmodel voor de CRA. De SBOM-verplichting van de CRA (Bijlage I Deel II) en de vereisten voor kwetsbaarheidsbewaking (artikelen 13 en 14) werken op hetzelfde principe. Het wallet-schema laat zien hoe die verplichtingen in de praktijk werken binnen een formeel certificeringskader: gedocumenteerd, bilateraal en blokkerend.

Belangrijk: De meldingsregels voor de toeleveringsketen en propagatieregels die hier worden beschreven, gelden voor het EUDIW-certificeringsschema. De parallelle verplichtingen van de CRA staan in artikel 13 en artikel 14. Hoe zij in de praktijk samenwerkingen voor producten die aan beide regimes zijn onderworpen, is nog niet vastgelegd in richtsnoeren.

Zie voor de interactie tussen de toeleveringsketen­verplichtingen van de CRA en toekomstige CSA-certificeringsschema's Cybersecurity Act 2. Zie voor de praktische mechanismen van het genereren en onderhouden van SBOM's de SBOM-generatiegids.

Wat uw bestaande certificeringen werkelijk waard zijn

De meeste fabrikanten gaan ervan uit dat hun bestaande certificeringen gewicht hebben in nieuwe schema's. Voor EUDIW hangt het antwoord volledig af van welke certificering u heeft en hoe zorgvuldig uw auditor de reikwijdte ervan heeft gekoppeld aan de criteria van het schema.

Het schema behandelt dit direct in paragraaf 5.3. Het staat CAB's toe om te vertrouwen op eerder werk, maar de voorwaarden zijn strikt. Een brugletter is vereist wanneer er een kloof is tussen de rapportageperiode van de eerdere audit en de huidige evaluatie (p.85). Gedeeltelijke steun is gebruikelijk; volledige steun is zeldzaam.

De bevinding over ISO 27001 verdient directe aandacht. Het schema stelt onomwonden: "het biedt op zichzelf onvoldoende zekerheid dat de individuele beheersmaatregelen die zijn geselecteerd in de verklaring van toepasselijkheid zijn ontworpen en werken op het niveau van strengheid dat door dit schema wordt vereist" (p.88).

De redenering hier is van toepassing buiten EUDIW. ISMS-certificering bevestigt de volwassenheid van processen en dat er een managementsysteem bestaat. Het bevestigt niet dat individuele beheersmaatregelen werken op het zekerheids­niveau dat een specifiek schema vereist. Dezelfde redenering zal gelden onder de CRA wanneer geharmoniseerde normen worden vastgesteld.

Als uw SOC 2 Type II-audit is afgebakend zonder EU-cyberbeveiligingscriteria in gedachten, kwalificeert die niet voor voorwaardelijke steun. U heeft dan een geverifieerde koppeling van uw auditor nodig. Plan dat gesprek nu, voordat u een certificeringstermijn heeft.

Zie onze vergelijkingsgids ISO 27001 voor een diepere vergelijking van wat ISO 27001 werkelijk dekt versus CRA-vereisten.

Belangrijk: Het EUDIW-schema is specifiek voor de context van de wallet-infrastructuur. CRA-geharmoniseerde normen kunnen andere drempels stellen voor wat eerdere certificeringen aantonen. Behandel deze analyse als richtinggevend, niet als definitief.

Kwetsbaarheidsbeheer gaat verder dan de CRA

De vereisten voor kwetsbaarheidsbeheer van het EUDIW-schema putten expliciet uit de CRA. Het schema stelt: "Deze sectie... put grotendeels uit andere regelgeving, zoals artikel 55 van de CSA... en ook uit de CRA" (p.43). Die herkomst is relevant, omdat de vereisten een gedeelde structuur hebben maar op de mechanismen uiteen­lopen.

Over SBOM: het schema vereist machineleesbaar formaat (p.43), in lijn met CRA Bijlage I Deel II. Dit is geen nieuw concept als u al CRA-verplichtingen bijhoudt, maar het bevestigt dat SBOM als technisch artefact een verwachte standaard wordt in EU-schema's, niet alleen CRA-specifiek.

Beveiligingsupdates moeten afzonderlijk van functionele updates worden geleverd (p.43). Dit is operationeel significant. Een gecombineerde release die kwetsbaarheden verhelpt en functies toevoegt, schept onduidelijkheid over wat gebruikers accepteren. Het schema behandelt ze als afzonderlijke verplichtingen.

Uw CVD-beleid moet openbaar zijn en in lijn met EN ISO/IEC 29147 (p.47). Dit is geen beleids­document dat weggestopt zit in een compliance-map. Het moet vindbaar, actueel en gestructureerd zijn conform de norm.

Over impactanalyse: CVSS-scores alleen zijn onvoldoende. Het schema vereist context-specifieke analyse (p.44). Een CVSS 9.8 in de ene implementatiecontext kan een CVSS 4.0 zijn in de uwe, maar u moet die redenering documenteren, niet alleen beweren.

De meest operationeel significante verplichting: een materiële kwets­baarheid zonder herstelpad leidt tot intrekking van het certificaat (p.45). Dit schept een directe koppeling tussen uw patch­ritme en uw certificeringsstatus. De klok stopt niet bij de beoordeling.

De vergelijking met de CRA is hier relevant. De CRA vereist melding aan ENISA binnen 24 uur na het ontdekken van een actief uitgebuite kwets­baarheid. EUDIW gebruikt "zonder onnodige vertraging" via de CAB-keten. Andere klok, andere route, vergelijkbare intentie. Als u processen bouwt voor het ene, ontwerp ze dan om aan beide te voldoen.

Zie onze post over ENISA-kwetsbaarheidsmeldingen voor een uiteenzetting van de specifieke 24-uursmeldingsverplichting. Zie het CVD-beleidssjabloon voor een startpunt voor uw CVD-beleid.

Wat bevestigd is versus onze analyse

Vijf zaken om in de gaten te houden

Het schema is nog niet definitief. De consultatietermijn van 30 april betekent dat wijzigingen nog mogelijk zijn. Dit zijn de gebieden waar de uitkomst uw planning materieel beïnvloedt.

1. Vereisten voor bewijs­formaten: Het schema verwijst naar machineleesbare SBOM's en de structuur van technische bestanden, maar standaardiseert nog niet volledig wat "voldoende" er in de praktijk uitziet. CAB's zullen dit interpreteren. Tot zij dat doen, bouwt u richting het meest gestructureerde formaat dat u kunt verdedigen.

2. CAB-capaciteit: Autorisatie vereist zowel accreditatie als goedkeuring van de NCCA, plus voltooiing van een pilotevaluatie (p.30). Het opstart­probleem is reëel. Als gekwalificeerde CAB's schaars zijn wanneer het schema van kracht wordt, lopen termijnen uit ongeacht hoe goed voorbereid u bent. Dit ligt niet binnen uw controle, maar het beïnvloedt uw planningsaannames.

3. Wederzijdse erkenning: Het schema neemt de EUCC-bepalingen voor wederzijdse erkenning met schema's van derde landen niet over (p.52). Wederzijdse erkenning van derde landen wordt expliciet opengelaten voor een latere fase: "deze voorwaarden kunnen in een latere fase worden toegevoegd." Dit is onopgelost, niet definitief beslist. Reken er niet op dat uw Amerikaanse certificeringen hier geldig zijn, maar dit is een actieve open vraag en geen permanente afwijzing.

4. Nationale schema's vervallen: Bestaande nationale schema's hebben een venster van 12 maanden na inwerkingtreding om geldig te blijven (p.56). Als uw huidige certificering is afgegeven onder een nationaal schema, moet u weten wanneer dat venster sluit.

5. Openstaande vragen: Eigenaarschap van penetratietesten, drempels voor aanvalspotentie en de diepte-kwalificatoren voor kwetsbaarheidanalyse blijven onopgelost in de huidige tekst (p.97-98). Dit zijn geen redactionele hiaten. Ze beïnvloeden hoe u beoordelingen afbakent en begroot.

Wat wij zeker weten

• De CRA wordt expliciet aangehaald als bron voor de vereisten van het schema.
• SBOM in machineleesbaar formaat is vereist.
• ISO 27001 alleen voldoet niet aan de organisatorische beheersmaatregel­vereisten.
• Zelfbeoordeling is niet beschikbaar op enig zekerheids­niveau voor EUDIW-componenten.
• De geldigheid van het certificaat is beperkt tot 5 jaar.

Onze analyse (niet bevestigd)

• CRA-conformiteitsbeoordelings­schema's zullen waarschijnlijk vergelijkbare patronen volgen wat betreft SBOM-vereisten, CVD-beleid en de ontoereikendheid van ISO 27001 als enige maatstaf. Het EUDIW-schema geeft een vooruitblik op hoe ENISA over deze verplichtingen denkt.
• De druk op certificering van de toeleveringsketen zal toenemen. De vereisten op component­niveau van EUDIW suggereren dat downstream-fabrikanten van upstream-leveranciers zullen gaan verlangen dat zij onafhankelijke certificeringen bezitten in plaats van enkel zelfverklaringen.
• SOC 2-koppeling is een reële kans. Als u nu met uw auditor in gesprek gaat over het structureren van criteria­koppeling aan EU-cyberbeveiligingsvereisten, kunt u uw volgende SOC 2 Type II positioneren voor voorwaardelijke steun in plaats van helemaal opnieuw te beginnen.

Wat niemand nog weet

• Wanneer een CRA-specifiek certificeringsschema zal worden gepubliceerd en hoe de consultatie­tijdlijn eruit ziet.
• Welke geharmoniseerde normen worden aangewezen onder de CRA en welke zekerheids­drempels zij zullen stellen.
• Hoe de nationale CAB-capaciteit zich zal ontwikkelen ten opzichte van de vraag wanneer meerdere schema's tegelijkertijd actief zijn.

Wat fabrikanten nu moeten doen

Het consultatievenster en de definitieve schema­publicatie geven u een afgebakend venster om u voor te bereiden. Dit zijn concrete stappen, geen algemeen advies.

• Begrijp uw conformiteitsbeoordelingsroute. De zekerheids­niveaus van het schema corresponderen met verschillende productcategorieën. Wat op u van toepassing is, is niet altijd vanzelf­sprekend. Gebruik een gestructureerd beslissingsproces voordat u aanneemt dat u uw route kent. Begin met onze besliswijzer voor conformiteitsbeoordeling.

• Bouw bewijs nu op. SBOM's, risicoanalyses, beleid voor kwets­baarheids­openbaarmaking en technische bestanden kosten tijd om correct te produceren. Als u begint tijdens de consultatieperiode, kunt u itereren voordat een CAB om ze vraagt.

• Ga er niet van uit dat ISO 27001 u dekt. Het schema is expliciet. Als uw compliance-positie is gebouwd op ISO 27001 als proxy voor cyberbeveiligingszekerheid, heeft u een hiaat. Bepaal welke beheersmaatregelen onafhankelijke verificatie vereisen.

• Structureer uw volgende SOC 2 met EU-criteria­koppeling in gedachten. Als u toe bent aan een SOC 2-verlenging, spreek dan met uw auditor voordat de afbakening begint. Gedocumenteerde criteria­koppeling aan EUDIW- (en uiteindelijk CRA-)vereisten is wat een Type II omzet van gedeeltelijke naar voorwaardelijke steun.

• Volg het consultatieproces. Het webinar van 8 april en de schriftelijke deadline van 30 april zijn de laatste formele inbreng­punten voordat het schema naar definitief­wording beweegt. Als het schema uw producten betreft, dient u opmerkingen in of volgt u op zijn minst welke wijzigingen er worden aangebracht.

• Breng uw toeleveringsketen in kaart. Bepaal welke upstream-componenten vallen onder de reikwijdte van het schema. Als een leverancier geen certificering kan aantonen voor een component die u integreert, wordt dat hiaat uw probleem bij de beoordelingstijd.

Hoe CRA Evidence helpt

CRA Evidence ondersteunt de documentatie- en procesinfrastructuur die EUDIW- en CRA-beoordelingen vereisen:

• SBOM-beheer: Genereer, bewaar en exporteer SBOM's in machineleesbare formaten in lijn met de vereisten van CRA Bijlage I Deel II.
• VDP met CVD-workflow: Publiceer en beheer uw kwets­baarheids­openbaarmakings­beleid met een gestructureerde intake- en responswerkstroom in lijn met EN ISO/IEC 29147.
• ENISA-melding bijhouden: Volg de meldingsvensters van 24 uur, 72 uur en 14 dagen met audit-klare records voor elke melding.
• Leveranciersportal: Beheer upstream- en downstream-meldingen binnen uw toeleveringsketen, met gedocumenteerd bewijs van communicatie voor technische bestanden.

Bekijk wat CRA Evidence dekt op craevidence.com.

Dit artikel is uitsluitend voor informatieve doeleinden en vormt geen juridisch advies. Voor specifiek compliance-advies raadpleegt u gekwalificeerde juridische bijstand.