Seit dem 11. September 2026 muss ein Hersteller, der von einer aktiv ausgenutzten Schwachstelle in einem von ihm auf dem EU-Markt in Verkehr gebrachten Produkt Kenntnis erlangt, innerhalb von 24 Stunden eine Frühwarnung übermitteln. Dennoch erwähnt der Cyber Resilience Act, die Verordnung (EU) 2024/2847, Krypto-Wallets nirgends.
Die Uhr des Artikels 14 beginnt zu laufen, wenn der Hersteller Kenntnis erlangt. Ab dem 11. Dezember 2027 müssen Hersteller außerdem die Sicherheit ihres Produkts regelmäßig und wirksam testen und überprüfen (Anhang I Teil II Nummer 3); für ein Produkt, das vor diesem Datum in Verkehr gebracht wurde, gilt das nur dann, wenn das Produkt nach diesem Zeitpunkt wesentlich geändert wird (Artikel 69 Absatz 2). Nach unserer Lesart berührt diese Pflicht die Frage, ob die Kenntnis aus Ihren eigenen Tests stammt oder aus dem Exploit eines anderen. Siehe Die Maschinen lesen den Code.
Diese Notiz richtet sich an Hersteller von Hardware-Wallets, Wallet-Software, Verwahrungssoftware und Zahlungsgeräten. Sie erläutert, welcher Maßstab für den Anwendungsbereich gilt, was die 24 Stunden voraussetzen, was der Dezember 2027 hinzufügt und wo ein unabhängiges adversarielles Review seinen Platz hat. Sie ist keine Rechtsberatung und stellt nicht fest, ob Ihr Produkt in den Anwendungsbereich fällt.
Fällt eine Wallet in den Anwendungsbereich?
Ausgangspunkt ist die Begriffsbestimmung des Produkts mit digitalen Elementen in der Verordnung: „ein Software- oder Hardwareprodukt und dessen Datenfernverarbeitungslösungen, einschließlich Software- oder Hardwarekomponenten, die getrennt in den Verkehr gebracht werden“ (Artikel 3 Nummer 1).
Die nächste Frage ist, ob dieses Produkt auf dem Markt bereitgestellt wird. Die Begriffsbestimmung lautet: „die entgeltliche oder unentgeltliche Abgabe eines Produkts mit digitalen Elementen zum Vertrieb oder zur Verwendung auf dem Unionsmarkt im Rahmen einer Geschäftstätigkeit“ (Artikel 3 Nummer 22). Artikel 2 Absatz 1 fügt eine Bedingung hinzu: Die Verordnung gilt für solche Produkte, „deren bestimmungsgemäßer Zweck oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung mit einem Gerät oder Netz einschließt“. Nach unserer Lesart werden eine Hardware-Wallet, die sich mit einem Telefon oder Computer verbindet, und Wallet-Software, die auf ein Netz zugreift, diese Bedingung in der Regel erfüllen. Ein Air-Gap-Gerät, das Daten nur per QR-Code oder Speicherkarte austauscht, kann sie dennoch erfüllen: Artikel 3 Nummer 9 bestimmt eine physische Verbindung als eine Verbindung, die mit physikalischen Mitteln „wie elektrischen, optischen oder mechanischen Schnittstellen“ hergestellt wird, und Artikel 3 Nummer 10 erfasst eine indirekte Verbindung, die „als Teil eines größeren Systems, das seinerseits direkt mit diesem Gerät oder Netz verbunden werden kann“, zustande kommt. Ob ein bestimmtes Gerät die Bedingung erfüllt, ist eine Frage für die anwaltliche Beratung.
Für Wallet-Hersteller werfen diese Begriffsbestimmungen mehrere Fragen auf. Die folgende Darstellung gibt unsere Lesart wieder; ihre Anwendung auf ein bestimmtes Produkt erfordert anwaltliche Beratung.
Hardware-Wallets
Eine in der EU verkaufte Hardware-Wallet wird häufig der Beschreibung eines Hardwareprodukts entsprechen, das Software enthält und im Rahmen einer Geschäftstätigkeit abgegeben wird. Ob Ihr Gerät den rechtlichen Maßstab erfüllt, muss dennoch festgestellt werden.
Ihre Firmware ist in der Regel Teil des Produkts. Eine Begleit-App wirft eine weitere Frage auf: Ist sie Teil desselben Produkts oder ein eigenständiges Produkt?
Wallet-Software und Geschäftstätigkeit
Bei Wallet-Software hängt die Frage davon ab, ob sie im Rahmen einer Geschäftstätigkeit bereitgestellt wird (Artikel 3 Nummer 22). Erwägungsgrund 18 besagt, dass die Bereitstellung von Produkten mit digitalen Elementen, die als freie und quelloffene Software eingestuft und von ihren Herstellern nicht zu Geld gemacht werden, nicht als Geschäftstätigkeit betrachtet werden sollte.
Den Hersteller zu bestimmen, ist ein eigener Schritt. Artikel 3 Nummer 13 benennt die Person, die das Produkt entwickelt oder herstellt oder diese Arbeiten ausführen lässt und es unter ihrem eigenen Namen oder ihrer Marke vermarktet, „sei es gegen Bezahlung, zur Monetarisierung oder unentgeltlich“.
Nach Erwägungsgrund 15 ist eine Lieferung im Rahmen einer Geschäftstätigkeit möglicherweise nicht nur dadurch gekennzeichnet, dass für das Produkt selbst ein Preis verlangt wird, sondern auch dadurch,
- dass für technische Unterstützungsleistungen ein Entgelt verlangt wird, das nicht nur der Deckung der tatsächlichen Kosten dient;
- dass „eine Gewinnerzielungsabsicht“ besteht, „beispielsweise durch Bereitstellung einer Softwareplattform, über die der Hersteller andere Dienste gewinnorientiert anbietet“;
- dass die Nutzung des Produkts davon abhängig gemacht wird, dass personenbezogene Daten zu anderen Zwecken als ausschließlich der Verbesserung der Sicherheit, Kompatibilität oder Interoperabilität der Software verarbeitet werden;
- dass Spenden angenommen werden, die die Kosten der Konzeption, Entwicklung und Bereitstellung des Produkts übersteigen.
Außerdem heißt es dort: „Die Annahme von Spenden ohne Gewinnabsicht sollte nicht als Geschäftstätigkeit gelten.“
Nach unserer Lesart liegt eine Wallet, die mit Gebühren, Swaps oder einem kostenpflichtigen Tarif Einnahmen erzielt, nahe an diesen Beispielen und kann im Sinne von Erwägungsgrund 18 als „zu Geld gemacht“ gelten. Die Verordnung definiert diesen Ausdruck nicht, und wir stellen nicht fest, wie er auf ein bestimmtes Produkt anzuwenden ist.
Freie und quelloffene Wallets
Erwägungsgrund 18 beschreibt eine Ausnahme: Danach sollte „die Bereitstellung von Produkten mit digitalen Elementen, die als freie und quelloffene Software eingestuft und von ihren Herstellern nicht zu Geld gemacht werden, nicht als Geschäftstätigkeit betrachtet werden“. Ein Unternehmen, das seine quelloffene Wallet zu Geld macht, kommt nicht schon dadurch in den Genuss dieser Ausnahme, dass es den Quellcode veröffentlicht.
Der Erwägungsgrund befasst sich auch mit gemeinnützigen Organisationen. Deren Entwicklung von Produkten mit digitalen Elementen, die als freie und quelloffene Software eingestuft sind, sollte nicht als Geschäftstätigkeit betrachtet werden, sofern die Organisation so angelegt ist, dass sichergestellt ist, dass alle Einnahmen nach Abzug der Kosten zur Verwirklichung gemeinnütziger Ziele verwendet werden.
Weiter heißt es dort, dass die Verordnung nicht für natürliche oder juristische Personen gilt, die mit Quellcode zu freien und quelloffenen Produkten beitragen, die nicht ihrer Verantwortung unterliegen.
Verwahrende Backends
Ein verwahrendes Backend kann in verschiedene Kategorien fallen. Wird das Backend selbst als Produkt auf dem Unionsmarkt abgegeben, kann es ein eigenständiges Produkt mit digitalen Elementen sein (Artikel 3 Nummer 1).
Verarbeitet es Daten aus der Ferne für ein anderes Produkt, zählt Artikel 3 Nummer 2 es nur dann als Datenfernverarbeitung, wenn beide Bedingungen erfüllt sind: Die Software wird vom Hersteller dieses Produkts selbst oder unter dessen Verantwortung konzipiert und entwickelt, und das Produkt könnte ohne sie eine seiner Funktionen nicht erfüllen.
Erwägungsgrund 12 hält fest, dass die Richtlinie (EU) 2022/2555 für Cloud-Computing-Dienste und Cloud-Dienstmodelle gilt. Welche Beschreibung auf ein bestimmtes Verwahrsystem zutrifft, ist eine Frage für die anwaltliche Beratung.
Wichtige und kritische Produkte
Die Verordnung unterscheidet außerdem kritische und wichtige Produkte. Diese Einstufungen wirken sich auf die Konformitätsbewertung aus; die Unterscheidung ist deshalb unabhängig von der Frage des Anwendungsbereichs von Bedeutung.
Anhang IV führt drei Kategorien kritischer Produkte auf: „Hardwaregeräte mit Sicherheitsboxen“; Smart-Meter-Gateways „sowie andere Geräte für fortgeschrittene Sicherheitszwecke, einschließlich der sicheren Kryptoverarbeitung“; und „Chipkarten oder ähnliche Geräte, einschließlich Sicherheitselemente“. Die Aufnahme in die Liste wirkt sich darauf aus, welche Konformitätsbewertungsverfahren ein Produkt anwenden darf (Artikel 8 und 32).
Anhang III führt wichtige Produkte in zwei Klassen auf, mit neunzehn Einträgen in Klasse I und vier in Klasse II. Klasse I umfasst „Passwort-Manager“, „Mikroprozessoren mit sicherheitsrelevanten Funktionen“ und „Mikrocontroller mit sicherheitsrelevanten Funktionen“. Klasse II umfasst „manipulationssichere Mikroprozessoren“ und „manipulationssichere Mikrocontroller“.
Ein Produkt, das die Kernfunktionen einer Kategorie des Anhangs III aufweist, ist ein wichtiges Produkt. Die entsprechenden Konformitätsbewertungsverfahren stehen in Artikel 32 Absatz 2 für Klasse I und in Artikel 32 Absatz 3 für Klasse II. Die Integration eines solchen Produkts in ein anderes führt für sich genommen nicht dazu, dass das aufnehmende Produkt diesen Verfahren unterliegt (Artikel 7 Absatz 1).
Artikel 32 Absatz 5 sieht einen Weg für Produkte vor, die als freie und quelloffene Software gelten und unter eine Kategorie des Anhangs III fallen. Ihre Hersteller können die Konformität anhand eines der Verfahren nach Artikel 32 Absatz 1 nachweisen, sofern die in Artikel 31 genannte technische Dokumentation zum Zeitpunkt des Inverkehrbringens des Produkts der Öffentlichkeit zugänglich gemacht wird.
Ob irgendein Eintrag in Anhang III oder Anhang IV ein bestimmtes Gerät oder eine bestimmte App beschreibt, erfordert eine rechtliche Einstufung. Diese Feststellung treffen wir nicht.
Was die 24 Stunden voraussetzen
Artikel 14 legt für eine aktiv ausgenutzte Schwachstelle drei Meldeschritte fest. Jede Meldung geht über die einheitliche Meldeplattform an das als Koordinator benannte CSIRT und an die ENISA:
- Frühwarnung: „unverzüglich, in jedem Fall aber innerhalb von 24 Stunden, nachdem der Hersteller davon Kenntnis erlangt hat“.
- Meldung von Schwachstellen: unverzüglich, in jedem Fall aber innerhalb von 72 Stunden nach Kenntniserlangung von der aktiv ausgenutzten Schwachstelle.
- Abschlussbericht: „spätestens 14 Tage, nachdem eine Korrektur- oder Risikominderungsmaßnahme zur Verfügung steht“.
Welches CSIRT zuständig ist, hängt von der Hauptniederlassung des Herstellers in der Union ab. Gibt es keine, legt Artikel 14 Absatz 7 die Reihenfolge der Kriterien fest, nach denen es bestimmt wird.
Daneben besteht eine eigene Pflicht, die Nutzer zu informieren. Nach Kenntniserlangung muss der Hersteller die betroffenen Nutzer (und gegebenenfalls alle Nutzer) über die Schwachstelle oder den Sicherheitsvorfall informieren. Erforderlichenfalls muss er ihnen auch mitteilen, welche Maßnahmen sie ergreifen können (Artikel 14 Absatz 8). Diese Pflicht ist von der 24-Stunden-Frühwarnung zu unterscheiden.
Die Uhr beginnt zu laufen, wenn der Hersteller Kenntnis erlangt. Nach unserer Lesart entsteht diese Kenntnis bei den meisten Produkten durch die Meldung eines Nutzers oder eines Sicherheitsforschers; bei einer Wallet ist das erste Anzeichen einer ausgenutzten Schwachstelle oft der Exploit selbst: Gelder, die bewegt werden, obwohl ihr Eigentümer sie nicht bewegt hat.
Was jede Meldung enthält
Der 24-Stunden-Schritt ist eine Frühwarnung und keine Beschreibung der Schwachstelle. Artikel 14 Absatz 2 Buchstabe a legt fest, dass sie gegebenenfalls die Mitgliedstaaten angeben muss, in deren Hoheitsgebiet das Produkt nach Kenntnis des Herstellers bereitgestellt wurde.
Anmerkung zur Übersetzung: In Artikel 14 Absatz 2 Buchstabe a fehlt in der amtlichen deutschen Fassung das „gegebenenfalls“, das die englische, französische, spanische und italienische Fassung enthalten; diese Seite folgt ihnen.
Die 72-Stunden-Meldung muss allgemeine Informationen enthalten, soweit verfügbar. Dazu gehören die allgemeine Art der Ausnutzung und der Schwachstelle, alle ergriffenen Korrektur- oder Risikominderungsmaßnahmen sowie Korrektur- oder Abhilfemaßnahmen, die Nutzer ergreifen können.
Der Abschlussbericht muss die Schwachstelle beschreiben, einschließlich ihres Schweregrads und ihrer Auswirkungen. Er muss außerdem Angaben zu der Sicherheitsaktualisierung oder den anderen Korrekturmaßnahmen enthalten, die zur Behebung der Schwachstelle zur Verfügung gestellt wurden. Falls verfügbar, muss er Informationen über jeden böswilligen Akteur enthalten, der die Schwachstelle ausgenutzt hat oder ausnutzt.
Nach unserer Lesart betreffen die übrigen Pflichten der Verordnung die Zeit, bevor diese Meldeuhr zu laufen beginnt.
Schwerwiegende Sicherheitsvorfälle haben einen eigenen Meldeweg
Schwerwiegende Sicherheitsvorfälle folgen einem parallelen Meldeweg mit denselben ersten beiden Fristen. Nach Artikel 14 Absatz 5 ist ein Sicherheitsvorfall schwerwiegend, wenn er sich negativ auf die Fähigkeit des Produkts auswirkt oder auswirken kann, die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler oder wichtiger Daten oder Funktionen zu schützen. Ein Sicherheitsvorfall gilt auch dann als schwerwiegend, wenn er zur Einführung oder Ausführung böswilligen Codes geführt hat oder dazu führen kann.
Der Abschlussbericht zu einem schwerwiegenden Sicherheitsvorfall ist innerhalb eines Monats nach der Meldung des Sicherheitsvorfalls fällig (Artikel 14 Absatz 4 Buchstabe c). Die Frist von 14 Tagen, nachdem eine Korrektur- oder Risikominderungsmaßnahme verfügbar geworden ist, gehört zum Meldeweg für Schwachstellen. Unsere Notiz Schwachstellenmanagement unter dem Cyber Resilience Act: wo die adversariale Prüfung sitzt erläutert beide Meldewege.
Was der Dezember 2027 hinzufügt
Die Verordnung gilt vollständig ab dem 11. Dezember 2027, wenn die grundlegenden Cybersicherheitsanforderungen des Anhangs I wirksam werden. Wallets, die vor diesem Datum in Verkehr gebracht wurden, unterliegen den in der Verordnung festgelegten Anforderungen „nur dann, wenn nach diesem Zeitpunkt diese Produkte einer wesentlichen Änderung unterliegen“ (Artikel 69 Absatz 2); die Meldepflichten nach Artikel 14 gelten für sie unabhängig von einer solchen Änderung, sofern sie in den Anwendungsbereich der Verordnung fallen (Artikel 69 Absatz 3). Unsere Notiz Die Normen mögen sich verschieben. Der Meldetermin nicht. erläutert den Zeitplan.
Drei Pflichten berühren unmittelbar die Frage, ob ein Fall nach Artikel 14 selten oder Routine ist. Zwei stammen aus Anhang I, eine aus Artikel 13.
Ohne bekannte ausnutzbare Schwachstellen ausliefern. Auf der Grundlage der Bewertung der Cybersicherheitsrisiken und soweit zutreffend muss ein Produkt „ohne bekannte ausnutzbare Schwachstellen auf dem Markt bereitgestellt werden“ (Anhang I Teil I Nummer 2 Buchstabe a).
Die Sicherheit des Produkts testen und überprüfen. Der Hersteller muss „die Sicherheit des Produkts mit digitalen Elementen regelmäßig und wirksam testen und überprüfen“ (Anhang I Teil II Nummer 3). Die technische Dokumentation muss „Berichte über die Tests und Prüfungen, die durchgeführt wurden, um die Konformität des Produkts mit digitalen Elementen und der Verfahren zur Behandlung von Schwachstellen mit den geltenden grundlegenden Cybersicherheitsanforderungen … zu überprüfen“ enthalten (Anhang VII Nummer 6). Siehe CRA-Testbericht.
Sorgfalt walten lassen bei dem, was Sie nicht selbst geschrieben haben. Hersteller müssen „die gebotene Sorgfalt walten“ lassen, „wenn sie von Dritten bezogene Komponenten in ihre Produkte mit digitalen Elementen integrieren, sodass solche Komponenten die Cybersicherheit des Produkts mit digitalen Elementen nicht beeinträchtigen“ (Artikel 13 Absatz 5). Das schließt quelloffene Komponenten ein. Für eine Wallet bedeutet das die kryptografischen Bibliotheken, den Ableitungscode und den Transaktions-Builder, von denen sie abhängt.
Das ist nur ein Teil der Anforderungen. Anhang I umfasst unter anderem auch die Vertraulichkeit und Integrität von Daten und Befehlen, die Ermittlung von Schwachstellen und Komponenten einschließlich einer Software-Stückliste (SBOM), eine Strategie für die koordinierte Offenlegung von Schwachstellen und rechtzeitige Sicherheitsaktualisierungen.
Die Nichteinhaltung der grundlegenden Cybersicherheitsanforderungen des Anhangs I und der Pflichten aus den Artikeln 13 und 14 wird mit Geldbußen von bis zu 15 000 000 EUR geahndet. Ist der Verstoßende ein Unternehmen, liegt die Obergrenze bei diesem Betrag oder bei 2,5 % seines gesamten weltweiten Jahresumsatzes im vorangegangenen Geschäftsjahr, je nachdem, welcher Betrag höher ist (Artikel 64 Absatz 2).
Keine dieser Pflichten hängt davon ab, ob ein Mensch oder ein Modell den Code geschrieben hat. Wenn ein Modell einen Teil Ihres Signierpfads geschrieben hat, liegt die Pflicht, ihn getestet und überprüft zu haben, dennoch bei Ihnen. Siehe Ist Vibe Coding sicher? Was ein Benchmark mit 186 realen Aufgaben ergab. Unsere Erläuterung Adversarielles Code-Review: was der Begriff auslässt erörtert, warum ein zweites Modell nicht automatisch ein zweiter Zeuge ist.
Wo Wallet-Code bricht
Ein Review muss irgendwo anfangen. In Wallet-Code sind die Stellen, an denen ein Defekt Geld kosten kann, gut bekannt. Wir beginnen mit:
- der Schlüsselerzeugung und der Entropie dahinter;
- der Sicherung und Wiederherstellung des Seeds sowie der Ableitung von Schlüsseln und Adressen;
- dem Signieren, einschließlich der Frage, wie Nonces erzeugt werden und ob sich eine wiederholen kann;
- dem Aufbau von Transaktionen, einschließlich der Frage, ob das, was das Gerät anzeigt, das ist, was es signiert;
- dem Update-Pfad für Firmware und Apps: Die Verordnung verlangt „Mechanismen für die sichere Verbreitung von Aktualisierungen“ (Anhang I Teil II Nummer 7);
- den Komponenten Dritter, von denen all dies abhängt (Artikel 13 Absatz 5).
Das sind allgemeine Fehlerquellen bei Wallets. Ihre Aufzählung ist keine Behauptung, dass ein bestimmtes Produkt einen Fehler enthält.
Was wir einem Wallet-Hersteller anbieten
Ein erster Auftrag umfasst eine Komponente: diejenige, bei der ein Fehler Ihre Nutzer am meisten kosten würde. Meist handelt es sich um das Signieren, die Schlüsselableitung oder den Update-Pfad. Wir prüfen eine genau bezeichnete, festgelegte Revision des Codes adversariell und liefern eine unterzeichnete Befundakte.
Jeder bestätigte Befund ist danach gekennzeichnet, wie er festgestellt wurde: reproduziert durch einen Testlauf gegen den unveränderten Code, oder gelesen aus diesem Code, ohne ihn auszuführen. Die Akte stellt einen Befund nie stärker dar, als seine Evidenz es trägt. Sie weist außerdem jede ohne Befund untersuchte Fläche aus, zusammen mit der Methode, mit der sie untersucht wurde.
Die Prüfer sind unabhängig vom Autor Ihres Codes, und eine namentlich benannte Person steht für die Akte ein. Ein Befund schließt, wenn der Prüfer, der ihn erhoben hat, ihn zurückzieht, oder wenn er am Code nachgewiesen wird. Siehe Ein Befund ist kein Urteil und What settles a finding.
Die Akte dokumentiert Test und Überprüfung der untersuchten Komponente. Sie trägt Evidenz zu den regelmäßigen und wirksamen Tests und Überprüfungen bei, die Anhang I Teil II Nummer 3 verlangt. Diese Pflicht umfasst das gesamte Produkt und erfordert wiederkehrende Arbeit, deshalb kann ein einzelner Auftrag sie nicht erfüllen. Ebenso wenig stellt die Akte für sich genommen die Berichte über die Tests und Prüfungen dar, die die technische Dokumentation nach Anhang VII Nummer 6 enthalten muss. Dieselbe Prüfmethode kann dann auf das übrige Produkt angewandt werden.
Das Review einer Komponente macht Ihr Produkt nicht konform und stellt nicht fest, ob es in den Anwendungsbereich fällt, wichtig oder kritisch ist. Es richtet Ihr Meldeverfahren nach Artikel 14 nicht ein und ersetzt keine notifizierte Stelle, wo eine erforderlich ist.
Unsere fünf Weigerungen setzen dem, was wir behaupten, weitere Grenzen. Darunter: Übereinstimmung zwischen KI-Modellen ist kein Beweis, und ein Review, das nichts findet, belegt nicht, dass nichts da ist.
Zitierte CRA-Bestimmungen beziehen sich auf Verordnung (EU) 2024/2847 und wurden gegen den Wortlaut der amtlichen deutschen Sprachfassung geprüft. Diese Seite ist eine Übersetzung des englischen Originals; bei Abweichungen gilt das Original. Wenn hier etwas falsch ist, korrigieren wir es schriftlich auf dieser Seite.