A hardware wallet can keep private keys away from an internet-connected computer. It cannot make every transaction presented for signature legitimate.
That distinction matters after wallet maker OneKey said it reproduced a transaction replacement attack against an older version of Ledger’s Ethereum app in a laboratory environment. Ledger fixed the issue in Ethereum app version 1.22.2, according to CoinTelegraph, and no user funds were reported lost.
The immediate lesson is straightforward: affected software should be updated. The larger lesson is more important. Self-custody security does not end when a private key moves onto a dedicated device. Users still depend on wallet software, transaction construction, device displays and their own ability to recognize when the final transaction differs from the one they intended to authorize.
A secure chip can protect a key while the person controlling that key still signs the wrong instruction.
Private-key protection is only one part of custody
Hardware wallets are often described as if they remove trust from crypto transactions. In practice, they relocate and reduce trust.
The private key may remain isolated inside the device, but the transaction typically begins elsewhere. A browser extension, desktop application or mobile wallet helps construct the request. A decentralized application may supply contract interactions. A computer or phone relays the unsigned transaction to the hardware device. The user then relies on the device to display enough accurate information to make an informed decision.
That creates a chain of dependencies:
1. The intended application must be authentic. 2. The wallet interface must construct the expected transaction. 3. The hardware device must receive and interpret it correctly. 4. The device must display the critical details accurately. 5. The user must compare those details with an independent expectation. 6. The signed transaction must be broadcast and confirmed as expected.
Private-key isolation helps prevent malware from simply extracting a key and spending funds later. It does not automatically prevent a compromised interface, malicious contract or transaction-manipulation technique from inducing an authorized signature.
That is why “the keys never left the device” is not a complete security conclusion. An attacker may not need the keys if the user can be persuaded—or technically misled—into signing an unwanted transfer.
The trusted display is a security boundary
The OneKey test concerned transaction replacement on an outdated Ethereum application. The supplied report does not establish losses in the wild, and users should not treat a laboratory reproduction as proof of a broad active campaign.
It does, however, reinforce the role of the hardware wallet’s own screen.
A computer monitor cannot be the final source of truth when the computer is the environment the hardware wallet is meant to distrust. The meaningful check occurs on the signing device itself. At a minimum, that review should cover the destination, amount, asset and network whenever the device can present them.
Contract interactions can make this harder. A simple transfer may produce recognizable information. A more complex decentralized-finance transaction can involve contract addresses, encoded calls, token approvals and results that are not obvious from a short device display.
When the device cannot render the action in understandable terms, users face a degraded security decision. They may still choose to proceed, but they should recognize that they are no longer verifying the full economic effect. They are relying more heavily on the connected application and contract interface.
This is the practical weakness behind casual “just use a hardware wallet” advice. The device is valuable, but its protection depends on what it displays and whether the owner checks it.
Updates belong inside the custody process
Ledger addressed the reproduced issue in Ethereum app version 1.22.2. That makes software inventory—not merely device ownership—a core part of wallet security.
A hardware wallet may involve several separately updated components: device firmware, coin or network applications, companion software and browser integrations. An owner who keeps the physical device secure but leaves one component outdated may continue operating with a known weakness.
Updates also carry their own risks. Phishing campaigns routinely exploit the urgency surrounding security notices, directing users toward fake software, fraudulent browser extensions or requests to enter recovery phrases.
A defensible update process should therefore be deliberate:
- Begin from a previously verified official application or bookmarked vendor domain. - Avoid update links delivered through unsolicited email, direct messages or search advertisements. - Confirm which component is being updated, rather than assuming that current firmware means every installed network app is current. - Read the device screen during the update and subsequent transaction. - Never enter a hardware-wallet recovery phrase into a website or ordinary computer application. - Test normal operation with a low-value transaction after a significant change.
Businesses should document this process instead of allowing individual employees to improvise it. The person who discovers an update notice should not necessarily be the only person approving its installation on a wallet controlling material funds.
Verification must happen before and after signing
A strong transaction workflow has two checkpoints.
The first occurs before the signature. Users should know the expected recipient, network, asset and amount before connecting the hardware wallet. Recipient addresses should come from a controlled source, not an unverified message or clipboard alone. High-value destinations can be established through a small test transfer and retained in an internal address book.
The second checkpoint occurs after broadcast. The sender should verify that the confirmed onchain transaction matches the approved instruction. That means checking the actual destination and value through a trusted block explorer or wallet record rather than assuming that a successful interface message proves correct execution.
Post-signing verification cannot reverse a final transfer. It can, however, detect a compromised workflow before the same process is used again. For recurring treasury payments, that can prevent one bad transaction from becoming a repeated operational failure.
This is particularly important when multiple people participate. A business may have one employee prepare a payment and another sign it. If the signer merely confirms that “a transaction is ready,” separation of duties provides little protection. The approver needs an independent record of the intended details and must compare it with the hardware device’s display.
Separate routine activity from material reserves
Not every transaction deserves the same operational burden. Signing a small experimental interaction can reasonably follow a lighter process than moving treasury reserves.
Wallet architecture should reflect that difference.
A practical setup may separate daily-use funds from long-term holdings, experimental decentralized applications from known counterparties, and routine payments from exceptional transfers. The objective is not to make compromise impossible. It is to limit how much a single mistaken signature can expose.
For individuals, that may mean keeping only an operational balance in the wallet used for frequent contract interactions. For a business, it may mean transfer limits, multiple approvals and a dedicated signing environment for material payments.
These controls address a weakness hardware alone cannot solve: a valid signature is not necessarily a valid business decision.
Recovery phrases require a different threat model
Transaction verification and software maintenance should not distract from the most consequential credential in many self-custody setups: the recovery phrase.
A fake update request that asks for a recovery phrase is not performing a legitimate update. The phrase can recreate control of the wallet, potentially bypassing the physical device entirely.
Users should treat recovery materials as offline secrets and clearly separate three events:
- authorizing a transaction, - updating wallet software, - restoring a wallet from backup.
A routine signature or update should not unexpectedly turn into a recovery procedure. If an interface introduces that request, the safe response is to stop and verify the situation through a separate channel.
For organizations, access to recovery material should also be distinct from ordinary transaction preparation. Otherwise, the same compromised workstation or employee account may expose both daily operations and the ultimate backup.
The grounded takeaway
OneKey’s laboratory test does not show that hardware wallets are ineffective. It shows why their security claims must be understood precisely.
Ledger’s fix in Ethereum app 1.22.2 addresses the reported outdated-app issue, and no user funds were reported lost. Owners should confirm that their relevant software is current through trusted channels.
But updates are only the immediate control. The durable control is a signing process that treats the hardware display as a checkpoint, verifies material transactions independently and limits the funds exposed to routine activity.
Self-custody gives the owner final authority. It also means that a technically valid signature can execute an operationally invalid instruction. The device protects the key; the user or custody team must still protect the decision.