Known security incidents, attack methods and forensic possibilities after the theft of crypto assets — from seed generation to structured root cause analysis.
Whitepaper 2026
Management Summary
Hardware wallets are considered one of the safest ways to store personal data. The basic idea is that private keys are not stored on computers or smartphones, but in dedicated hardware. However, this often leads to the technically overly optimistic conclusion that cryptocurrencies on a hardware wallet "cannot be hacked." Hardware wallets significantly reduce risks—they do not eliminate them.
The security of a hardware wallet is not solely a property of the device itself. It arises from a security chain: manufacturing, delivery, initialization, seed generation, firmware, hardware, app or host system, transaction authorization, backup, and user behavior.
Documented incidents reveal various attack vectors: physical seed extraction, fault injection and voltage glitching attacks, faulty random number generation, firmware vulnerabilities, compromised software libraries, supply chain and evil maid scenarios, and sensitive key data in application logs. From a forensic perspective, the theft of a hardware wallet therefore means by no means automatically, that the victim has passed on their seed — and an unauthorized transfer in itself does not prove a hardware hack.
The principle "Not your keys, not your coins" shapes the crypto world. Manufacturers such as Ledger, Trezor, Tangem, BitBox, COLDCARD, OneKey, SafePal, Keystone, and Ellipal all employ different technical concepts—regarding microcontrollers, secure elements, firmware, seed generation, backup, display/input, communication methods (USB, Bluetooth, NFC, QR), and the proportion of open-source software. Therefore, a blanket assessment of "Manufacturer A secure, Manufacturer B insecure" would be neither technically nor forensically sound.
This document is based on manufacturer safety notices, published research and audit reports, and expert reports; no in-house laboratory tests were conducted for this version. Manufacturer information is provided by the parties. Damage estimates for ongoing incidents are snapshots in time. A proven vulnerability does not prove theft; a theft does not prove a device vulnerability. The version stated on the cover sheet is authoritative.
A hardware wallet doesn't technically store coins—the assets reside on the blockchain. The device manages the keys used to authorize transactions.
The signature is created within the protected environment; the private key is not exposed to the host system. This isolation is the key advantage over software wallets—but it only provides protection if the seed was generated correctly and randomly, is not otherwise disclosed, the firmware is functioning correctly, the device has not been tampered with, and the user actually confirms the intended transaction.
Security should not be reduced to a single chip. The entire chain is forensically relevant.
A flaw in just one area can weaken the entire system. Therefore, after a theft, the first step is to determine at which level an attack was technically possible and which hypotheses are actually supported by the available evidence.
Whoever possesses the complete seed no longer needs the original device—they can transfer assets while the device remains with the victim. Methods: PhishingFake support, photographing or copying the seed, cloud/file backups, input on computer or website, fake wallet software, pre-defined seed on manipulated devices.
A wallet is only as secure as its random values. With predictable or insufficient entropy, an attacker can calculate potential seeds offline and compare them with public blockchain addresses.
Firmware controls key security functions. Errors can affect key generation, signature verification, updates, memory access, or communication between security components.
Fault injection, voltage glitching, side-channel analysis, memory extraction and bus sniffing require physical access and are clearly distinct from remote attacks.
Even if the private key does not leave the device, malware or manipulated applications can change the interface, exchange receiving addresses, or trick the user into revealing the seed.
A device can be compromised before its first use: swapped devices, manipulated packaging, altered firmware, pre-programmed seeds, counterfeit accompanying cards, or imitation manufacturer websites and apps.
The COLDCARD incident of summer 2026 shows that a hardware wallet can be compromised without an attacker ever touching it or taking it over remotely. Mechanism: A build and link integration error caused seed generation to use the software PRNG Yasmarang included in MicroPython, instead of the intended hardware TRNG implementation. A protection check only verified whether a configuration value was set—not whether it was non-zero. The hardware generator did not fail, but it simply could not be reached. [1][2]
Impact: The effective key size decreased to approximately 40 bits (Mk2/Mk3) and approximately 72 bits (Mk4/Mk5/Q) instead of 128 bits. A 40-bit search space is practically vulnerable to attack with modern computing power; TRM Labs describes the keys as searchable without physical access. Extent: Starting on July 30, 2026, addresses were emptied in several waves—in the first wave, around 594 BTC from approximately 500 wallets were stolen in 25 minutes. According to TRM Labs (August 5, 2026), around 1,816 BTC from over 5,200 addresses were stolen in four waves, with a value of approximately US$116 million; no final damage assessment has been released. [2][4]
Exceptions: Seeds with at least 50 fair, independent dice rolls are considered not vulnerable to this RNG problem. A strong, once-used BIP-39 passphrase makes exploitation more difficult, but does not fix the weak seed. Decisive: A firmware update does not fix a weak seed that has already been generated — affected wallets must be migrated to a newly generated seed. [1][2][3]
The victim may never have digitized the seed, never handed over the device, and never confirmed an unknown transaction – and yet assets can still be stolen if the keys were inadequately protected when they were generated.
| feature | Reference to cohort/RNG case | Indication of individual compromise |
|---|---|---|
| Temporal distribution | many unconnected victims within a few hours or days | single victim, no temporal pattern |
| Similarities | same model/model series, seed generation within the same firmware period | No common technical basis is apparent. |
| prehistory | No phishing, no support contact, no digitized seed | Phishing, support chat, screenshot or cloud backup demonstrable |
| Address selection | Discharge without any prior interaction with the perpetrator | targeted approach or prior contact |
| Transaction patterns | Sweeps across many addresses in quick succession, often without regard to fees | single outflow, often after a test transaction |
| Countermeasures | With a weak seed: Firmware update is insufficient; migration is required. | Re-establishing/cleaning the surroundings may be sufficient. |
Ledger Donjon (2019) and Octopus Security Labs (2020, Voltage Glitching) demonstrated the ability to read memory and extract a seed from a Trezor One / Model T using physical access. This is not a remote hack—it requires device ownership, expertise, and equipment. [7][8]
Ledger Donjon used a 1064 nm laser to manipulate the Ed25519 signature verification of the TROPIC01 Secure Element, causing it to register an invalid signature as valid. This allowed the vulnerability to execute custom firmware (disclosure 03/06/2026). The stored secrets are protected by a hardware MAC-and-destroy mechanism. The chip manufacturer rates the vulnerability CVSS 5.7 (moderate); the attack requires decapsulation, laboratory equipment (costing over €30,000), and complete device possession. There is no evidence of actual exploitation. The vulnerability is silicon-level and cannot be fixed via a firmware update. [5][6][19][20]
An attacker gained access to Ledger's e-commerce/marketing database via an API key: over one million email addresses and around 272,000 records containing other personal data. Private keys were not directly affected, but the risk of targeted phishing and physical attacks on known owners increased. [9]
In December 2023, an attacker, after phishing a former employee, distributed manipulated versions of the Ledger Connect Kit via NPMJS; integrating DApps could load malicious code and exfiltrate assets. The hardware itself was not compromised—the software and integration environment was the critical factor. [10]
In wallets activated with a seed phrase, the private key could mistakenly appear in app logs; potentially affected were users who also submitted logs to support within seven days. Tangem reported no user losses. Vulnerabilities can therefore originate outside the wallet chip. [11]
Unciphered demonstrated a physical attack via the inadequately protected communication between the CPU and the Secure Element; OneKey explained the solution. The crucial factor was physical access, not a remote attack. [12]
Kraken Security Labs (2021) reported on issues related to tamper detection and a possible firmware downgrade, but was unable to steal any coins from the device. A proven vulnerability does not automatically constitute theft. [13]
Ledger Donjon (2019) reported vulnerabilities including seed extraction via physical access and reactivated interfaces (supply chain/evil maid relevance). This is noteworthy because... Ellipal advertised with an „air-gapped“ architecture: Air gap reduces the attack surface, but is no guarantee against hardware/firmware errors. [14]
Keylabs (2023) identified, among other things, a high-scoring firmware vulnerability (tamper response); according to the auditors, the high-scoring vulnerability and other findings were fixed and retested. Published audits also show that a manufacturer allows external audits. [15]
BitBox It describes a dual-chip architecture (microcontroller + separate secure chip), encrypted seed storage, multiple independent secrets/entropy sources, a secure bootloader, device authentication, and transaction verification on the display. No confirmed theft case comparable to COLDCARD 2026 was identified in the evaluated sources—explicitly making no statement about absolute security. [16]
| Manufacturer / Case | level | access | Real user loss? | Key message |
|---|---|---|---|---|
| COLDCARD 2026 | Seed generation / Firmware | No physical access required | Yes; Sweep waves from July 30, 2026 | Weakly generated keys can be reconstructed offline. |
| Trezor 2019/2020 | Hardware / physical | physically | not documented; extraction demonstrated | Physical ownership can be decisive in older designs. |
| TROPIC01 2026 | Secure Element | Laboratory, decapsulation | not documented; laboratory attack | Even security chips can be vulnerable to attack. |
| Ledger 2020 | Customer data | remote against DB | not through the leak itself | Manufacturer data can enable follow-up attacks. |
| Ledger Connect Kit 2023 | Software supply chain | remote / DApp | Yes | The wallet hardware itself was not compromised. |
| Tangem 2024 | Mobile App / Logs | Support configuration | No (manufacturer's information) | Key data can be exposed outside the chip. |
| OneKey Mini | Hardware integration | physically | not documented; extraction | CPU ↔ Secure Element is part of the architecture. |
| SafePal S1 | Firmware / Protection | physically | Not documented; no theft in the test | Weakness ≠ Asset theft. |
| Ellipal 2019 | Hardware / physical | physically | not documented; extraction | Air Gap does not protect against every error. |
| Keystone 3 Audit | Firmware / Hardware | Audit | not documented; findings resolved | External audits make risks solvable. |
A particularly problematic class of attack arises before the user even uses the device for the first time. The attacker doesn't have to steal immediately—they can prepare a compromised seed or a manipulated environment and wait for a larger investment: opening/repackaging, replacing with counterfeit devices, manipulated firmware/electronics, pre-defined seeds, manipulated companion cards, fake websites/apps.
| time | Event |
|---|---|
| Day 1 | Manipulation or knowledge of the seed |
| Day 5 | User activates the supposedly new wallet |
| Day 6 | small test transaction |
| Day 8 | larger Bitcoin transfer |
| shortly thereafter | complete transfer to an unknown address |
An attacker gains temporary physical access and manipulates the device undetected — during transport, storage, hotel stay, repair, shipping or personal handover.
A user might believe they are using a genuine device, even though it is a copy, a modified original, or a tampered-with used device. Authenticity verification and a controlled supply chain are part of the security model.
The most practically relevant scenario is also the least spectacular: The owner doesn't set up the wallet themselves, but receives a pre-initialized device or has the setup done by a merchant, intermediary, acquaintance, or "expert." Whoever controls the initial setup and knows the key or keeps a backup copy retains access later—regardless of who owns the device. Tangem warns: Devices are never shipped with pre-generated keys; an included "initialization password" is a warning sign. Copying to backup devices only happens once during the initial setup—a configured wallet cannot be subsequently cleaned up, but must be reset and recreated. Typical damage pattern: The outflow doesn't occur at the time of handover, but shortly after the first significant deposit. [17][18][21]
After a theft, no cause should be assumed prematurely. A structured investigation at several levels is advisable.
Originating address and transaction hash; time, amount, network fee; destination address and downstream wallets; consolidations and splits; swaps, bridges and other protocols; deposits to centralized exchanges or identifiable service providers.
A very short distance between the entrance and the unauthorized outlet may indicate automated monitoring or existing key access — but does not prove it.
| Event | Example time |
|---|---|
| Wallet activated | 2:05 PM |
| Received address created | 2:08 PM |
| BTC sent | 2:23 PM |
| Confirmation on the network | 2:31 PM |
| Unknown output transaction | 2:37 PM |
Manufacturer/model, serial/device information, firmware version, purchase date/seller, packaging and signs of tampering, updates performed, wallet app and pairing type. Important: If the circumstances are unclear, do not reset, update, or modify the device—this could make later testing impossible. Record the time of seed generation and the firmware version at that time (cohort testing). Retain the device and accompanying materials with a documented chain of evidence.
Installation source and version of the wallet software; suspicious apps/extensions/downloads; support contacts; screenshots, files and possible seed images; indications of remote access or malware; browser history related to setup and transactions.
It needs to be clarified whether the device was purchased directly from the manufacturer, via an authorized dealer, online marketplace, private individual, advisor, intermediary, or alleged financial service provider. The answer can significantly alter the risk assessment.
„"My hardware wallet has been hacked" only describes the perception. Technically possible scenarios include: (1) compromised seed, (2) predictably/weakly generated seed, (3) compromised hardware, (4) compromised firmware, (5) compromised software/app, (6) manipulated/misleadingly displayed transaction, (7) compromised supply chain, (8) social engineering or fake support.
A Appraise The cause should only be considered established if it is supported by technical or documentary evidence. Plausible alternative hypotheses must be explicitly identified.
It has proven effective to work from verifiable to unverifiable assumptions: first the cohort question (known safety notice regarding device/model series/production period — answerable without the involvement of third parties), then the documentable circumstances (procurement, initial setup, seed handling, support/phishing contacts, app source), then the blockchain (timeline, target structure, forwarding, endpoints), last The remaining technical scenarios could only be explained in a laboratory or with physical access. A finding marked as open is usable by investigative authorities; a cause determined too early is not.
| Attack scenario | Physical access | Seed directly required | Is it possible without device access? | Typical blockchain traces |
|---|---|---|---|---|
| Seed phishing | No | Yes | Yes | Outflow as per regular signed transaction |
| Weak seed production | No | No | Yes (offline reconstruction) | Outflow as per regular signed transaction |
| Tampered device | Before use / physical | Not necessarily | Yes, after manipulation | Outflow after deposit |
| Supply Chain | Before use | Not necessarily | Yes, after manipulation | often timely or event-driven |
| Fault Injection | Yes | No | No | Drainage after key extraction |
| Side Channel | Yes | No | No | Drainage after key extraction |
| Firmware vulnerability | dependent | dependent | depending on the attack | depending on the attack |
| App/Software Compromise | No | not necessarily | Yes | manipulated or authorized transaction |
| Seed in log files | No | indirect | Yes, provided data has leaked. | regularly signed outflow |
The matrix serves as an initial structuring tool and does not replace individual case review; different attack classes can be combined.
Additional security measures often increase complexity. Therefore, a security concept must not only protect against attackers, but also be easy and reliable for the owner to use consistently.
The term "hardware wallet" is not proof that only the victim had access to the private keys—conversely, an unauthorized transfer is not automatically a product defect. For a reliable initial assessment, document the following: manufacturer/model/generation, source and date of purchase, initialization, firmware/update history, method of seed generation and storage, smartphone/computer, wallet app and source, last legitimate access, time of asset receipt and unauthorized transfer, destination address, and other relevant information.
Two points are regularly overlooked: First, the device should be secured early and not reset Secondly, it must be examined whether other affected users with the same device type are known to have experienced the same issue within the same timeframe—if the case falls within a known affected cohort, this strongly suggests that the cause is not solely user-related. The legal assessment of any potential contributory negligence remains separate from this.
Hardware wallets significantly reduce many traditional cyber risks, but they are not an absolute barrier to security. The COLDCARD incident of 2026 demonstrates that an attacker doesn't need to physically possess or remotely take control of the device—if key generation is flawed, the security model fails at its very core. Conversely, not every transaction should be prematurely labeled a "hardware wallet hack"; the cause could be seed compromise, phishing, manipulated software, or supply chain risks.
The security of cryptocurrencies is not determined by the individual hardware wallet, but by the entire chain from the generation of the private key to the release of a transaction.
For blockchain forensics, the following questions are crucial: When were the assets transferred? Which address did they receive? How were they forwarded? Which exchanges, bridges, or service providers were used? And which technical explanation is actually consistent with the available evidence?
Manufacturer specifications are treated as such and do not replace an independent technical assessment. References last accessed in September 2026; damage levels are snapshots in time.
[1] Coinkite: Coldcard Security Advisory, 07/2026 · [2] Coinkite: Entropy Technical Deep Dive · [3] Coinkite: COLDCARD Security Update 5.6.1/1.5.1q · [4] TRM Labs: Inside the $116M Coldcard Hack, 08/2026 · [5][6] Trezor: TROPIC01 disclosure · [7] Ledger Donjon: Seed Extraction on Trezor, 2019 · [8] Kraken Security Labs: Trezor Flaw, 2020 · [9] Ledger: Data Breach Update, 2020 · [10] Ledger: Connect Kit Incident, 2023 · [11] Tangem: Log Issue, 2024 · [12] Unciphered: OneKey, 2023 · [13] Kraken: SafePal S1, 2021 · [14] Ledger Donjon: Ellipal, 2019 · [15] Keylabs: Keystone 3 Audit, 2023 · [16] BitBox02 Security Features · [17][18][21] Tangem: Pre-Activated Wallets / Firmware & Authenticity / Backup · [19] Ledger Donjon: LFI on TROPIC01, 06/2026 · [20] Tropic Square: TROPIC01 Security Advisory, 06/2026 · [22] COLDCARD: Security Status, 09/2026.
David Lüdtke
Managing Director · OSINT Analyst & Crypto Forensic Expert · Finanz Forensik GmbH
Court-admissible crypto transaction analysis, OSINT-based asset investigation, and expert reports for defense attorneys, insolvency administrators, and companies. Certified Crystal Expert (CECF, CEEI, CEUI). Finanz Forensik Supports law firms, companies, investigative bodies and insolvency administrators — focus areas: Blockchain forensics, wallet analysis, court-admissible documentation, OSINT.
Contact: postfach@finanz-forensik.de · +49 6057 9189145 · finanz-forensik.de
We clarify the cohort issue, secure the device and timeline, reconstruct the blockchain trace, and prepare the findings in a legally sound manner for the law firm and investigating authority.
