A cryptocurrency holder with significant assets faces a recurring operational problem: how to move funds from cold storage to an exchange, send a payment, or consolidate holdings without exposing private keys to any internet-connected environment, even momentarily. The standard workflow of connecting a hardware wallet, reviewing the transaction on the device, and then broadcasting it to the network still requires at least one machine to have internet access. For users managing large balances or operating under strict security protocols, that brief window of vulnerability can feel unacceptable. The solution is not to abandon hardware wallets entirely, but to separate the signing device from the broadcasting device completely.

Trezor supports offline signing workflows that eliminate direct internet exposure during the critical moment when a transaction is constructed and approved. Using air-gapped systems, QR code transmission, and USB-only signing protocols, a user can operate a Trezor device on a machine that never connects to the network, while a separate internet-connected system prepares the unsigned transaction and later broadcasts the signed result. This approach requires more operational discipline and technical understanding than a standard connected workflow, but it moves the trust boundary significantly. The signing device is no longer a network endpoint at any point; it is purely a cryptographic engine that receives data in, produces a signature, and hands control back to the operator.

The architecture of air-gapped signing

An air-gapped setup involves at least two machines. The first machine runs Trezor Suite or compatible software and maintains no network connection. This signing computer receives unsigned transaction data through a manual mechanism—typically a QR code photographed from a second machine, a USB drive copied in one direction only, or a direct USB connection that is immediately disconnected after data transfer. The second machine, the broadcasting computer, has full internet access and runs standard blockchain node software or connects to public RPC endpoints. Its role is strictly to prepare the transaction structure and later broadcast the signed result.

The key insight is the direction of data flow. The signing machine receives transaction details as input but never sends information outbound. No network interface is required. The broadcasting machine never sees the private key or recovery seed; it only receives the finalized, signed transaction in a format suitable for blockchain transmission. This separation is not a theoretical improvement—it eliminates the class of exploits that compromise a machine during or after signing. A remotely executed vulnerability on the signing computer cannot exfiltrate keys because there is no network path outward. Malware that might attempt to modify transaction details before signing is bypassed because the Trezor device displays the transaction on its own screen, independent of the host computer’s operating system.

The practical limitation is that offline signing requires more human effort. The operator must physically manage the transfer of unsigned transaction data, verify addresses on the Trezor device’s screen using only what appears there, and manage the transition from offline signing to network broadcast. Convenience is traded for a measurable reduction in the remote attack surface. For most users, this trade-off is unnecessary; a properly updated computer with a hardware wallet provides adequate security. But for users managing institutional funds, maintaining long-term custody of appreciated assets, or operating under regulatory or personal security mandates, the additional friction is acceptable.

QR code workflows: Visual verification and USB avoidance

Trezor Model T and Model One+ support QR code transmission through an optional camera module or an external camera attached to a separate computer. The general sequence is: the offline machine displays an unsigned transaction as a QR code; an internet-connected camera captures it; the transaction structure is reconstructed on the broadcasting machine and sent to a blockchain or relay node; the signed result is captured as a return QR code from the Trezor device and photographed back to the broadcasting machine.

The advantage of this workflow is that no physical connection between machines is required. An air-gapped room can contain the signing computer and Trezor device, while transaction data flows through visual channels only. The disadvantage is that QR codes have size limitations, particularly for complex transactions with multiple inputs or outputs. A transaction that exceeds the QR code capacity must be split across multiple codes or encoded differently. Additionally, the QR workflow is only as reliable as the camera and lighting conditions; a blurry image or misread code can cause the transaction to fail or be misinterpreted.

The practical strength of QR signing is address verification. When the Trezor device displays a transaction on its own screen, it shows the destination address in a format the user can read and check against an independently verified address list. The operator can compare what the Trezor screen shows against what the broadcasting machine prepared; if there is a mismatch, the transaction is rejected locally on the signing device. This is the core security property: the user approves the transaction by directly observing its critical details on hardware that they control, not on the computer that prepared it. Even if the broadcasting machine is compromised and attempts to redirect funds to an attacker’s address, the Trezor device’s display prevents that from succeeding without the user’s explicit approval of the wrong destination.

USB-only signing: Disconnection protocols for the paranoid

A simpler offline workflow uses USB for data transfer but operates under strict isolation rules. The signing computer is configured to never auto-mount USB drives from external sources, never open email or browser applications, and disconnect from the network permanently. After the recovery seed is restored and the Trezor device is set up with a strong PIN and optional passphrase, the signing computer can be used for transaction approval as needed. Each time a transaction arrives, it is transferred via USB, signed on the Trezor device, and the signed result is returned via a second USB operation to the broadcasting machine.

This workflow avoids QR code complexity but requires discipline around USB drive handling. The operator must maintain separate USB devices for inbound and outbound transfers, or use a USB hub with directional access control. Some users implement physical locks or write-protection on USB drives to prevent accidental writes from the signing computer to an inbound drive. The goal is to make any data leakage from the signing machine to the outside world obviously detectable or impossible by default. A USB drive that is mounted read-only cannot receive data from the offline machine, only provide it.

The USB workflow is faster for rapid transaction signing, making it practical for active custody scenarios where transactions occur multiple times per day. It is also more flexible for transaction size, since USB transfers are not limited by QR code capacity. However, it requires more careful operational setup and carries a small risk that a USB device could be compromised if it spends time in an internet-connected environment. The solution is to treat USB devices as single-use: a drive formatted and used exclusively for outbound broadcasts is less vulnerable than a drive that moves between machines frequently.

Setting up an offline Trezor device

The setup process begins with a dedicated machine that will never connect to the internet. This can be a laptop with networking disabled in BIOS, a desktop with no network card, or a virtual machine configured with no external network access. Some users purchase older machines known for reliability and firmware simplicity, while others use live USB distributions that are built for security and minimal network features. The operating system choice matters less than the commitment to never connecting it after setup.

Install Trezor Suite or compatible software (such as Python utilities for advanced workflows in this guide) on the signing computer before it goes offline. Generate the recovery seed on the Trezor device or restore an existing one using an offline method. Set a strong PIN and, if desired, a passphrase that adds an additional layer to the seed. The passphrase is particularly useful in offline workflows because it allows the same hardware wallet to maintain multiple address spaces; different passphrases produce entirely different sets of derivation paths and addresses.

After setup, the signing machine should not receive any software updates or new installations while offline. Its security is static, frozen at the moment of initial configuration. This is acceptable because the attack surface is minimal—no network, no email, no web browser. The machine’s operating system vulnerabilities only matter if an attacker can deliver a payload, and a device with no network connection and no external data ingestion is a difficult target. The Trezor device itself receives firmware updates through a connected machine during setup, but after that, the device stores all update verification signatures on its own secure element, so updates can be applied later through any machine without compromising the isolated environment.

Transaction flow: From broadcast machine to signature

The broadcasting machine is a standard internet-connected computer running a full node, a light client, or connecting to public RPC endpoints. Its role is to construct the unsigned transaction. For Bitcoin, this typically involves gathering unspent transaction outputs (UTXOs) from the blockchain, creating the transaction structure with inputs and outputs, and computing fees. For Ethereum and ERC-20 assets, it constructs the smart contract interaction or simple value transfer. The transaction is not signed on the broadcasting machine; instead, a descriptor or partially signed transaction (PSBT, in Bitcoin terminology) is created.

The unsigned transaction is then transferred to the signing machine. In a QR workflow, the broadcasting machine displays the PSBT or transaction descriptor as a QR code. In a USB workflow, the transaction is written to a USB drive and transferred. The signing machine receives this data, imports it into Trezor Suite or a compatible application, and presents it to the operator for review. At this point, the Trezor device’s screen displays the critical transaction details: the destination address, the amount, and the network fee.

The operator verifies the information against an independently maintained list of destination addresses. This is crucial. If the operator is sending to a cold storage address they control, they should have that address written down, memorized, or stored in an offline address book. They compare what the Trezor device shows against their records. If there is a match, they approve the transaction by entering their PIN on the Trezor device. The device then signs the transaction using its private key, which never leaves the device. The signed transaction is returned to the signing machine, where it can be exported as a QR code (photographed by the broadcasting machine) or written to a USB drive.

The broadcasting machine receives the signed transaction and broadcasts it to the blockchain network. At this point, the transaction is public, immutable (once confirmed), and irreversible. The signing machine plays no further role. Future transactions repeat this sequence: prepare, transfer, review, sign, broadcast.

Passphrase isolation: Multiple address spaces from one seed

A passphrase in Trezor’s context is not a password to unlock the seed; it is additional entropy mixed with the seed during key derivation. Two passphrases, even slightly different ones, produce entirely separate sets of addresses. This property makes passphrases useful in offline workflows because a user can maintain multiple address spaces on the same hardware wallet without revealing which passphrase is in use.

The practical benefit is operational compartmentalization. A user might keep one passphrase for daily transaction addresses and a different passphrase for long-term cold storage. If the device is lost or stolen, an attacker possessing the recovery seed cannot access the funds without knowing the passphrases. The passphrases are entered on the Trezor device itself during transaction approval; they are never stored on the device or transmitted to the signing machine software. Each transaction approval requires re-entering the correct passphrase, which is inconvenient but adds a significant security layer.

In an offline workflow, passphrases solve another problem: they allow the same recovery seed to support multiple segregated portfolios. One passphrase might be used for a Bitcoin cold storage address; another for Ethereum; another for a decoy wallet with a small amount of funds. If coercion or surveillance becomes a concern, the attacker’s access is limited to one portfolio, and the existence of other passphrases is unknown. This is advanced operational security, appropriate only for users managing truly significant assets or those operating under genuinely high-threat conditions. For ordinary users, a single passphrase or no passphrase at all is sufficient.

Monitoring balances without exposing the signing device

An operational challenge in offline signing is balance verification. The signing device is offline, so it cannot query the blockchain to determine how much cryptocurrency is currently controlled. The operator must use the broadcasting machine or a third machine to monitor balances independently. For Bitcoin and similar UTXO-based cryptocurrencies, the balance is derived from the addresses generated by the Trezor wallet, which can be retrieved by exporting the public key or extended public key (xpub) to the broadcasting machine.

This export is safe. A public key or xpub reveals all generated addresses and current balances, but it does not expose the private keys. An attacker with only the xpub cannot spend the funds. The operator can keep the xpub in a text file on the broadcasting machine and use it to monitor activity without the signing machine. For account-based cryptocurrencies like Ethereum, the Trezor device generates one or more addresses during setup, which can be similarly monitored using a standard blockchain explorer or a local node on the broadcasting machine.

The security principle is simple: receiving information (which addresses, how many coins are at each address) is not the same as sending information (signing transactions). The signing machine can afford to be paranoid because it only needs to do one job: approve and sign. The broadcasting machine handles everything else, including monitoring, preparing transactions, and broadcasting them. Separating these roles reduces the consequences of any single machine being compromised.

Physical security and recovery seed backup in offline workflows

An air-gapped Trezor device is secure against remote attacks but vulnerable to physical theft or loss. The recovery seed, if written down and stored, becomes a target. In offline setups, users often maintain multiple copies of the recovery seed in different physical locations, using metal backup plates or laminated paper, with strong protection against water, fire, and unauthorized access. The trade-off is that each copy is a potential vulnerability: a stolen seed allows an attacker to derive all addresses and private keys on any Trezor device.

Some users mitigate this risk by maintaining the recovery seed in parts—splitting it across multiple locations such that no single location contains enough information to restore the wallet. This Shamir Secret Sharing approach can be implemented manually (by dividing the seed words among trusted individuals) or through Trezor’s built-in backup features if supported. The cost is operational complexity: recovery requires assembling the pieces, which takes time and coordination.

Passphrases also serve a backup security function. Even if the recovery seed is stolen, the passphrases are not stored anywhere; they are known only to the operator. An attacker with the seed cannot access funds protected by unknown passphrases. This is why passphrases should never be written down in the same location as the seed—they defeat the purpose if compromised together. A mental passphrase, if memorable, is the strongest option, though it is also the easiest to forget or lose if the operator dies unexpectedly.