A user holds significant cryptocurrency and faces a practical problem: how to sign transactions on a Trezor hardware wallet without ever exposing the device or its private keys to an internet-connected computer. The standard workflow involves installing Trezor Suite on a networked machine, connecting the device, and approving transactions on the hardware screen. But for high-value holdings or threat models that treat any online exposure as unacceptable, an air-gapped setup offers stronger isolation. The device never connects to the internet; transaction construction happens on an offline computer; and only the signed transaction moves to a networked machine for broadcast.

This approach requires careful planning and discipline. It is not simply unplugging the ethernet cable. An air-gapped workflow involves separate hardware, deliberate information flow between machines, and a clear understanding of what each device does and what it must never do. The goal is to ensure that private key isolation—the foundational security property of any hardware wallet—remains intact throughout the entire signing process, even when moving transaction data between devices.

Why air-gapped workflows matter for hardware wallets

A hardware wallet’s core promise is private key isolation. The Trezor device stores the recovery seed and derives all cryptographic keys internally, never exposing them to connected computers or networks. However, the software application that creates transactions, displays balances, and manages addresses still runs on an internet-connected machine in most workflows. That separation between key storage and transaction composition is meaningful, but it is not absolute isolation.

An attacker with access to a networked Trezor Suite installation could observe unconfirmed transaction data, wallet addresses before they are used, fee calculations, or the order in which addresses are generated. They cannot steal the private keys, but they can gather context about the wallet’s activity and future transaction patterns. For most users, this risk is acceptable because the attacker would still need to physically access the Trezor device to approve and sign transactions. For users managing very large amounts, operating in high-threat environments, or holding assets for institutional purposes, the additional step of air-gapping the entire transaction composition process reduces that observational risk.

The second benefit is operational security discipline. An air-gapped setup forces explicit decisions about what information leaves the offline machine and what stays local. USB transfers become visible events rather than automatic background processes. Firmware updates, balance checks, and address derivations cannot happen casually because each action requires intentional media movement and verification. This friction, while sometimes inconvenient, serves a purpose: it makes mistakes harder and opportunistic compromises less effective.

The third consideration is legal or institutional compliance. Some organizations or jurisdictions require demonstrable evidence that high-value key material never touched a networked device. An air-gapped setup with documented procedures can satisfy those requirements more clearly than a standard Trezor Suite installation, even though both achieve the same cryptographic isolation of private keys.

Hardware and media requirements for the air-gapped machine

An air-gapped computer can be used, repurposed, or even borrowed hardware, but it should meet certain practical criteria. The machine must be capable of running Trezor Suite (Windows, macOS, or Linux), have at least one USB port for the Trezor device, and ideally have either no WiFi capability or a physically disabled network card. Ethernet should be disconnected or removed. A laptop with WiFi disabled and no wired network is acceptable; a desktop with the network card removed is even better. The key principle is that the machine should have no hardware pathway for data to leave except through deliberate USB transfers.

Removable media is the critical bridge. USB flash drives serve as the transport mechanism for transaction files between machines. A typical workflow uses two USB drives: one for moving unsigned transaction data from the online machine to the offline machine, and another for moving signed transactions back. In practice, a single drive can be reused, but keeping two separate drives creates clearer visual distinction and reduces the risk of confusion. The drives should be formatted and wiped regularly to avoid accumulating unrelated data.

The offline machine’s operating system should be clean and recently installed. This is not strictly necessary for Trezor Suite functionality, but it reduces the risk that malware left from previous use could interfere with the signing process or observe sensitive data. A minimal Linux installation (Ubuntu, Debian, or Fedora) can be lighter weight and easier to verify than Windows or macOS, though all three are acceptable if kept updated. The critical step is disabling all automatic updates and network features before disconnecting the internet.

Recovery and backup storage for the offline machine itself should also be considered. If the air-gapped machine fails, the Trezor device remains secure (its private keys are on the device, not the computer), but any transaction drafts, address derivation records, or configuration might be lost. A separate backup drive kept offline and encrypted can store this supporting data without creating a network vulnerability.

Setting up the offline machine with Trezor Suite

Installing Trezor Suite on the air-gapped machine follows the standard procedure: download the application from the official Trezor website using the online machine, transfer it via USB drive to the offline machine, verify the signature if possible, and run the installer. The key difference is that after installation, the offline machine remains permanently offline. No automatic update checks, no wallet data synchronization, and no background network requests.

During initial setup, connect the Trezor device to the offline machine and follow Trezor Suite’s recovery process if this is a new device, or import an existing recovery seed if restoring a wallet. The device will display recovery seed words on its own screen; never type the seed into the networked machine or store it anywhere except the physical Trezor or a secure offline backup. Once the wallet is initialized, the offline Trezor Suite installation will recognize addresses and allow transaction composition, but it will not be able to query the blockchain for balances or broadcast transactions.

To work around this limitation, the standard air-gapped workflow separates address discovery from transaction signing. The online machine queries the blockchain for confirmed transactions and wallet balance using either a block explorer or a private full node running on the same network. This information is used to identify which addresses have received funds, how much balance is available, and what transaction inputs are available to spend. The online machine constructs a transaction file in a standard format (such as PSBT, or Partially Signed Bitcoin Transaction for Bitcoin-based assets), exports it to a USB drive, and transfers it to the offline machine.

The offline Trezor Suite installation receives the unsigned transaction file, displays its details on the connected Trezor device screen, and prompts for approval. The user verifies the destination address, amount, fee, and network on the hardware screen—not on the computer display, which could be compromised. After approval, the Trezor device signs the transaction and Trezor Suite exports the signed transaction file back to the USB drive. This signed file, which contains the transaction data plus the cryptographic signature but not the private key, can then be safely transferred to the online machine and broadcast.

Transaction workflow and media isolation in practice

The operational routine for sending funds from an air-gapped Trezor setup follows several distinct steps. First, the online machine identifies transaction inputs—specific cryptocurrency addresses and amounts that will be spent—by querying a blockchain or connecting to a full node. Second, it constructs an unsigned transaction specifying the inputs, outputs (destination addresses and amounts), and fees, and exports this as a file to a USB drive. Third, the user physically transfers the USB drive to the offline machine, loads the unsigned transaction into Trezor Suite, and connects the Trezor device.

Fourth, the Trezor device displays the transaction details on its own screen, including inputs, outputs, fee amount, and change address. The user verifies these details match the intended transaction—not by trusting the computer display, but by reading the hardware wallet’s integrated screen. This is where transaction verification on the device screen becomes the actual security checkpoint. Fifth, the user approves the transaction on the Trezor device using its physical buttons. The device signs the transaction internally using the private key stored on the device, and Trezor Suite exports the signed transaction to another USB drive.

Sixth, the user transfers the signed transaction USB drive back to the online machine, loads the signed transaction into Trezor Suite or another compatible tool, and broadcasts it to the network. From the moment the transaction is broadcast, it follows the normal network rules for the cryptocurrency: it is propagated by nodes, included in a mempool, and eventually added to a confirmed block.

The critical security property throughout this workflow is that the private key never leaves the Trezor device, and the device never connects to the internet. The offline computer’s Trezor Suite installation can see the unsigned transaction data and must be trusted not to modify it between signing and broadcast, but it cannot modify the signature itself because the signature is created on the device. The online machine can see the unsigned and signed transaction data, but it never has access to the private key.

Managing wallet state and address discovery offline

A subtle challenge in air-gapped workflows is keeping track of which addresses have been used and which are available for receiving new funds. With the offline machine disconnected from the network, Trezor Suite cannot query the blockchain to determine whether an address is already in use. The standard solution is to generate a detailed address list on the offline machine and transfer it to the online machine via USB, then use the online machine to check which addresses have received transactions.

Most hardware wallets, including Trezor, use a cold wallet architecture where the addresses are deterministically derived from the recovery seed. This means the same sequence of addresses will always be generated from the same seed, without requiring any state stored online. The user or a tool running on the online machine can independently derive the same address list and check it against the blockchain. Trezor Suite on the offline machine can export a list of receiving addresses and their derivation paths to a file on a USB drive. The online machine then uses this list to scan the blockchain and identify which addresses have been used and what the current balance is.

This approach requires some care. The address list itself is not sensitive—knowing which addresses belong to a wallet does not allow spending from that wallet without the private key. However, if the address list is transmitted from offline to online and then observed by an attacker, they can begin analyzing the wallet’s activity patterns. Some users prefer to generate addresses in small batches rather than exporting a large pre-computed list, or to use a separate tool on the online machine to derive addresses without transferring the complete list from offline storage.

For assets other than Bitcoin and similar UTXO-based cryptocurrencies, the workflow is similar but the transaction construction differs. Ethereum and ERC-20 tokens use an account model with nonces and gas prices rather than UTXOs. The online machine still constructs the unsigned transaction, the offline machine still signs it with the Trezor device, and the signed transaction is still broadcast online. The details of what gets displayed on the Trezor screen and verified before signing will be different, but the principle of offline composition and device-based signing remains the same.

Integration with Tor and additional privacy layers

An air-gapped Trezor Suite setup already isolates the key material from the internet. Adding Tor integration on the online machine provides an additional layer by obscuring which blockchain or node the signed transactions are broadcast to. Trezor Suite itself includes Tor integration, but in an air-gapped workflow, the Tor connection would run on the online machine while broadcasting signed transactions, not on the offline machine.

Some users combine air-gapping with a dedicated node running on the online machine or a separate device on the same network. Rather than broadcasting transactions to a random public node, the signed transaction can be sent to a full node under the user’s control, which then validates and relays it to the wider network. This reduces the risk that a compromised node or network monitoring could link the transaction broadcast to the user’s IP address.

The Tor integration and private node setup are orthogonal to the air-gapped architecture. They address different threat models: air-gapping protects private key material from observation or interference, while Tor and node privacy address network-level surveillance. A user might implement one, both, or neither depending on their specific security requirements and tolerance for operational complexity.

Practical challenges and recovery procedures

Air-gapped workflows introduce friction that must be managed carefully. The most common issue is a mismatch between the online machine’s view of the wallet state and the offline machine’s view. If the online machine is out of sync with the blockchain—for example, if it is showing an old balance or has not yet detected a confirmed transaction—the unsigned transaction it creates may reference inputs that have already been spent. The Trezor device will still sign the transaction, but it will fail when broadcast because the inputs no longer exist.

The solution is to ensure the online machine is fully synchronized before creating unsigned transactions. For Bitcoin, this typically means waiting for block confirmations and using a reliable blockchain data source such as a personal full node or a trusted block explorer queried over Tor. For Ethereum, it means confirming current nonce values and gas prices before composition. The unsigned transaction file should include timestamps or blockchain height information so the user can verify how recent the data is before transferring it offline for signing.

Another practical issue is managing recovery seed backups in an air-gapped context. The Trezor device itself is a secure backup—the seed is stored in the hardware wallet and can be recovered by reinitializing the device. However, if additional offline backups are kept, they should be stored separately from the offline machine and encrypted. A written seed backup that is stored with the offline computer becomes a single point of failure if that machine is lost, stolen, or exposed to physical tampering.

Recovery procedures should be tested before relying on the air-gapped setup for actual high-value transactions. A test transaction using small amounts allows verification that the workflow functions correctly, that both the offline and online machines perform their intended roles, and that the user can successfully sign and broadcast a transaction without errors. This test run is especially important if the setup is infrequently used, as the operational details can be easily forgotten over time.

Auditing and maintaining Trezor Suite security over time

The trezor suite application is open-source, which means its code can be reviewed and the binary can theoretically be verified to match the published source. For users implementing an air-gapped setup, this auditability is particularly valuable. The offline machine should not receive automatic updates, but periodic updates should be reviewed and applied manually to address security issues.

The update process for the offline machine should follow the same pattern as the initial installation: download the updated Trezor Suite on the online machine, transfer it via USB to the offline machine, verify its signature if possible, and install it offline. The offline machine then remains offline again until the next update. This approach prevents the offline installation from falling severely outdated while maintaining the principle that it remains disconnected from the network.

For very high-security implementations, some users maintain multiple offline machines or rotate hardware periodically. A machine used for a single large transaction and then wiped or stored can provide stronger isolation than a single continuously reused machine. This approach requires more overhead but can be justified for institutional or very large personal holdings.

The Trezor device firmware itself is updated through the device’s USB connection, not through the network. Trezor Suite will notify the user if a firmware update is available, and the update can be performed on either the offline or online machine—the device handles the cryptographic verification of the firmware. As with Trezor Suite updates, firmware updates should be reviewed before applying, especially if the device is in use for high-value transactions.