Nach COLDCARD, Trezor und SafePal: CLAVIs Plädoyer für Datenminimierung

Recherchestand: 19. August 2026. Von Anbietern gemeldete Gesamtwerte sind als solche gekennzeichnet. Dieser Artikel dient der Information und ist keine Rechts- oder Incident-Response-Beratung.

Die direkte Antwort: Weniger gespeicherte Daten bedeuten weniger Exposition auf Betreiberseite

Datenminimierung ist eine Sicherheitskontrolle, weil ein Betreiber keinen Datensatz verlieren kann, den er nie erhoben hat. Die nächstbeste Lösung besteht darin, nur das zu erheben, was ein bestimmter Zweck erfordert, es von anderen Systemen zu trennen und nach einem überprüften Zeitplan zu löschen. „Null Daten“ ist für ein operatives Unternehmen jedoch kein glaubwürdiges Versprechen. Versand, Rechnungen, Support, Betrugsprävention und regulierte Dienstleistungen können eng begrenzte Aufzeichnungspflichten schaffen. Das vertretbare Ziel lautet: kein Betreiberzugriff auf Vault-Geheimnisse und überall sonst nur die unbedingt notwendige Aufbewahrung.

Diese Unterscheidung ist wichtig, weil im Nachrichtenzyklus des August 2026 drei Sicherheitsmeldungen häufig zu einer alarmierenden Schlagzeile über „Hardware-Wallet-Hacks“ verdichtet wurden. Es handelte sich nicht um ein einziges Problem.

• Der COLDCARD-Vorfall betraf die Erzeugung von Wallet-Geheimnissen.
• Der Trezor-Vorfall betraf einen unbefugten Zugriff bei einem Versanddienstleister.
• Die SafePal-Offenlegung betraf einen Autorisierungsfehler in einer Komponente zur Bestellverfolgung.

Was geschah im Juli und August 2026?

Vorfall	Öffentliche Mitteilung oder Aktualisierung	Sicherheitsebene	Publikationsfähige Darstellung	Konfidenz
COLDCARD-Vorfall mit vorhersehbarem RNG	Hinweis veröffentlicht am 30. Juli; Leitfaden aktualisiert am 14. August 2026	Geheimniserzeugung	Coinkite und Block führten das Problem unabhängig voneinander auf einen Fehler bei der Firmware-Integration zurück, durch den ein deterministischer Fallback-Generator die Zufallswerte für die Seed-Erzeugung liefern konnte.	Ursache bestätigt; einige Versions- und Auswirkungsdetails bleiben umstritten oder geschätzt.
Trezor/ShipMonk-Exposition	Mitteilung veröffentlicht am 13. August 2026	Abwicklungs- und Identitätsdaten	Trezor zufolge informierte ShipMonk das Unternehmen über einen unbefugten Zugriff, der ungefähr 13.689 Kundendatensätze betraf. Laut Trezor waren Geräte, Schlüssel und Backups nicht betroffen.	Vom Anbieter gemeldeter Umfang; die Offenlegung wurde durch unabhängige Berichterstattung bestätigt, der Datensatz jedoch nicht unabhängig geprüft.
Exposition der SafePal-Bestellverfolgung	Offenlegung veröffentlicht am 16. August 2026	Abwicklungs- und Kaufdaten	SafePal zufolge legte ein Autorisierungsfehler Bestellinformationen von ungefähr 39.798 Kunden offen. Wallet-Zugangsdaten und Zahlungskartendaten seien nicht betroffen gewesen.	Vom Anbieter gemeldet; der Sachverhalt entwickelt sich noch.

COLDCARD: Ein Air-Gap kann schwache Entropie nicht ausgleichen

Die COLDCARD-Schwachstelle war ein Fehler bei der Erzeugung von Geheimnissen und keine Kompromittierung einer Kundendatenbank. Sowohl Coinkites technische Darstellung als auch Blocks unabhängige Codeanalyse ergaben, dass ein Build- oder Linkerfehler die Verwendung eines deterministischen MicroPython-Fallback-Generators anstelle der vorgesehenen hardwaregenerierten Zufallswerte ermöglichte.

Ein Wallet-Seed muss unvorhersehbar sein. Wird der mögliche Seed-Raum klein genug, um ihn zu durchsuchen, kann ein Angreifer außerhalb des Geräts mögliche Schlüssel rekonstruieren. Das Wallet kann ausgeschaltet, in einem Tresor verwahrt und nie mit dem Internet verbunden gewesen sein; diese Schutzmaßnahmen stellen die Zufälligkeit nicht wieder her, die bei der Erzeugung des Geheimnisses fehlte.

Dies ist eine wichtige Korrektur vereinfachender Beschreibungen eines „Air-Gap“. Physische und netzwerkseitige Isolation können Fernangriffspfade stark reduzieren, beweisen aber nicht, dass jede Komponente innerhalb der isolierten Grenze korrekt arbeitet. Entropieerzeugung, Firmware-Integration, reproduzierbare Builds, Update-Verfahren und unabhängige Überprüfungen bleiben Teil des Sicherheitsmodells.

Die genaue Mk2/Mk3-Versionsgrenze ist selbst eine nützliche Lektion im Umgang mit Belegen. Blocks Analyse führt den betroffenen Pfad auf Version 4.0.0 zurück. Coinkites aktuelle Warnung beginnt bei 4.0.1. Anstatt stillschweigend eine der beiden Grenzen zu wählen, sollten Nutzer und Publizierende die Abweichung benennen und einen unter einer der beiden Grenzen erzeugten Seed vorsichtig behandeln.

Coinkite erklärt außerdem, dass die Installation korrigierter Firmware einen bereits mit betroffener Firmware erzeugten Seed nicht stärkt. Das Update schützt die künftige Seed-Erzeugung; ein betroffener Seed erfordert weiterhin eine sorgfältige Migration auf ein neu erzeugtes Wallet, vorbehaltlich der Hinweise des Anbieters zu Würfeln und Passphrase. Diese Unterscheidung sollte in jeder Zusammenfassung der Abhilfemaßnahmen erscheinen.

Galaxy Research ordnete in seiner On-Chain-Analyse vom 3. August 1.596 BTC drei Wellen mit hoher Konfidenz und 14 kleineren Vorfällen zu. Diese Zahl sollte nur mit dieser Attribution verwendet werden. Sie ist keine von Coinkite bestätigte Verlustsumme, und dieser Artikel wiederholt weder die höheren Schätzungen für eine vierte Welle noch die unbestätigten Dollarwerte.

Die öffentlichen Belege identifizieren weder den Angreifer noch zeigen sie, dass künstliche Intelligenz den Fehler entdeckt hat. Eine separate Phishing-Kampagne nutzte die Sorge um COLDCARD aus, doch keine geprüfte Quelle belegt, dass dafür eine geleakte Coinkite-Kundenliste verwendet wurde.

Trezor: Minimierung scheint die Exposition verringert, aber nicht beseitigt zu haben

Trezors Mitteilung vom 13. August betraf bei ShipMonk gespeicherte Abwicklungsdaten und keine kompromittierte Wallet-Hardware. Trezor zufolge informierte ShipMonk das Unternehmen am 10. August. Das war das Benachrichtigungsdatum, nicht zwingend das Datum des Eindringens.

Trezors Mitteilung nannte den Exploit nicht. BleepingComputer berichtete später, dass die von der Redaktion geprüften ShipMonk-Benachrichtigungs-E-Mails den Zugriff mit einer Metabase-Schwachstelle verknüpften. Metabases Primärhinweis identifiziert CVE-2026-72898 als kritische, aktiv ausgenutzte, nicht authentifizierte SQL-Injection-Schwachstelle. Bis zum Recherchestichtag wurde weder ein öffentlicher ShipMonk-Postmortem-Bericht noch ein unabhängiger Forensikbericht gefunden.

Trezor meldete zwei betroffene Gruppen:

• 11.742 Kunden, deren Namen, E-Mail-Adressen, Telefonnummern und Lieferadressen offengelegt wurden.
• 1.947 Kunden, deren Namen, Städte und E-Mail-Adressen ohne vollständige Lieferadressen offengelegt wurden.

Daraus ergibt sich eine gemeldete Gesamtzahl von ungefähr 13.689, nicht „genau 14.000“. Laut Trezor betrafen die meisten Datensätze Kunden, die zwischen dem 10. Mai und dem 8. August 2026 Bestellungen in den Vereinigten Staaten, im Vereinigten Königreich, in Schweden, Kolumbien, Brasilien, Italien oder Portugal erhalten hatten. Das Unternehmen wies gesondert darauf hin, dass die unvollständigen Datensätze ältere Bestellungen enthalten könnten und der genaue Zeitraum noch mit ShipMonk geprüft werde.

Trezor zufolge waren die eigenen Systeme, Hardware-Wallets, privaten Schlüssel und Wallet-Backups nicht betroffen. Trezor erklärt außerdem, dass Paketinhalte nicht offengelegt wurden. Diese Einschränkungen sind bedeutsam, machen Namen und Wohnadressen aber nicht harmlos. Identitäts- und Lieferinformationen können eine betrügerische Supportnachricht glaubwürdiger machen und das Risiko gezielter Angriffe erhöhen. Die Mitteilung belegt keinen physischen Angriff; ein Risiko sollte daher nicht als bestätigte Folge umgeschrieben werden.

Trezors veröffentlichte Aufbewahrungstabelle besagt, dass zentrale E-Shop-Bestell- und Lieferdaten zu abgeschlossenen oder stornierten Bestellungen vorbehaltlich von Ausnahmen für laufende Bestellungen im Allgemeinen nach 90 Tagen gelöscht werden. Diese Richtlinie scheint die Zahl verfügbarer vollständiger Lieferadressen begrenzt zu haben. Sie hat den Vorfall nicht verhindert, und der Vorbehalt zu älteren unvollständigen Datensätzen verbietet es, die Richtlinie als perfekt umgesetzt darzustellen.

Dieselbe Tabelle zeigt auch, warum „Trezor löscht Kundendaten nach 90 Tagen“ falsch ist. Für unterschiedliche Zwecke nennt sie unterschiedliche Fristen: Rechnungsdaten zehn Jahre in einer separaten Umgebung, Fiat-Zahlungsdaten bei Dritten bis zu sieben Jahre, bestimmte Aufzeichnungen zu Kryptozahlungen fünf Jahre nach Ende der Geschäftsbeziehung und Anonymisierung geschlossener Supporttickets nach 120 Tagen. Für Marketing- und Empfehlungsdaten gelten wiederum andere Regeln.

So sieht echte Minimierung aus: kein einzelner Slogan und keine einzelne Frist, sondern eine Karte der Datenkategorien. Entscheidend ist, ob diese Karte beim Händler, Lager, Versanddienstleister, Supportsystem, Zahlungsabwickler sowie in Replikaten und Backups durchgesetzt wird.

SafePal: Ein Wallet kann intakt bleiben, während seine Käufer sichtbar werden

SafePals Offenlegung beschreibt einen weiteren Fehler bei Geschäftsdaten und keine gemeldete Kompromittierung von Wallet-Geheimnissen. SafePal zufolge legte ein Autorisierungsfehler in einem Plug-in zur Bestellverfolgung Informationen von ungefähr 39.798 Kunden offen, die zwischen dem 2. März 2025 und dem 11. April 2026 bestellt hatten.

Nach Angaben von SafePal umfassten die offengelegten Felder Namen, E-Mail-Adressen, Lieferadressen, Telefonnummern und Kaufdetails. Das Unternehmen erklärt, der Vorfall habe weder Seed-Phrasen, private Schlüssel, Wallet-Passwörter oder andere Wallet-Zugangsdaten noch Bankkontoinformationen, Zahlungskartennummern oder amtliche Identifikationsnummern betroffen.

Diese Aussagen bleiben Anbieterangaben. Die belastbare Schlussfolgerung ist enger: Das Wissen, dass eine namentlich bekannte Person ein Sicherheitsprodukt gekauft hat, kann wertvoll sein, selbst wenn die Geheimnisse des Produkts geschützt bleiben.

Für einen Hardwareanbieter ist der Checkout- und Tracking-Stack kein „gewöhnlicher E-Commerce“ außerhalb des Sicherheitsperimeters. Er kann eine reale Identität, einen Lieferort, Kontaktkanäle und einen sicherheitssensiblen Kauf miteinander verbinden. Jedes Plug-in und jeder Logistikpartner, der diese Kombination verarbeitet, wird Teil des Bedrohungsmodells des Kunden.

„Null Daten“ bedeutet nicht immer dasselbe

„Keine Daten erheben“ ist eine nützliche Designfrage, aber keine vollständige Betriebsrichtlinie. Ein Personal Vault und das Unternehmen, das ihn herstellt oder unterstützt, verarbeiten unterschiedliche Informationskategorien.

Das stärkste Ziel gilt für die Ebene der Vault-Geheimnisse: Der Anbieter sollte private Schlüssel, Wiederherstellungsmaterial, lokale Prompts der proprietären CLAVI-KI oder andere geschützte Inhalte gar nicht erst erhalten. CLAVIs öffentliche Dokumentation beschreibt dies als Designziel des Personal Vault. Das ist eine Aussage zur Produktarchitektur und zum Betreiberzugriff auf Nutzergeheimnisse, nicht die Behauptung, CLAVI Switzerland AG besitze keinerlei Geschäftsunterlagen.

Geschäfts- und Unternehmensunterlagen erfordern eine andere Disziplin:

Datenklasse	Vertretbares Ziel	Warum „nichts speichern“ unvollständig sein kann
Vault-Geheimnisse und geschützte lokale Inhalte	Durch die Architektur für den Betreiber unzugänglich halten; niemals über den Support anfordern.	Bei diesen Daten beseitigt die Nichterhebung die betreiberseitige Exposition am unmittelbarsten.
Bestell- und Lieferdaten	Nur die vom gewählten Versanddienstleister benötigten Felder erheben; sie trennen; nach Lieferung sowie nach Ablauf der Rückgabe- und Streitfristen löschen.	Ein physisches Produkt kann den Kunden nicht ohne einen Liefermechanismus erreichen, sofern keine datenschutzfreundliche Abholoption genutzt wird.
Rechnungen und Buchungsbelege	Nur die Informationen in einem separaten System aufbewahren, die erforderlich sind, um vorgeschriebene Buchungsunterlagen zu bilden und zu belegen.	Schweizer Rechnungslegungsvorschriften können verlangen, Geschäftsbücher und Buchungsbelege sowie den Geschäftsbericht und den Revisionsbericht zehn Jahre aufzubewahren; das ist keine Erlaubnis, ein vollständiges CRM-Profil zu speichern.
Supportunterlagen	Geheimnisse untersagen, Anhänge minimieren, Adressen für Ersatzlieferungen trennen und geschlossene Fälle löschen oder anonymisieren.	Eine laufende Garantie, ein Ersatz oder ein Streitfall kann begrenzte Unterlagen erfordern.
Marketingdaten	Teilnahme optional machen und Einwilligungsnachweise von Abwicklungsdaten trennen.	Eine Bestellung sollte nicht stillschweigend zur unbefristeten Erlaubnis für Profilbildung werden.
Sicherheitsbelege und rechtliche Aufbewahrungssperren	Bei einem Vorfall oder einer gültigen Rechtspflicht einen dokumentierten, eng abgegrenzten Datensatz bewahren; die Ausnahme überprüfen.	Reguläre Löschung kann für eine konkrete Untersuchung oder Aufbewahrungspflicht rechtmäßig ausgesetzt werden, doch die Ausnahme sollte nicht zum dauerhaften Standard werden.

Das Prinzip lautet nicht „alles ungeachtet der Folgen löschen“. Es lautet: „Jedes gespeicherte Feld muss seine Existenz rechtfertigen.“

Was verlangen DSGVO, Schweizer Recht und Kryptoregeln tatsächlich?

Die Rechtslandschaft unterstützt Minimierung, schreibt aber keinen universellen Aufbewahrungsplan vor. Die Anwendbarkeit hängt vom Unternehmen, Kunden, Verarbeitungszweck, Dienst und von der Jurisdiktion ab. Die folgende Darstellung ordnet den Geltungsbereich ein und ist keine Rechtsberatung.

Regelwerk	Was sich belastbar sagen lässt	Was es nicht bedeutet
DSGVO	Artikel 5 verlangt, dass personenbezogene Daten angemessen und erheblich sowie auf das notwendige Maß beschränkt sind und nicht länger als nötig gespeichert werden. Artikel 25 verlangt Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen.	Die DSGVO verlangt nicht von jedem Unternehmen, gar keine Daten zu erheben, und schreibt keine einzige rein lokale Architektur vor.
DSGVO-Meldung von Datenschutzverletzungen	Ein Verantwortlicher meldet der Aufsichtsbehörde die Verletzung unverzüglich und, soweit machbar, innerhalb von 72 Stunden nach Bekanntwerden, es sei denn, dass die Verletzung voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen führt. Betroffene Personen werden unverzüglich informiert, wenn voraussichtlich ein hohes Risiko besteht, vorbehaltlich der Ausnahmen.	Nicht jeder Vorfall muss innerhalb von 72 Stunden allen bekannt gegeben werden.
Schweizer DSG	Artikel 7 verlangt Datenschutz durch Technik und datenschutzfreundliche Voreinstellungen, einschließlich Voreinstellungen, die auf die für den Zweck erforderliche Verarbeitung beschränkt sind. Artikel 24 verwendet den Maßstab „so rasch wie möglich“, wenn eine Verletzung voraussichtlich ein hohes Risiko schafft.	Das Schweizer Recht verwendet nicht die feste 72-Stunden-Formulierung der DSGVO.
Schweizer Rechnungslegungsrecht	Artikel 958f des Obligationenrechts verlangt, dass Geschäftsbücher und Buchungsbelege sowie der Geschäftsbericht und der Revisionsbericht ab Ende des Geschäftsjahres zehn Jahre lang aufbewahrt werden.	Er verpflichtet nicht zur zehnjährigen Speicherung sachfremder Telemetrie, Marketingprofile, Supportdateien oder Wallet-Daten.
MiCA	Ein in den Anwendungsbereich fallender Anbieter von Kryptowerte-Dienstleistungen bewahrt bestimmte Aufzeichnungen zu Diensten, Tätigkeiten, Aufträgen und Transaktionen fünf Jahre auf, möglicherweise sieben Jahre nach rechtzeitiger Behördenanfrage. Der CASP-Status hängt davon ab, ob der Anbieter gewerbsmäßig für Kunden eine oder mehrere in MiCA aufgeführte Kryptowerte-Dienstleistungen erbringt. Die Verwahrung oder Kontrolle von Kryptowerten der Kunden oder deren Zugangsmitteln ist speziell für die Verwahrung relevant; Transfer, Ausführung, Tausch, Beratung und andere aufgeführte Dienste haben eigene Tatbestände.	Nicht jeder Hardwareverkäufer ist automatisch ein CASP, und MiCA verlangt nicht, jedes Kundenfeld aufzubewahren.
EU-Geldtransferverordnung	Informationspflichten gelten für alle erfassten Transfers unter Beteiligung eines EU-CASP. Transfers von mehr als 1.000 € zu oder von einer selbst gehosteten Adresse des Kunden lösen eine zusätzliche Prüfung aus, ob der Kunde diese Adresse besitzt oder kontrolliert. Die vorgeschriebenen Informationen werden fünf Jahre aufbewahrt; ein Mitgliedstaat darf bis zu fünf weitere Jahre nur nach einer Prüfung der Erforderlichkeit und Verhältnismäßigkeit für Zwecke der Bekämpfung von Geldwäsche und Terrorismusfinanzierung zulassen oder vorschreiben.	1.000 € ist kein allgemeiner Schwellenwert der Travel Rule. Reine Transfers von Person zu Person ohne CASP sind ausgenommen.
Schweizer CARF-Umsetzung	Das Schweizer SIF erklärt, der Rahmen könne nicht vor dem 1. Januar 2027 umgesetzt werden und seine Rechtsgrundlage gelte 2026 nicht. Der OECD-CARF umfasst die Identität meldepflichtiger Nutzer und aggregierte relevante Transaktionen bei erfassten Dienstleistern.	Die Schweiz hat CARF nicht am 1. Januar 2026 umgesetzt, und CARF ist keine universelle Datenbank der Bestände jedes Käufers einer Hardware-Wallet.

MiCA, Travel Rule, DORA, das Schweizer GwG und CARF lassen sich nicht allein anhand von Bezeichnungen wie „Hardware“, „Selbstverwahrung“ oder „nicht verwahrend“ auf CLAVI anwenden. Die Analyse kann sich durch Schlüsselzugriff, Signatur- oder Eingriffsmöglichkeiten, Transfer- und Tauschdienste, Smart-Contract-Kontrolle, vertragliche Rollen und fortlaufende Kundenbeziehungen ändern. Der produktive Funktionsumfang erfordert eine qualifizierte rechtliche Prüfung, bevor ein Ausschluss öffentlich behauptet wird.

Die endgültigen Leitlinien 02/2025 v2.0 des Europäischen Datenschutzausschusses, angenommen am 7. Juli 2026, ziehen eine weitere Grenze. Wallet-Adressen und öffentliche Schlüssel können personenbezogene Daten sein, wenn sie mit vertretbarem Aufwand einer natürlichen Person zugeordnet werden können. Verschlüsselung kann personenbezogene Daten schützen, ohne sie anonym zu machen. Die Leitlinien raten grundsätzlich davon ab, personenbezogene Daten on-chain zu speichern, weil unveränderliche Speicherung die Löschung erschwert; sie stellen jedoch kein kategorisches gesetzliches Verbot jeder solchen Verarbeitung dar.

Ein Datengrenzenmodell für CLAVIs Personal Vault

CLAVI sollte Datenschutz als überprüfbare Grenze beschreiben, nicht als absolutes Adjektiv. Die kanonische CLAVI-Definition beschreibt das Produkt als Personal Vault für digitale Vermögenswerte, private Daten und private Kommunikation. Der nützliche nächste Schritt ist eine kategorienweise Erklärung dazu, worauf der Betreiber zugreifen kann und was das operative Unternehmen weiterhin verarbeiten muss.

Das öffentliche Modell sollte für jede Datenklasse sieben Fragen beantworten:

1. Zweck: Warum existiert dieses Feld?
2. Mindestfelder: Welche Attribute sind unbedingt erforderlich?
3. System: Wo wird der Datensatz gespeichert, und ist er von anderen Zwecken getrennt?
4. Zugriff: Welche Rollen und Auftragsverarbeiter können ihn sehen?
5. Auslöser der Löschfrist: Beginnt die Frist bei Erhebung, Lieferung, Ticketschließung, Ende der Geschäftsbeziehung oder Ende des Geschäftsjahres?
6. Löschnachweis: Wie werden Produktivkopien, Replikate, Systeme von Auftragsverarbeitern und Backups erfasst?
7. Ausnahme: Was kann die Löschung aussetzen, wer genehmigt das und wann wird es überprüft?

Zusammen mit Warum CLAVI nicht mit Ledger konkurriert gelesen, lautet die Aussage nicht, dass ein Sicherheitsmechanismus jeden Angriff besiegt. Ein Personal Vault kombiniert Ebenen: Geheimniserzeugung, Signaturbefugnis, lokale Verarbeitung, physische Kontrolle, sorgfältig begrenzte Unternehmensdaten und ein rechtliches Umfeld. Jede Ebene hat einen anderen Fehlermodus.

Neun Kontrollen, die Minimierung in den Betrieb überführen

Eine Richtlinie senkt das Risiko nur, wenn Systeme und Auftragsverarbeiter sie durchsetzen. Für Hardware- und Personal-Vault-Anbieter lässt sich das praktische Kontrollpaket klar benennen, auch wenn die Umsetzung schwierig ist.

1. Ein zweckbezogenes Register auf Feldebene führen. „Bestelldaten“ ist zu ungenau. Name, Anschrift, Telefonnummer, E-Mail-Adresse, SKU und Tracking-ID benötigen jeweils einen dokumentierten Zweck und Verantwortlichen.
2. Daten nach Zweck trennen. Abwicklung, Buchhaltung, Support, Marketing und Sicherheitsbelege sollten nicht zu einem einzigen durchsuchbaren Kundenprofil werden.
3. Optionale Felder tatsächlich optional machen. Eine lokale Anforderung eines Versanddienstleisters sollte nicht zur universellen Checkout-Anforderung werden.
4. Kurze operative Lebensdauern verwenden. Die Löschfrist an einem bestimmten Ereignis beginnen lassen und Verlängerungen für laufende Rückgaben, Garantien oder Streitfälle dokumentieren.
5. Löschung bei Auftragsverarbeitern überprüfen. Vertragsklauseln sollten durch Löschläufe, Berichte, Stichproben oder Auditrechte gestützt werden, die Lager, Versanddienstleister und Unterauftragsverarbeiter abdecken.
6. Backups auf das Fristende ausrichten. Ein Datensatz ist nicht sinnvoll gelöscht, wenn er aus langlebigen Backups weiterhin routinemäßig wiederherstellbar und durchsuchbar ist. Wo eine sofortige Entfernung unpraktikabel ist, Wiederherstellungen beschränken und die Löschung erneut anwenden, bevor zurückgespielte Daten aktiv werden.
7. Geheimnisse aus dem Support fernhalten. Mitarbeitende, Formulare und automatisierte Werkzeuge sollten niemals Wiederherstellungsphrasen, private Schlüssel oder Vault-Inhalte anfordern. Sensible Anhänge benötigen ausdrückliche Verarbeitungs- und Löschregeln.
8. Die Aussagekraft eines Pakets verringern. Neutrale Verpackung, allgemeine Absenderangaben und rechtmäßige Paketfach- oder Abholoptionen können die Zuordnung erschweren; nichts davon sollte als garantierte Anonymität vermarktet werden.
9. Ausnahmen planen, ohne sie zu normalisieren. Vorfallsbelege und rechtliche Aufbewahrungssperren benötigen einen dokumentierten Umfang, eine Genehmigung, ein Prüfdatum und ein Freigabeverfahren.

Keine Kontrolle macht die Lage statisch. Angreifer ändern ihre Taktiken, Softwareabhängigkeiten ändern sich, Logistikketten ändern sich und Regulierung ändert sich. Die richtige Antwort ist nicht unbegrenzte Erhebung „für alle Fälle“. Sie ist eine lebende Datenkarte, deren Zwecke, Auftragsverarbeiter und Löschnachweise überprüft werden, während sich die Welt weiterentwickelt.

Häufig gestellte Fragen

Wurde Trezors Hardware im August 2026 gehackt?

Trezor sagt nein. Die Mitteilung vom 13. August betraf unbefugten Zugriff bei ShipMonk und exponierte Abwicklungsdaten. Trezor erklärte, eigene Systeme, Hardware-Wallets, private Schlüssel und Backups seien nicht betroffen. Trezors Mitteilung nannte den Exploit nicht; BleepingComputer berichtete später, ShipMonk-E-Mails hätten den Zugriff mit einer Metabase-Schwachstelle verknüpft, die Metabase als CVE-2026-72898 identifizierte.

War der COLDCARD-Vorfall eine Kundendatenpanne?

Im Zusammenhang mit der COLDCARD-Schwachstelle ist keine Kompromittierung einer Kundendatenbank nachgewiesen. Das bestätigte Problem lag in der Seed-Erzeugung: Ein Fehler bei der Firmware-Integration erlaubte es einem deterministischen Fallback-Generator, die Zufallswerte zu liefern. Eine separate Phishing-Kampagne nutzte später die öffentliche Verunsicherung über den Vorfall aus, doch die öffentlich verfügbaren Belege zeigen nicht, dass dabei eine geleakte Coinkite-Kundenliste verwendet wurde.

Welche Informationen meldeten Trezor und SafePal als offengelegt?

Trezor meldete Namen, E-Mail-Adressen, Telefonnummern und Lieferadressen von 11.742 Kunden sowie Namen, Städte und E-Mail-Adressen von weiteren 1.947. SafePal meldete Namen, E-Mail-Adressen, Telefonnummern, Lieferadressen und Kaufdetails von ungefähr 39.798 Kunden. Dies sind von den Unternehmen gemeldete Zahlen und keine unabhängig geprüften Gesamtwerte; keines der Unternehmen meldete in diesen Mitteilungen offengelegte Wallet-Geheimnisse.

Verlangt die DSGVO von einem Hardware-Wallet-Unternehmen, gar keine Daten zu erheben?

Nein. Soweit die DSGVO anwendbar ist, müssen personenbezogene Daten dem festgelegten Zweck angemessen und erheblich sowie auf das dafür notwendige Maß beschränkt sein; außerdem dürfen sie nicht länger als nötig gespeichert werden. Die DSGVO verlangt auch Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen. Das stützt Minimierung, Trennung und Löschfristen, schafft aber keine universelle Null-Erhebungs-Regel.

Befreit Selbstverwahrung einen Anbieter automatisch von der Finanzregulierung?

Nein. Die regulatorische Einordnung richtet sich danach, was ein Anbieter tatsächlich tut, einschließlich Schlüsselkontrolle, Signatur- oder Eingriffsbefugnissen, Transfer- oder Tauschdiensten, Smart-Contract-Rollen und fortlaufenden Kundenbeziehungen. Ein Hardwareverkauf allein entscheidet die Analyse nicht. CLAVIs im Produktivbetrieb eingesetzter Funktionsumfang und vertragliche Rolle erfordern daher eine jurisdiktionsspezifische rechtliche Prüfung, bevor ein Ausschluss von MiCA, Travel Rule, AMLA, DORA oder CARF behauptet wird.

Was sollte Zero Knowledge bei einem Personal Vault bedeuten?

Bei einem Personal Vault sollte Zero Knowledge eine präzise technische Grenze beschreiben: Der Betreiber sollte die Vault-Geheimnisse des Nutzers weder erhalten noch wiederherstellen können. Der Begriff sollte nicht suggerieren, ein operatives Unternehmen besitze keinerlei Bestell-, Rechnungs-, Support- oder Compliance-Unterlagen. Diese Geschäftsunterlagen benötigen getrennte Zwecke, Zugriffskontrollen und Aufbewahrungsfristen.

Warum muss die Löschung bei Logistikdienstleistern und anderen Auftragsverarbeitern überprüft werden?

Die Löschrichtlinie eines Verantwortlichen kann die Exposition nicht verringern, wenn Kopien bei einem Lager, Versanddienstleister, Zahlungsabwickler, Supportsystem, Backup-Anbieter oder Marketingdienst aktiv bleiben. Verträge sind notwendig; die stärkere Kontrolle ist jedoch eine überprüfbare Löschung in Produktivsystemen, Replikaten und Backups mit dokumentierten Ausnahmen für offene Bestellungen oder rechtmäßige Aufbewahrung.

Die dauerhafte Position: keine Vault-Geheimnisse, weniger Geschäftsdaten, mehr Nachweise

Der sicherste Kundendatensatz ist derjenige, der nie in die Systeme des Betreibers gelangt. Dieses Prinzip sollte am strengsten auf private Schlüssel, Wiederherstellungsmaterial und geschützte Vault-Inhalte angewendet werden. Für die enger begrenzten Informationen, die ein operatives Unternehmen verarbeiten muss, gilt ein anderer, aber weiterhin anspruchsvoller Maßstab: weniger erheben, Zwecke trennen, Datensätze ablaufen lassen, nachgelagerte Löschung überprüfen und die Ausnahme dokumentieren.

COLDCARD zeigt, warum Datenschutz keine solide kryptografische Implementierung ersetzen kann. Trezor und SafePal zeigen, wie Geschäftssysteme Menschen exponieren können, während die Wallet-Hardware außerhalb des gemeldeten Vorfalls bleibt. Eine ehrlichere Definition der Sicherheit eines Personal Vault muss das Geheimnis schützen, die Person schützen und die Daten benennen, die zwischen beiden existieren.