What is a hardware wallet?

A hardware wallet is a purpose-built physical device that stores or derives private keys and signs requests separately from a general-purpose computer or phone. When the design and implementation work as intended, the connected application receives a signature without receiving the private key itself.

The device does not contain blockchain assets as files. Balances and transaction history remain part of network state. The hardware controls signing material that may authorize activity under the relevant network or account rules.

How transaction preparation and signing are separated

A typical workflow has two sides:

1. A host application reads blockchain data and prepares an unsigned transaction or signing request.
2. The hardware device parses the request, applies its authorization controls and displays available details.
3. After confirmation, the device signs internally.
4. The host receives the signature or signed transaction and broadcasts it.

Bitcoin’s PSBT specification provides one standardized way for transaction creators, signers and finalizers to exchange information without every participant holding every private key. It also defines output information that helps a signer identify recipients and change. Other networks use different request formats, so a device must support the applicable chain and transaction type rather than merely accept arbitrary bytes. BIP-174

NIST describes hardware wallets as devices that hold keys in protected hardware and provide signing functions without exposing those keys to applications. “Protected hardware” is a design goal and category description, not proof that every product, firmware version or setup has identical properties. NISTIR 8301

The device screen is part of the authorization boundary

Key isolation answers whether the host can directly copy signing secrets. It does not answer whether the request is the one the user intended. A compromised host can try to replace an address, modify an amount or present a different contract interaction.

A device can reduce this risk only when it independently interprets and displays meaningful details. Ledger’s developer documentation calls human-readable presentation clear signing and distinguishes it from blind signing, where the device cannot fully interpret the payload. This is vendor terminology, but the underlying boundary is general: approving an opaque hash provides less independent verification than checking the actual destination and action on a trusted display. Ledger developer documentation: clear signing

Display size, supported transaction fields and contract decoding vary. Even a correctly displayed address may be difficult to compare, and some operations contain permissions or nested calls that cannot be summarized by one amount. A confirmation button is useful only for details the device can accurately present and the user actually checks.

Hardware, cold and non-custodial describe different properties

• Hardware wallet identifies a physical signing device.
• Cold wallet identifies an offline authorization workflow.
• Non-custodial wallet identifies who controls the authorization mechanism.

A hardware wallet can participate in a cold workflow, but it may also communicate with an online host during normal use. It is often used non-custodially, yet it can be one signer in a multisignature policy or part of a managed arrangement. One device may be insufficient to authorize an account, and possession of the device may be insufficient if another signer or policy condition is required.

Connectivity also has several forms. USB, Bluetooth, NFC, QR codes and removable media create different data paths; none alone determines custody or proves that a request is valid. Trezor’s educational documentation likewise describes the device as keeping keys separate while requiring the user to verify transaction details on the device. Trezor: what is a hardware wallet?

Device PIN, recovery phrase and passphrase are not interchangeable

A device PIN normally restricts local access to that physical device. It does not automatically change the underlying wallet keys. Many hardware wallets derive keys from seed material that can be backed up as a recovery phrase; BIP-39-compatible implementations may also accept an additional passphrase that changes the resulting seed and wallet. BIP-39

The recovery material is a parallel route to the keys. Anyone with the required phrase, passphrase and compatible settings may be able to reconstruct them on another device or application. Conversely, losing both the device and sufficient recovery information can prevent access.

Not every hardware wallet uses BIP-39, and one phrase may not restore imported keys, multisignature policy information, account descriptors, labels or smart-account recovery settings. Recovery should be assessed against the specific architecture rather than inferred from the presence of a phrase.

Failure modes beyond remote key extraction

Hardware separation can reduce a host computer’s direct access to private keys. It does not eliminate:

• firmware defects, malicious updates or unsupported transaction parsing;
• tampering before delivery, during initialization or through physical access;
• deceptive host interfaces and incomplete device displays;
• recovery-phrase disclosure, transcription errors or incompatible restoration;
• signing an unintended approval, message or contract operation; or
• loss of other keys or policy data in a multisignature or smart-account setup.

Device authenticity checks, firmware provenance and initialization instructions are product-specific. They should not be replaced with the general claim that hardware wallets are automatically safe. Ethereum’s security guidance similarly treats hardware devices as one protective measure while retaining phishing, recovery-secret and malicious-transaction risks. Ethereum security

FAQ

Does losing the device mean the assets are lost?

Not necessarily. A compatible recovery method may reconstruct access if all required inputs and account settings remain available. If the backup is missing, incorrect or incomplete for the account design, the device itself cannot supply what was never preserved.

Can malware on the host spend without obtaining the private key?

It cannot create a valid key-based signature on its own if the key remains isolated and the account requires that signature. It may still present a malicious request and persuade the device user to authorize it. Key isolation and transaction verification are separate controls.

Learn more

For a longer product-category overview, see Hardware Wallet Guide. Treat product comparisons and recommendations there as supplementary material; the technical definition above relies on specifications and official documentation.

Related concepts

Explore cold wallets, non-custodial wallets, private keys and seed phrases, or return to the Crypto Glossary.

Sources

• NISTIR 8301: Blockchain Networks — Token Design and Management Overview — hardware-wallet design, protected key storage and signing boundaries.
• BIP-174: Partially Signed Bitcoin Transaction Format — creator, signer and finalizer roles and transaction information for signers.
• Bitcoin Developer Guide: wallets — separation between networked wallet functions and signing devices.
• BIP-39: Mnemonic code for generating deterministic keys — mnemonic-to-seed processing and optional passphrases in compatible implementations.
• Ledger developer documentation: clear signing — human-readable device verification and blind-signing limits.
• Trezor: what is a hardware wallet? — device-side key isolation and transaction confirmation.
• Ethereum: security — recovery-secret, phishing and malicious-signing risks.