A hardware wallet is not a storage device in the ordinary sense. It is a small computer that performs one operation and refuses to export the material it uses to perform it.
The key never leaves the device
Keys are generated on the device itself, from entropy produced there, and are written into storage that the firmware will not read out.
To spend, the computer sends an unsigned transaction, the device signs it internally, and only the signature comes back.
A compromised computer therefore sees a signature it could have obtained anyway, and never sees the key that produced it.
The screen is the actual security boundary
Malware cannot extract the key, but it can present a transaction different from the one the user intended and ask the device to sign it.
The device's own display exists to defeat this, showing the destination and amount from the data it is about to sign rather than from what the computer claims.
Verification on that small screen is the step that provides the protection, and skipping it reduces the device to an inconvenient signing key.
Secure elements resist physical access
Better devices store keys in a chip designed to resist extraction through physical probing, voltage manipulation and timing analysis.
A device protected only by a general-purpose microcontroller can often be read out by someone with the hardware in hand and sufficient expertise.
This distinction matters mainly for the case where a device is stolen, since remote attacks are constrained by the isolation rather than by the chip.
Contract interactions weaken the guarantee
Signing a simple transfer is easy to verify because the amount and destination are legible. Signing a contract call is not.
Without the ability to decode the call, the device can only show data the user cannot evaluate, which restores blind approval.
Devices that parse common contract types and display the intent in plain language close part of this gap, and unfamiliar contracts still fall outside it.
Supply chain and recovery remain the weak points
A device tampered with before delivery can be built to generate predictable keys, which is why initialisation should always happen with a freshly generated phrase.
A device arriving with a phrase already printed is compromised by definition, and this remains one of the more common ways holdings are lost.
The recovery phrase also sits outside the device entirely, so however well the hardware performs, the backup is protected only by wherever it is kept.