Air-gapped signing & offline workflows
Short answer: an air-gapped signing workflow keeps private keys on a device that never touches an internet-connected computer, and only signed transactions leave the device. I believe that for long-term self-custody, understanding these workflows is worth the initial friction. In my testing, air-gapped setups reduce attack surface noticeably—but they add steps.
What is air-gapped signing?
Air-gapped signing means the device that holds your private keys is intentionally isolated from any networked computer or phone while it signs transactions. The host constructs an unsigned transaction (often in a PSBT format for Bitcoin), transfers it to the offline device, the device signs it, and the signed transaction is returned to the host for broadcasting.
Key standards referenced here: BIP-39 for seed phrases (BIP-39) and BIP-174 for Partially Signed Bitcoin Transactions (PSBT) (BIP-174). These are widely used in air-gapped workflows.
Why use an air-gapped workflow?
- Reduced remote attack surface (malware on your PC cannot directly extract private keys).
- Better protection against supply-chain or host compromises.
- Friendly to multisig setups where each cosigner stays offline.
But air-gapped workflows add operational friction. And yes, some users accept that trade-off because they value long-term custody over daily convenience.
Common air-gapped signing methods
QR-code exchange (UR/CBOR encodings): construct a PSBT on a connected computer or mobile app, transfer via QR to the offline device, scan the signed QR back. See the UR specification for QR-PSBT encodings (UR spec).
Removable storage (microSD/USB): PSBT file written to an offline medium, moved to the hardware wallet for signing, then returned to the host.
USB data-only transfer with explicit signature containers (file-based PSBT): similar to removable storage but uses a USB cable in a mode that only transfers files (not a live host connection).
Each method trades convenience for different threat models (malicious host vs. compromised camera/QR app).
Step-by-step: set up an air-gapped device
- Initialize the hardware wallet while offline (create a new seed phrase on the device). Follow the device screens carefully; write the seed phrase on a secure backup medium. See seed phrase and setup-initial.
- Set a strong PIN and enable any anti-tamper checks the device offers.
- If you plan to use a passphrase (the so-called 25th word), read risks and procedures at passphrase-25th-word. A passphrase can increase security but also adds risk of permanent loss if forgotten.
- Choose your signing transfer method (QR, microSD, or USB file). Practice one signing round with small amounts first.
- Keep a copy of the recovery information in a secure, geographically separated backup (consider metal backup plates; see metal-backup-plates).
If you need to update device firmware later, follow verified procedures at firmware-updates and verify-firmware.
Daily offline-signing workflow (example: Bitcoin PSBT)
How do you actually send funds without connecting your device to the internet? Here’s a common pattern using PSBT (BIP-174):
- On an online computer or mobile wallet (hot wallet), build the transaction and export it as a PSBT file.
- Transfer that PSBT to the air-gapped hardware wallet via QR or removable media.
- On the air-gapped device, review details on-screen (outputs, amounts, addresses) and approve.
- The device signs the PSBT and produces a signed PSBT or raw transaction.
- Move the signed transaction back to the online host and broadcast it.
This keeps private keys offline the whole time. Want a walkthrough for a specific device model or app pairing? See air-gapped-signing and third-party-wallets.
Multisig with air-gapped devices
Multisig pairs well with air-gapped cosigners: each cosigner can stay offline and only provide signatures when needed. The setup requires coordinate exchange of extended public keys (xpubs) and often uses PSBT-compatible wallet software. For compatibility notes and setup patterns see multisig and multisig-compatibility.
Why use multisig with air-gapped keys? Because it separates risk: a single compromised host or one compromised cosigner doesn't allow unilateral spending.
Security mechanics: secure element, firmware, and verification
Hardware wallets typically store private keys inside a secure element (see general description: secure element overview). The secure element isolates cryptographic operations from the host.
Firmware and its authenticity matter. Always verify firmware signatures and follow documented update processes (see verify-firmware and firmware-updates). An attacker who can install malicious firmware could weaken an air-gapped workflow.
Comparison: air-gapped vs connected workflows
| Feature |
Air-gapped (QR/microSD) |
Connected (USB/Bluetooth) |
| Private-key exposure risk |
Minimal (keys never touch host) |
Higher (host could exploit drivers/malware) |
| Convenience |
Lower (extra steps) |
Higher (plug-and-play) |
| Firmware update complexity |
May require temporary connection or external verification |
Easier via companion apps |
| Multisig friendliness |
Excellent (each cosigner isolated) |
Good (but dependent on host security) |
Which should you pick? It depends on threat model and operational needs.
Common mistakes & risks
But remember: operational security matters as much as device choice. Small mistakes defeat the strongest hardware.
FAQ
Q: Can I recover my crypto if the device breaks?
A: Yes—if you have a correct seed phrase backup (and passphrase if used). See backup-and-recovery.
Q: What happens if the company stops operating?
A: Your funds are in your keys. As long as you have your seed phrase and compatible recovery tools, you can recover funds even if the vendor ceases operations. See company-failure-recovery.
Q: Is Bluetooth safe for a hardware wallet?
A: Bluetooth increases convenience but introduces additional attack vectors. For maximum security prefer fully air-gapped transfer methods. See connectivity-usb-bluetooth-nfc.
Conclusion & next steps
Air-gapped signing is a pragmatic, high-assurance choice for long-term self-custody and multisig roles. It adds steps, yes, but those steps materially reduce remote attack surface. In my experience, practicing the full workflow once or twice (with tiny amounts) removes most user friction.
Next steps: try a dry-run using a testnet or small transfer; read the setup checklist at setup-initial, review seed handling at seed-phrase, and read the firmware guidance at verify-firmware. If you plan multisig, start with multisig and multisig-compatibility.
Would you like a step-by-step PSBT QR example or a downloadable checklist for air-gapped signing? I can draft one based on the method you prefer.
