Sinds 11 september 2026 moet een fabrikant die kennis krijgt van een actief uitgebuite kwetsbaarheid in een product dat hij op de EU-markt in de handel heeft gebracht, binnen 24 uur een vroegtijdige waarschuwing indienen. Toch noemt de Cyber Resilience Act, Verordening (EU) 2024/2847, cryptowallets nergens.
De klok van artikel 14 gaat lopen op het moment dat de fabrikant kennis krijgt. Vanaf 11 december 2027 moeten fabrikanten bovendien de beveiliging van hun product op doeltreffende en regelmatige wijze testen en evalueren (bijlage I, deel II, punt 3); voor een product dat vóór die datum in de handel is gebracht, geldt dat alleen als het product vanaf die datum ingrijpend wordt gewijzigd (artikel 69, lid 2). In onze lezing raakt die plicht aan de vraag of die kennis voortkomt uit uw eigen tests of uit de exploit van een ander. Zie The Machines Are Reading the Code.
Deze notitie is bedoeld voor makers van hardwarewallets, walletsoftware, bewaarsoftware en betaalapparaten. Ze legt uit welke toets bepaalt of een product binnen het toepassingsgebied valt, wat de 24 uur veronderstellen, wat december 2027 toevoegt en waar een onafhankelijke adversariële review past. Ze is geen juridisch advies en stelt niet vast of uw product binnen het toepassingsgebied valt.
Valt een wallet binnen het toepassingsgebied?
Het uitgangspunt is de definitie van een product met digitale elementen in de verordening: “een software- of hardwareproduct en zijn oplossingen voor gegevensverwerking op afstand, met inbegrip van software- of hardwarecomponenten die afzonderlijk in de handel worden gebracht” (artikel 3, punt 1).
De volgende vraag is of dat product op de markt wordt aangeboden. De definitie luidt: “het in het kader van een handelsactiviteit, al dan niet tegen betaling, verstrekken van een product met digitale elementen met het oog op distributie of gebruik op de markt van de Unie” (artikel 3, punt 22). Artikel 2, lid 1, voegt een voorwaarde toe: de verordening is van toepassing op zulke producten “waarvan het beoogde doel of het redelijkerwijs voorzienbaar gebruik een directe of indirecte logische of fysieke gegevensverbinding met een apparaat of netwerk omvat”. In onze lezing voldoen een hardwarewallet die verbinding maakt met een telefoon of computer, en walletsoftware die een netwerk bereikt, daar doorgaans aan. Een air-gapped apparaat dat alleen via een QR-code of een geheugenkaart gegevens uitwisselt, kan er toch aan voldoen: artikel 3, punt 9, definieert een fysieke verbinding als een verbinding die met behulp van fysieke middelen tot stand wordt gebracht, “onder meer via elektrische, optische of mechanische interfaces”, en artikel 3, punt 10, omvat een indirecte verbinding die tot stand komt “als onderdeel van een groter systeem dat een directe verbinding kan maken met dat apparaat of netwerk”. Of een bepaald apparaat eraan voldoet, is een vraag voor een juridisch adviseur.
Voor walletmakers roepen deze definities verschillende vragen op. De bespreking hieronder geeft onze lezing; voor de toepassing ervan op een bepaald product is juridisch advies nodig.
Hardwarewallets
Een hardwarewallet die in de EU wordt verkocht, zal vaak passen in de omschrijving van een hardwareproduct met software erin, verstrekt in het kader van een handelsactiviteit. Of uw apparaat aan de juridische toets voldoet, moet nog steeds worden vastgesteld.
De firmware ervan maakt doorgaans deel uit van het product. Een begeleidende app roept een verdere vraag op: hoort die bij hetzelfde product, of is het een zelfstandig product?
Walletsoftware en handelsactiviteit
Bij walletsoftware draait de vraag erom of die in het kader van een handelsactiviteit op de markt wordt aangeboden (artikel 3, punt 22). Overweging 18 zegt dat de levering van producten met digitale elementen die als vrije en opensourcesoftware worden aangemerkt en die niet door hun fabrikanten te gelde worden gemaakt, niet als een handelsactiviteit mag worden beschouwd.
Vaststellen wie de fabrikant is, is een afzonderlijke stap. Artikel 3, punt 13, wijst de persoon aan die het product ontwikkelt of vervaardigt, of dat werk laat doen, en het onder zijn eigen naam of merk in de handel brengt, “tegen betaling, met een verdienmodel of gratis”.
Volgens overweging 15 kan levering in het kader van een handelsactiviteit niet alleen worden gekenmerkt door het in rekening brengen van een prijs voor het product zelf, maar ook door:
- het in rekening brengen van een prijs voor technische ondersteuningsdiensten, als die prijs niet alleen dient om de gemaakte kosten te dekken;
- het hebben van “een intentie van tegeldemaking, bijvoorbeeld door het aanbieden van een softwareplatform waarmee de fabrikant andere diensten te gelde maakt”;
- het gebruik van het product afhankelijk maken van de verwerking van persoonsgegevens om andere redenen dan uitsluitend de verbetering van de beveiliging, compatibiliteit of interoperabiliteit van de software;
- het aanvaarden van donaties die hoger zijn dan de kosten van het ontwerp, de ontwikkeling en de levering van het product.
Ook staat er: “Het aanvaarden van schenkingen zonder winstoogmerk mag niet worden beschouwd als een handelsactiviteit.”
In onze lezing staat een wallet die verdient aan fees, swaps of een betaalde versie dicht bij deze voorbeelden, en kan hij behoren tot de producten die in de zin van overweging 18 “te gelde worden gemaakt”. De verordening definieert dat begrip niet, en wij stellen niet vast hoe het op een bepaald product van toepassing is.
Vrije en opensourcewallets
Overweging 18 beschrijft een uitzondering: volgens de overweging mag “de levering van producten met digitale elementen die als vrije en opensourcesoftware worden aangemerkt en die niet door de fabrikanten te gelde worden gemaakt, niet als een handelsactiviteit worden beschouwd”. Een bedrijf dat zijn opensourcewallet te gelde maakt, valt niet onder die uitzondering louter doordat het de broncode publiceert.
De overweging gaat ook in op non-profitorganisaties. De ontwikkeling door zulke organisaties van producten met digitale elementen die als vrije en opensourcesoftware worden aangemerkt, mag niet als een handelsactiviteit worden beschouwd, mits de organisatie zodanig is opgezet dat alle inkomsten na aftrek van kosten worden aangewend om doelstellingen zonder winstoogmerk te verwezenlijken.
Verder staat er dat de verordening niet van toepassing is op natuurlijke of rechtspersonen die met broncode bijdragen aan vrije en opensourceproducten die niet onder hun verantwoordelijkheid vallen.
Back-ends voor bewaring
Een back-end voor bewaring kan in verschillende categorieën vallen. Als de back-end zelf als product op de markt van de Unie wordt geleverd, kan hij op zichzelf een product met digitale elementen zijn (artikel 3, punt 1).
Als hij op afstand gegevens verwerkt voor een ander product, telt artikel 3, punt 2, dat alleen als gegevensverwerking op afstand wanneer aan beide voorwaarden is voldaan: de software is ontworpen en ontwikkeld door of onder de verantwoordelijkheid van de fabrikant van dat product, en het product zou zonder die back-end een van zijn functies niet kunnen vervullen.
Overweging 12 zegt dat Richtlijn (EU) 2022/2555 van toepassing is op cloudcomputerdiensten en cloudmodellen. Welke omschrijving bij een bepaald bewaarsysteem past, is een vraag voor een juridisch adviseur.
Belangrijke en kritieke producten
De verordening onderscheidt ook kritieke en belangrijke producten. Deze indelingen hebben gevolgen voor de conformiteitsbeoordeling, dus het onderscheid doet ertoe los van de vraag naar het toepassingsgebied.
Bijlage IV noemt drie categorieën kritieke producten: “hardwareapparaten met beveiligingskastje”; gateways voor slimme meters “en andere apparaten voor geavanceerde beveiligingsdoeleinden, onder meer voor beveiligde cryptoverwerking”; en “smartcards of soortgelijke apparaten, met inbegrip van secure elements (beveiligde elementen)”. Vermelding in die lijst is van invloed op welke conformiteitsbeoordelingsprocedures een product mag gebruiken (de artikelen 8 en 32).
Bijlage III noemt belangrijke producten in twee klassen, met negentien vermeldingen in klasse I en vier in klasse II. Klasse I omvat “wachtwoordbeheer”, “microprocessoren met beveiligingsgerelateerde functies” en “microcontrollers met beveiligingsgerelateerde functies”. Klasse II omvat “manipulatiebestendige microprocessoren” en “manipulatiebestendige microcontrollers”.
Een product met de belangrijkste functionaliteit van een categorie uit bijlage III is een belangrijk product. De bijbehorende conformiteitsbeoordelingsprocedures staan in artikel 32, lid 2, voor klasse I en in artikel 32, lid 3, voor klasse II. Het integreren van zo’n product in een ander product betekent op zich niet dat het product waarin het wordt geïntegreerd, aan die procedures wordt onderworpen (artikel 7, lid 1).
Artikel 32, lid 5, biedt een route voor producten die als vrije en opensourcesoftware worden aangemerkt en onder een categorie uit bijlage III vallen. Hun fabrikanten kunnen de conformiteit aantonen met een van de procedures van artikel 32, lid 1, op voorwaarde dat de in artikel 31 bedoelde technische documentatie openbaar wordt gemaakt op het moment dat het product in de handel wordt gebracht.
Of een vermelding in bijlage III of bijlage IV een bepaald apparaat of een bepaalde app beschrijft, vereist een juridische kwalificatie. Die vaststelling doen wij niet.
Wat de 24 uur veronderstellen
Artikel 14 kent drie meldstappen voor een actief uitgebuite kwetsbaarheid. Elke melding gaat via het centrale meldingsplatform naar het als coördinator aangewezen CSIRT en naar Enisa:
- Vroegtijdige waarschuwing: “zonder onnodige vertraging en in elk geval binnen 24 uur nadat de fabrikant er kennis van heeft gekregen”.
- Kwetsbaarheidsmelding: zonder onnodige vertraging en in elk geval binnen 72 uur nadat de fabrikant kennis heeft gekregen van de actief uitgebuite kwetsbaarheid.
- Eindverslag: “uiterlijk 14 dagen nadat een corrigerende of risicobeperkende maatregel beschikbaar is”.
Welk CSIRT het betreft, hangt af van de hoofdvestiging van de fabrikant in de Unie. Is die er niet, dan geeft artikel 14, lid 7, de volgorde van criteria waarmee het wordt bepaald.
Daarnaast is er een afzonderlijke plicht om gebruikers te informeren. Nadat de fabrikant kennis heeft gekregen, moet hij de getroffen gebruikers (en, indien passend, alle gebruikers) op de hoogte stellen van de kwetsbaarheid of het incident. Indien nodig moet hij hun ook laten weten welke maatregelen zij kunnen nemen (artikel 14, lid 8). Deze plicht staat los van de vroegtijdige waarschuwing binnen 24 uur.
De klok gaat lopen wanneer de fabrikant kennis krijgt. In onze lezing komt die kennis bij de meeste producten via een melding van een gebruiker of onderzoeker; bij een wallet is het eerste teken van een uitgebuite fout vaak de exploit zelf: tegoeden die worden verplaatst terwijl de eigenaar ze niet heeft verplaatst.
Wat elke melding bevat
De stap binnen 24 uur is een vroegtijdige waarschuwing, geen beschrijving van de fout. Artikel 14, lid 2, punt a), bepaalt dat daarin, in voorkomend geval, de lidstaten worden vermeld op het grondgebied waarvan de fabrikant ervan op de hoogte is dat het product beschikbaar is gesteld.
De melding binnen 72 uur moet algemene informatie geven, voor zover beschikbaar. Daartoe behoren de algemene aard van de uitbuiting en van de kwetsbaarheid, alle genomen corrigerende of risicobeperkende maatregelen, en corrigerende of risicobeperkende maatregelen die gebruikers kunnen nemen.
Het eindverslag moet de kwetsbaarheid beschrijven, inclusief de ernst en de gevolgen ervan. Het moet ook details geven over de beveiligingsupdate of andere corrigerende maatregelen die beschikbaar zijn gesteld om de kwetsbaarheid te verhelpen. Indien beschikbaar moet het informatie bevatten over elke kwaadwillige actor die de kwetsbaarheid heeft uitgebuit of aan het uitbuiten is.
In onze lezing raken de andere plichten uit de verordening aan de periode voordat deze meldklok gaat lopen.
Ernstige incidenten volgen een apart traject
Ernstige incidenten volgen een parallel meldtraject met dezelfde eerste twee termijnen. Volgens artikel 14, lid 5, is een incident ernstig als het negatieve gevolgen heeft of kan hebben voor het vermogen van het product om de beschikbaarheid, authenticiteit, integriteit of vertrouwelijkheid van gevoelige of belangrijke gegevens of functies te beschermen. Een incident is ook ernstig als het heeft geleid of kan leiden tot de invoering of uitvoering van kwaadwillige code.
Het eindverslag over een ernstig incident moet binnen één maand na de incidentmelding worden ingediend (artikel 14, lid 4, punt c)). De termijn van 14 dagen nadat een corrigerende of risicobeperkende maatregel beschikbaar is gekomen, hoort bij het traject voor kwetsbaarheden. Onze notitie over kwetsbaarhedenbeheer legt beide meldtrajecten uit.
Wat december 2027 toevoegt
De verordening is volledig van toepassing vanaf 11 december 2027, wanneer de essentiële cyberbeveiligingsvereisten van bijlage I van kracht worden. Voor wallets die vóór die datum in de handel zijn gebracht, gelden de vereisten van de verordening “alleen indien die producten vanaf die datum ingrijpend worden gewijzigd” (artikel 69, lid 2); de meldingsplichten van artikel 14 gelden voor die wallets ongeacht zo’n wijziging, als ze binnen het toepassingsgebied van de verordening vallen (artikel 69, lid 3). Onze notitie The standards may slip. The reporting date does not. legt het tijdpad uit.
Drie plichten zijn rechtstreeks van belang voor de vraag of een geval onder artikel 14 zeldzaam is of routine. Twee komen uit bijlage I en één uit artikel 13.
Lever zonder bekende uitbuitbare fouten. Op basis van de beoordeling van de cyberbeveiligingsrisico’s en indien van toepassing moet een product “op de markt worden aangeboden zonder bekende uitbuitbare kwetsbaarheden” (bijlage I, deel I, punt 2, a)).
Test en evalueer de beveiliging van het product. De fabrikant moet “de beveiliging van het product met digitale elementen op doeltreffende en regelmatige wijze testen en evalueren” (bijlage I, deel II, punt 3). De technische documentatie moet het volgende bevatten: “verslagen van de tests die zijn uitgevoerd om de conformiteit van het product met digitale elementen en van de procedures inzake de respons op kwetsbaarheden met de toepasselijke essentiële cyberbeveiligingsvereisten van de delen I en II van bijlage I te verifiëren” (bijlage VII, punt 6). Zie CRA-testverslag.
Betracht passende zorgvuldigheid bij wat u niet hebt geschreven. Fabrikanten moeten de passende zorgvuldigheid betrachten “bij de integratie van van derden afkomstige componenten in producten met digitale elementen, zodat die componenten de cyberbeveiliging van het product met digitale elementen niet in gevaar brengen” (artikel 13, lid 5). Dat geldt ook voor opensourcecomponenten. Voor een wallet gaat het om de cryptografische bibliotheken, de afleidingscode en de transactiebouwer waarvan hij afhankelijk is.
Dit is maar een deel van de vereisten. Bijlage I omvat onder meer ook de vertrouwelijkheid en integriteit van gegevens en commando’s, het vaststellen van kwetsbaarheden en componenten, met inbegrip van een softwarestuklijst (SBOM), een beleid inzake gecoördineerde openbaarmaking van kwetsbaarheden, en tijdige beveiligingsupdates.
Niet-naleving van de essentiële cyberbeveiligingsvereisten van bijlage I en van de verplichtingen in de artikelen 13 en 14 wordt bestraft met administratieve geldboeten tot 15.000.000 euro. Als de overtreder een onderneming is, ligt het maximum op dat bedrag of op 2,5% van haar totale wereldwijde jaarlijkse omzet over het voorafgaande boekjaar, afhankelijk van welk bedrag hoger is (artikel 64, lid 2).
Geen van deze plichten hangt ervan af of een mens of een model de code heeft geschreven. Als een model een deel van uw ondertekeningspad heeft geschreven, blijft de plicht om dat te hebben getest en geëvalueerd de uwe. Zie Is vibe coding safe? What a benchmark of 186 real tasks found. Onze uitleg over adversariële code review bespreekt waarom een tweede model niet automatisch een tweede getuige is.
Waar walletcode breekt
Een review moet ergens beginnen. In walletcode zijn de plekken waar een defect geld kan kosten goed bekend. Wij beginnen met:
- sleutelgeneratie en de entropie daarachter;
- back-up en herstel van de seed, en de afleiding van sleutels en adressen;
- ondertekening, inclusief hoe nonces worden aangemaakt en of een ervan zich kan herhalen;
- transactieopbouw, inclusief de vraag of wat het apparaat toont ook is wat het ondertekent;
- het updatepad voor firmware en apps: de verordening vraagt om “mechanismen om updates voor producten met digitale elementen veilig te verspreiden” (bijlage I, deel II, punt 7);
- de componenten van derden waarvan dit alles afhankelijk is (artikel 13, lid 5).
Dit zijn in het algemeen bronnen van fouten in wallets. Met deze opsomming beweren we niet dat een bepaald product een fout bevat.
Wat wij een walletmaker bieden
Een eerste opdracht omvat één component: de component waarin een fout uw gebruikers het meest zou kosten. Meestal is dat de ondertekening, de sleutelafleiding of het updatepad. We onderwerpen een precies aangeduide, vaste revisie van de code aan een adversariële review en leveren een ondertekend dossier van bevindingen op.
Bij elke bevestigde bevinding staat aangegeven hoe ze is vastgesteld: gereproduceerd via een testrun tegen de ongewijzigde code, of gelezen uit die code zonder die uit te voeren. Het dossier presenteert een bevinding nooit als meer dan het bewijs ervoor draagt. Het vermeldt ook elk oppervlak dat zonder bevinding is onderzocht, en de methode waarmee het is onderzocht.
De reviewers zijn onafhankelijk van de auteur van uw code, en een met naam genoemde persoon staat in voor het dossier. Een bevinding wordt afgesloten wanneer de reviewer die haar heeft ingebracht, haar intrekt, of wanneer ze tegen de code is aangetoond. Zie Een bevinding is geen vonnis en What settles a finding.
Het dossier legt het testen en evalueren van de onderzochte component vast. Het draagt bij aan het bewijs van de doeltreffende en regelmatige tests en evaluaties die bijlage I, deel II, punt 3, vereist. Die plicht geldt voor het hele product en vraagt om terugkerend werk, dus één opdracht kan er niet aan voldoen. Evenmin vormt het dossier op zichzelf de verslagen van de tests die de technische documentatie volgens bijlage VII, punt 6, moet bevatten. Dezelfde reviewmethode kan daarna op de rest van het product worden toegepast.
Een review van een component maakt uw product niet conform en stelt niet vast of het binnen het toepassingsgebied valt, dan wel belangrijk of kritiek is. Ze richt uw meldproces voor artikel 14 niet in en vervangt geen aangemelde instantie waar die vereist is.
Onze vijf weigeringen begrenzen verder wat we beweren. Daaronder: overeenstemming tussen AI-modellen is geen bewijs, en een review die niets vindt, toont niet aan dat er niets is.
De aangehaalde bepalingen van de CRA verwijzen naar Verordening (EU) 2024/2847 en zijn gecontroleerd aan de hand van de officiële Nederlandse taalversie; de citaten tussen aanhalingstekens geven die versie woordelijk weer. Deze pagina is een vertaling van het Engelse origineel; bij verschillen geldt het origineel. Als hier iets onjuist is, corrigeren we dat schriftelijk op deze pagina.