Tangems Andrey Lazutkin: Warum weniger bei Hardware-Wallets mehr ist

Das Marketing für Hardware-Wallets läuft heute meist in eine Richtung: mehr Features, mehr Displays, mehr Konnektivität, mehr Firmware-Updates. Tangem setzt mit seinem Produkt bewusst auf das Gegenteil.
 

Es gibt kein Display, keine Batterie, keinen USB- oder Bluetooth-Anschluss, keine aktualisierbare Firmware und keine Seed-Phrase zum Aufschreiben. Für viele in der Security-Community klingt das wie eine Aufzählung der wichtigsten Funktionen einer Krypto-Wallet – tatsächlich handelt es sich aber um absichtlich weggelassene Features.
 

Yellow Media hat sich mit Tangem-CTO Andrey Lazutkin zusammengesetzt und genau dazu nachgehakt. 

• Was passiert, wenn das Smartphone kompromittiert ist? 
• Warum eine Firmware ausliefern, die sich nie patchen lässt? 
• Wie schützt ein Tangem Ring vor einem NFC-Angriff in einer vollen Bahn? 
• Und was passiert, wenn Quantencomputer Realität werden?

Das Screenless-Problem: Was, wenn das Smartphone lügt?

Ein zentrales Prinzip klassischer Hardware-Wallets lautet: „What You See Is What You Sign“ – ein Display auf dem Gerät, das Transaktionen zur Kontrolle anzeigt. Tangem verzichtet auf ein Display und lagert die komplette Bedienung auf das Smartphone aus. 

Wenn ein Smartphone durch Malware manipuliert wird und falsche Inhalte anzeigt, könnte ein Nutzer unwissentlich eine schädliche NFC-Transaktion freigeben. Wie verhindert eure Architektur UI-Manipulation auf einem infizierten Gerät?

Ein Display allein ist kein Sicherheitskonzept. Es ist nur ein Baustein – und jeder Baustein schafft neue Angriffsflächen. Je komplexer eine Hardware-Wallet wird, desto mehr Angriffspunkte entstehen: Display-Logik, Buttons, Firmware, Update-Mechanismen, USB, Bluetooth, Batterien, Treiber, Parser und physische Schnittstellen. 

Das Internet ist voll von Beispielen, in denen klassische Hardware-Wallets nicht wegen gebrochener Kryptografie, sondern durch Schwachstellen in der Implementierung kompromittiert wurden.

Tangem verfolgt bewusst den Gegenansatz: Das Signiergerät so einfach wie möglich halten. Kein Display, keine Batterie, kein USB, kein Bluetooth, keine aktualisierbare Firmware, kein komplexes Betriebssystem. Der private Schlüssel wird im sicheren Chip erzeugt und gespeichert und verlässt die Karte nie. Diese Einfachheit ist ein großer Sicherheitsvorteil.

Das Smartphone dient nur als Bedienoberfläche – die Schlüssel liegen dort nicht. Auch die Tangem App ist stark geschützt: 

• Laufzeit-Integritätsprüfungen, 
• Anti-Debugging,
• Anti-Emulation, 
• Root- und Jailbreak-Erkennung, 
• verschlüsselte Speicherung,
• gesicherte Kommunikation, 
• Zertifikatsvalidierung, 
• WebView-Schutz, 
• Tapjacking-Schutz, 
• sichere Eingabeverarbeitung, 

Hinzu kommen minimale Berechtigungen, Code-Reviews, Audits und automatisierte Sicherheitsprüfungen.
 

Wir betrachten Sicherheit also nicht als Frage von „Display oder nicht“, sondern als Gesamtsystem. Tangem minimiert die Angriffsfläche in der Hardware und härtet die mobile Ebene, die Transaktionen vorbereitet. Das bietet Nutzer:innen eine starke Kombination: ein simples, isoliertes Signiergerät und eine sichere, moderne Mobile-Experience.

In der IT-Sicherheit ist Komplexität oft der Feind. Tangems Vorteil: Die Karte macht sehr wenig, aber das Entscheidende extrem gut – den Schlüssel schützen und sicher signieren.

Warum die Karte nie gepatcht werden kann

Die Firmware ist ab Werk aufgespielt und unveränderlich – sie kann nicht over-the-air aktualisiert werden, das Risiko bösartiger Firmware-Updates entfällt. Aber was passiert, wenn später ein Zero-Day oder ein kritischer Kryptografie-Bug im Chip gefunden wird? Warum ist ein komplett nicht-aktualisierbarer Chip langfristig sicherer für Self-Custody als ein patchbares Gerät?

Patchbarkeit ist kein kostenloses Feature. In einer Hardware-Wallet ist ein Update-Mechanismus immer auch ein permanenter Angriffsvektor für Code-Injektionen.

Kann eine Wallet nach der Auslieferung neue Firmware empfangen, muss der Nutzer dem Hersteller dauerhaft vertrauen: dessen Signierschlüsseln, Build-System, Release-Pipeline, Update-Servern, Mitarbeitenden, Sicherheitsprozessen und künftigen Geschäftsentscheidungen. Selbst wenn alles korrekt designt ist, wird diese Infrastruktur Teil der Trusted-Computing-Base.
 

Dadurch entstehen reale Risiken: kompromittierte Update-Server, geleakte Signierschlüssel, böswillige Insider, regulatorischer Druck, versehentliche Fehl-Updates oder Firmware-Änderungen, die das ursprüngliche Sicherheitsmodell schwächen.

Die Ledger Recover-Kontroverse hat das deutlich gemacht. Ledgers eigener Support schrieb in einem inzwischen gelöschten Post: „Technically speaking, it is and always has been possible to write firmware that facilitates key extraction. You have always trusted Ledger not to deploy such firmware, whether you knew it or not.“ Genau dieses Vertrauensmodell schließt Tangem aus.
 

Tangem setzt auf Unveränderlichkeit. Die Firmware wird beim Herstellungsprozess aufgespielt und kann danach nicht mehr verändert werden. Es gibt kein OTA-Update, kein USB-Firmware-Flashen, keinen drahtlosen Update-Pfad und keine Möglichkeit, nachträglich Code auf die Karte zu bringen, sobald sie beim Nutzer ist.

Ja, das bedeutet: Wir können einen Chip nicht aus der Ferne patchen, falls später eine Hardware-Sicherheitslücke entdeckt wird. Aber ein updatefähiges Gerät eliminiert das Risiko nicht, sondern schafft ein anderes, dauerhaftes Risiko – nämlich die Möglichkeit, sicherheitskritischen Code nachträglich zu ändern.

Für langfristige Self-Custody halten wir einen unveränderlichen Vertrauensanker für sicherer. Das Gerät sollte nicht darauf angewiesen sein, dass der Hersteller für immer vertrauenswürdig bleibt. Tangems Philosophie ist klar: Die Karte schützt den Schlüssel, signiert sicher und akzeptiert nie wieder neuen Code.
 

Die App-Store-Abhängigkeit

Tangem ist auf die eigene App angewiesen – damit besteht eine strukturelle Abhängigkeit von zentralisierten Vertriebsplattformen wie Apples App Store und Google Play.

 Was passiert, wenn ein staatlicher Akteur oder ein raffinierter Angreifer eure Entwickler-Zugangsdaten kompromittiert und ein bösartiges Update veröffentlicht, bevor ihr es bemerkt? Welche Schutzmechanismen im Secure Element sichern die Nutzer-Gelder?

Damit dieses Szenario eintritt, müsste ein Angreifer unsere Entwickler-Zugangsdaten kompromittieren, MFA und interne Zugriffskontrollen umgehen, den Freigabeprozess für Releases durchlaufen, schädlichen Code in den offiziellen Build einschleusen, Apples oder Googles Prüfung bestehen, die App-Identität beibehalten, Plattform-Malware-Erkennung umgehen und unbemerkt von unserem Team, Monitoring-Systemen und der Open-Source-Community bleiben.

Das ist nicht eine einzelne Schwachstelle, sondern eine Kette unabhängiger Versagen über mehrere Sicherheitsebenen hinweg. Genau das meine ich, wenn ich sage: Sicherheit muss als Gesamtsystem bewertet werden, nicht anhand eines isolierten Features. 

Aus unserer Sicht ist die Wahrscheinlichkeit, dass eine solche Kette gelingt, deutlich geringer als die Risiken, die durch eine komplexere Hardware-Wallet-Architektur entstehen – insbesondere, wenn diese auf Firmware-Updates angewiesen ist, um langfristig sicher zu bleiben.
 

Komplexere Geräte brauchen mehr Schnittstellen, mehr Firmware, mehr Update-Mechanismen, mehr Komponenten und mehr vertrauenswürdige Prozesse. Jede dieser Ebenen schafft zusätzliche Angriffsflächen: Supply-Chain-Angriffe, Debugging-Interfaces, Firmware-Bugs, bösartige oder kompromittierte Updates, geleakte Signierschlüssel, Build-System-Kompromittierung oder Druck auf den Hersteller, das Geräteverhalten nachträglich zu ändern.
 

Wer sich die Geschichte von Hardware-Wallet-Angriffen ansieht, erkennt ein klares Muster: Die meisten realen Probleme entstehen nicht durch gebrochene Kryptografie, sondern durch Komplexität – Implementierungsfehler, Update-Mechanismen, physische Schnittstellen, Firmware-Verhalten, Supply-Chain-Annahmen oder unerwartete Wechselwirkungen zwischen Komponenten.

Ein bösartiges App-Store-Update ist ein theoretisches Risiko – aber es erfordert eine Kette unabhängiger Versagen, bevor der Angreifer überhaupt beim Nutzer ankommt. Ein dauerhaft updatefähiger Quellcode hält dagegen einen Code-Update-Pfad über die gesamte Produktlebensdauer offen.

Das ist der Kern des Tangem-Sicherheitsmodells: Die Zahl der vertrauenswürdigen Komponenten minimieren, die Angriffsfläche verringern und das Signiergerät unveränderlich machen.

Seedless Backup vs. Papier-Seed-Phrase

Die Seedless-Architektur sichert die Wallet, indem der private Schlüssel beim Setup auf Backup-Karten geklont wird. Das entfernt den Single Point of Failure einer Papier-Seed-Phrase, schafft aber eine physische Abhängigkeit: Gehen alle Backup-Karten verloren, ist keine Wiederherstellung möglich. Wie skaliert ein reines Hardware-Backup für Generationenwechsel oder Nachlassplanung im Vergleich zu klassischen BIP-39-Papierstandards?

Wer eine Hardware-Wallet kauft, erwartet, dass das Gerät die privaten Schlüssel schützt. Bei vielen klassischen Wallets zeigt das Gerät aber zuerst die Seed-Phrase an – und überträgt die Verantwortung zurück an den Nutzer.
 

Ab diesem Moment ist die Seed-Phrase das schwächste Glied: ein Zettel, eine Metallplatte, eine Schublade, ein Safe, ein Foto (das man nie machen sollte) oder eine Phrase, die verloren, beschädigt, kopiert, offengelegt oder gestohlen werden kann.
 

Verlorene Zugänge zu privaten Schlüsseln und Wiederherstellungsphrasen sind eine der häufigsten Ursachen für dauerhaften Krypto-Verlust. Chainalysis schätzt, dass Millionen Bitcoins für immer verloren sind. Auch Phishing-Angriffe zielen direkt auf Seed-Phrasen ab – denn sobald diese kompromittiert ist, spielt der Preis oder das Sicherheitsniveau der Hardware-Wallet keine Rolle mehr.
 

Im klassischen Modell gibt es eine Hardware-Wallet und eine Seed-Phrase. Man kann Kopien der Seed-Phrase anlegen – jede einzelne erhöht aber das Risiko, da sie nicht durch Hardware geschützt ist. Der Nutzer muss sich sein eigenes Sicherheitssystem ausdenken.
 

Tangem sieht das anders: Auch das Backup sollte durch Hardware geschützt sein. Deshalb erhalten Nutzer:innen im Standard-Setup drei Karten. Jede Karte ist eine vollwertige Hardware-Wallet mit Secure Element – kein ungeschütztes Papiergeheimnis.
 

Für Nachlass oder langfristige Aufbewahrung kann eine Karte im Alltag genutzt, eine sicher verwahrt und eine dritte an eine vertraute Person, einen Anwalt oder als Teil einer Nachlassregelung übergeben werden. Sind alle Karten verloren, gibt es keine Wiederherstellung – aber das ist echte Self-Custody. Tangem eliminiert den fragilsten Teil des klassischen Modells: eine offenliegende Seed-Phrase.
 

Wenn der private Schlüssel wichtig genug ist, um ihn mit einer Hardware-Wallet zu schützen, sollte auch das Backup hardwaregeschützt sein. Genau das macht Tangem.

Kann Transaktionssimulation je 100 % sicher sein?

DeFi-Phishing und Blind Signing sind weiterhin die häufigsten Wege, wie Nutzer:innen ihre Wallets verlieren. Eure App integriert Transaktionssimulation und dApp-Scam-Erkennung, um anzuzeigen, was ein Smart Contract ausführt. 

Aber angesichts der Turing-Vollständigkeit komplexer Multi-Hop-Smart-Contracts: Kann eine clientseitige Simulation je 100 % zuverlässig sein? Oder besteht das Risiko, Nutzer:innen eine falsche Sicherheit zu suggerieren?

Das ist eine sehr gute Frage, denn du hast das Stichwort „absolute Sicherheit“ genannt.

Die ehrliche Antwort: Nein. Keine Wallet, keine Simulation, kein Hardware-Device und kein Security-Unternehmen kann absolute Sicherheit versprechen. Krypto ist ein adversarielles Umfeld. Sicherheit ist kein magisches Feature, sondern ein Schichtsystem, das Angriffe erschwert, verteuert und weniger skalierbar macht.
 

Und manchmal liegt die Schwachstelle nicht dort, wo man sie erwartet. Es gibt bestätigte Fälle, in denen Kundendaten aus Hardware-Wallet-Käufen offengelegt wurden. Das Problem lag dann nicht in der Kryptografie oder dem Gerät, sondern im erweiterten Sicherheitsumfeld: Phishing, Social Engineering, Fake-Support, gefälschte Ersatzgeräte oder gezielter Druck.
 

Auf DeFi-Seite nutzt Tangem einige der fortschrittlichsten Schutzmechanismen: Transaktionssimulation, Smart-Contract-Risikoanalyse, dApp-Erkennung, Domain-Checks, Warnungen bei verdächtigem Verhalten und Schutz vor Blind Signing, wo immer Transaktionen dekodiert und analysiert werden können.
 

Aber kann Simulation für jeden Smart Contract 100 % zuverlässig sein? Nein. Komplexe Smart Contracts, Multi-Hop-Routen, sich ändernde On-Chain-States, bösartige Frontends, Phishing-Domains und Social Engineering bedeuten, dass Nutzer:innen weiterhin prüfen müssen, wo sie sich verbinden, was sie freigeben und ob sie der dApp vertrauen.
 

Wir stellen Simulation daher nie als absoluten Schutz dar, sondern als zusätzliche Sicherheitsschicht, die die Sichtbarkeit vor dem Signieren deutlich erhöht. Sie hilft, die Absicht einer Transaktion besser zu verstehen, Scams früher zu erkennen und Blind Approvals zu vermeiden.

Das richtige Mindset: Tangem schützt den Schlüssel hardwarebasiert, reduziert die Angriffsfläche mit einer einfachen, unveränderlichen Karte und ergänzt den Schutz um moderne DeFi-Features in der App. Trotzdem sollten Nutzer:innen nur vertrauenswürdige dApps nutzen, Domains prüfen, keine überhasteten oder unter Druck stehenden Transaktionen durchführen, bei Freigaben vorsichtig sein und kein Warnsystem als Ersatz für gesunden Menschenverstand betrachten.

Absolute Sicherheit gibt es nicht. Starke Sicherheit entsteht durch gestaffelte Schutzmechanismen – und genau so ist Tangem aufgebaut.
 

Gasgebühren in Stablecoins zahlen – ohne Cold Storage zu brechen

Ihr habt kürzlich eine Funktion eingeführt, mit der Nutzer:innen Netzwerkgebühren in Stablecoins wie USDT oder USDC statt im nativen Gas-Token zahlen können. Im Hintergrund erfordert das meist Account-Abstraction-Relayer oder Drittliquidität. 

Schaffen diese Komfortfunktionen neue Gegenparteirisiken oder zentrale Abhängigkeiten in einer eigentlich als Cold Storage gedachten Umgebung?
 

Tangem nutzt EIP-7702 für Smart Gas auf unterstützten EVM-Netzwerken. So können Netzwerkgebühren in bestimmten ERC-20-Tokens gezahlt werden, statt den nativen Gas-Token zu halten. Das ändert nichts am Custody-Modell: Der private Schlüssel bleibt in der Tangem-Karte, die Signatur erfolgt weiterhin hardwarebasiert, und kein Dritter erhält Zugriff auf die Schlüssel.
 

Open-Source-App, Closed-Source-Silicon

Die Companion-App ist vollständig Open Source auf GitHub, ganz im Sinne des „Don't Trust, Verify“-Prinzips der Community. Das EAL6+-Secure-Element in den Karten läuft aber auf einer proprietären, Closed-Source-Architektur der Chip-Hersteller. 

Wie passt der Open-Source-Gedanke von DeFi zu einer Hardware-Basis, bei der man einer firmeneigenen, geschlossenen Chip-Architektur vertrauen muss?
 

Open Source ist wichtig – aber zu verlangen, dass jede Schicht eines sicheren Hardware-Produkts Open Source sein muss, zeigt, dass jemand Hardware-Sicherheit nicht verstanden hat.
 

Für ein Secure Element sind geschlossene Low-Level-Firmware und Chip-Interna kein Makel, sondern Teil des Schutzkonzepts. Diese Chips sind darauf ausgelegt, physischen und invasiven Angriffen zu widerstehen: Fault Injection, Side-Channel-Analyse, Probing, Glitching, Laser-Attacken und andere Labor-Methoden. Würde man Details zu Firmware-Verhalten, Speicherstruktur, Sensorik, Gegenmaßnahmen oder Fehlererkennung offenlegen, würde das Angreifern helfen – nicht den Nutzern.
 

Das ist kein naives „Security through Obscurity“. Echte Hardware-Sicherheit basiert auf gestaffelten Schutzmechanismen: zertifizierte Secure Elements, limitierte Befehlssätze, unabhängige Audits, unveränderliche Firmware und minimale Angriffsfläche. 

Das bedeutet aber auch, keine unnötigen Low-Level-Details offenzulegen, die physische Angriffe erleichtern würden.

Und ehrlich: Selbst wenn jemand „Open-Source-Firmware“ anbietet, ist der Secure Chip selbst nie vollständig offen. Er enthält Hardware-Logik, ROM, Microcode, proprietäre Gegenmaßnahmen, Fertigungsprozesse und physische Sicherheitsmechanismen, die realistisch niemand inspizieren oder reproduzieren kann. 

So zu tun, als könne ein Konsument die gesamte Hardware-Root-of-Trust prüfen, nur weil etwas Firmware-Code veröffentlicht ist, ist irreführend.

Unser Sicherheitsmodell lautet: „Dort schließen, wo Offenlegung Angreifern helfen würde, unabhängig prüfen, wo Vertrauen nötig ist, und so minimal wie möglich bleiben“.

Hardware im Alltag: der Tangem Ring

Mit Wearables wie dem Tangem Ring bringt Tangem Hardware direkt in den öffentlichen Raum. Welche technischen Maßnahmen schützen Nutzer:innen vor Angriffen mit verstärkten NFC-Lesern in Menschenmengen, die unautorisierte Handshakes oder Brute-Force-Angriffe versuchen?

Erstens: NFC steht für Near Field Communication und ist auf sehr kurze Distanzen ausgelegt. Die Vorstellung, ein „verstärkter Leser“ könnte heimlich mit einem Ring am Finger in einer vollen Bahn kommunizieren, ist kein realistisches Alltagsrisiko.

Hinzu kommt: Der Tangem Ring sieht aus wie ein normales Wearable, ähnlich wie Bezahlringe oder andere Accessoires. Ein Angreifer müsste zuerst erkennen, dass es sich um eine Krypto-Hardware-Wallet handelt – und nicht um einen gewöhnlichen Ring.

Selbst wenn jemand versuchen würde, per NFC mit dem Ring zu interagieren, erhält er dadurch keinen Zugriff auf die Wallet. Der Tangem Ring ist – wie die Karten – durch einen selbstgewählten Zugangscode geschützt. Ohne diesen kann kein Angreifer Wallet-Operationen autorisieren.

Brute-Force ist ebenfalls kein praktikabler Weg. Das Gerät schützt vor wiederholten Passwortversuchen: Nach Fehleingaben steigt die Verzögerung zwischen den Versuchen, automatisiertes Raten wird so praktisch unmöglich.

Das Sicherheitsmodell ist einfach: NFC-Nähe allein reicht nicht, physische Anwesenheit allein reicht nicht, und das Erraten des Zugangscodes ist kein realistischer Angriff. Nutzer:innen können den Tangem Ring bedenkenlos im Alltag tragen.

Regulierung und Self-Custody als Kern

Weltweit verschärfen Regulierer die Vorgaben für „unhosted wallets“ und verpflichtende Zielkontrollen für Transaktionen. Entwickelt ihr eure Infrastruktur so, dass sie künftigen Anforderungen nach eingebauten Compliance- oder KYC-Hooks in Self-Custody-Apps widersteht – oder ist eure Software grundsätzlich unveränderlich, egal wie sich das regulatorische Umfeld wandelt?
 

Wichtig ist zunächst, die Gerätearchitektur von der Regulierungsebene zu trennen.

Bei Tangem wird der private Schlüssel auf der Karte erzeugt und gespeichert. Die Karte kennt kein KYC, ist nicht auf einen Compliance-Server angewiesen und fragt Tangem nicht um Erlaubnis, eine Transaktion zu signieren. Sie schützt einfach den Schlüssel und signiert, wenn der Nutzer autorisiert.
 

Man kann die Karte mit der offiziellen Tangem App nutzen oder technisch auch mit Open-Source-Tools und SDKs. Das heißt: Tangem kann die Karte nicht aus der Ferne einfrieren, den Schlüssel nicht extrahieren und den Zugriff auf die Gelder auf Hardware-Ebene nicht verhindern.
 

Was Regulierung betrifft, muss man realistisch bleiben: Würde man Self-Custody-Wallets zwingen, Kontrollmechanismen direkt in die Signierebene einzubauen, wäre das das falsche Werkzeug. Es gibt viele freie Wallets, Open-Source-Wallets, Forks und Untergrundlösungen. Wenn Regulierer die Nutzer von geprüften, sicheren Produkten wegdrängen, weichen viele auf weniger transparente, unsichere Alternativen aus. Das erhöht Verluste, Betrug und Schattenaktivität – nicht umgekehrt.
 

Global sehen wir einen anderen Trend: Regulierer konzentrieren sich auf Schnittstellen zu regulierten Diensten – Börsen, On-/Off-Ramps, Zahlungsprodukte und Finanzintermediäre. Dort gehören KYC, AML, Sanktionsprüfungen und Meldepflichten hin.
 

Wenn bestimmte Länder für bestimmte Dienste Compliance-Prozesse verlangen, kann Tangem Nutzer:innen unterstützen, diese einzuhalten. Das ist aber etwas anderes, als die Hardware-Wallet selbst zu einem permissioned Device zu machen.
 

Unsere Position ist klar: Tangem kann konforme Zugänge zu regulierten Services unterstützen, aber der Self-Custody-Kern bleibt unangetastet. Die Karte schützt den Schlüssel. Der Nutzer kontrolliert die Gelder. Tangem hält keine Assets, kontrolliert den privaten Schlüssel nicht und hat keinen Remote-Schalter, um zu entscheiden, ob signiert werden darf.
 

Die Quantum-Frage

Die große Mehrheit der Hardware-Wallets – auch Tangem – setzt auf Standard-Kryptografie wie ECDSA oder Ed25519. Mit dem Fortschritt bei Quantencomputern: Wie verwundbar ist fest verdrahtete Firmware gegenüber späterer Quantenentschlüsselung und wie sieht euer Fahrplan für die Umstellung bestehender Karten auf Post-Quantum-Kryptografie aus?
 

Der Umstieg auf Post-Quantum-Kryptografie muss auf Protokollebene der Blockchains beginnen.

Hardware-Wallets legen nicht fest, welche Signaturalgorithmen Bitcoin, Ethereum, Solana oder andere Netzwerke akzeptieren. Zuerst müssen die Blockchains selbst post-quantum-resistente Standards einführen. Erst dann können diese Algorithmen in Wallets, Secure Elements und Signiergeräten umgesetzt werden.
 

Derzeit gibt es keinen allgemein akzeptierten Migrationspfad oder einheitlichen Post-Quantum-Algorithmus, den große Blockchains für alltägliche Transaktionen nutzen. Die Branche forscht, testet und diskutiert noch den richtigen Ansatz.
 

Tangem arbeitet aktiv an diesem Thema – aber die Herausforderung ist viel größer als nur Hardware-Wallets. Der Wandel betrifft auch Bankkarten, SIM-Karten, Secure Elements, Ausweisdokumente, IoT-Geräte und viele andere sicherheitskritische Systeme.

In den nächsten Jahren erwarten wir einen starken Schub bei Post-Quantum-Kryptografie, Chip-Support und Blockchain-Standards. Sobald die Netzwerke bereit sind, wird Tangem mitziehen.

Wichtig ist: Die Post-Quantum-Migration ist ein Ökosystem-Übergang – erst die Blockchains, dann die Hardware-Wallets.

Der rote Faden durch alle Antworten bleibt derselbe, den Tangem seit Tag eins vertritt: Sicherheit ist eine Eigenschaft des Gesamtsystems, nicht irgendeines einzelnen Features. Weniger bewegliche Teile, weniger Vertrauen, weniger Fehlerquellen – und eine entscheidende Aufgabe, die extrem gut gelöst wird.