<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Air Gapped Signer — tagged coverage - FogChain</title>
	<atom:link href="https://www.fogment.com/tags/air-gapped-signer/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.fogment.com/tags/air-gapped-signer/</link>
	<description>Blockchain news, exchange data and press releases — independently verified.</description>
	<lastBuildDate>Wed, 28 Oct 2026 01:28:01 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.1.2</generator>

<image>
	<url>https://www.fogment.com/wp-content/uploads/2026/10/cropped-39cb25f161f59e8c-raccoon-6-32x32.png</url>
	<title>Air Gapped Signer — tagged coverage - FogChain</title>
	<link>https://www.fogment.com/tags/air-gapped-signer/</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>Cold Storage Setup for a Large Balance</title>
		<link>https://www.fogment.com/cold-storage-large-balance/</link>
					<comments>https://www.fogment.com/cold-storage-large-balance/#respond</comments>
		
		<dc:creator><![CDATA[]]></dc:creator>
		<pubDate>Wed, 28 Oct 2026 01:28:01 +0000</pubDate>
				<category><![CDATA[Wallets]]></category>
		<category><![CDATA[Air Gapped Signer]]></category>
		<category><![CDATA[Cold Storage]]></category>
		<category><![CDATA[Key Management]]></category>
		<category><![CDATA[Large Balance]]></category>
		<category><![CDATA[Recovery Drill]]></category>
		<category><![CDATA[Seed Phrase]]></category>
		<category><![CDATA[Self Custody]]></category>
		<category><![CDATA[Storage Tiers]]></category>
		<category><![CDATA[Wallet Backup]]></category>
		<category><![CDATA[Wallet Security]]></category>
		<guid isPermaLink="false">https://www.fogment.com/?p=209811</guid>

					<description><![CDATA[<p>A cold storage setup is a procedure, not a purchase. The device is one component; the recovery material, the geographic separation and the documented restore path do the actual work, [&#8230;]</p>
<p>The post <a href="https://www.fogment.com/cold-storage-large-balance/">Cold Storage Setup for a Large Balance</a> appeared first on <a href="https://www.fogment.com">FogChain</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p>A cold storage setup is a procedure, not a purchase. The device is one component; the recovery material, the geographic separation and the documented restore path do the actual work, and a setup that has never been restored is a guess about your own future.</p>
<p>The reason to bother is arithmetic. A hot wallet should hold only what you are willing to lose to a single mistake, and that tolerance does not scale with your balance. A cold storage setup is how a large balance stops being reachable from a browser tab, a clipboard and one signature.</p>
<ul>
<li><strong>Cold describes the key&#8217;s location, not the box it shipped in.</strong> A phone in airplane mode is still a hot wallet with a habit.</li>
<li><strong>The restore is the deliverable.</strong> A backup you have never used is a hypothesis; only a full restore on separate hardware tests it.</li>
<li><strong>Cold storage costs time, not money.</strong> Every signing session takes minutes, which is why the balance is usually split.</li>
<li><strong>Most losses at this tier are owner errors.</strong> The device signs what you approve, including the transaction you did not read.</li>
</ul>
<h2>What cold storage actually protects against</h2>
<p>Cold storage means the private key is never present on a machine that is simultaneously connected to a network and doing something else. Signing happens on dedicated hardware, and the transaction travels in and out as data rather than as a live connection to a wallet file.</p>
<p>That definition excludes two things people routinely call cold storage. A wallet app on a phone with the radio off is still a hot wallet that behaves carefully. A seed phrase on paper in a drawer is a backup of a wallet, and the backup inherits the security of whatever the wallet was.</p>
<h3>What it does protect against</h3>
<p>Malware that reads files, keyloggers, clipboard hijacks and malicious browser extensions. None of these can exfiltrate a key that is not on the machine, and none can produce a signature the device itself never approved.</p>
<h3>What it does not protect against</h3>
<p>You, mostly. Cold storage is defeated far more often by its owner approving a transaction the device signed correctly than by any technical break. It also does not protect against a lost backup, a fire, a passphrase nobody else knows about, or a restore you assumed would work because the words were written down carefully.</p>
<p>The device also does not protect the screen you approve on, and the screen is where most of these losses happen.</p>
<h2>The cold storage setup sequence</h2>
<p>Run these steps once, in order, and keep a written record of what you did and where each item went.</p>
<ol>
<li>Buy from a channel where the packaging has not been accessible to a third party, and inspect the seal before powering anything on. A device that arrives pre-initialised is a device to return.</li>
<li>Generate the recovery material on the device itself, never on a computer or a phone. Write it by hand, in order, and read it back twice before confirming.</li>
<li>Restore the material once immediately, on the same device or a spare, and compare the resulting addresses against the ones shown the first time. This catches transcription errors while the words are still fresh.</li>
<li>Add a passphrase only if you understand that it creates a second wallet with no checksum. Store it separately from the recovery words, and record that it exists without recording what it is.</li>
<li>Move a small test amount, confirm it arrives at the expected address, then move the balance. Do this over a settled day rather than at the end of one.</li>
<li>Make a second copy of the recovery material in a different building, in a medium that survives water and fire, labelled so it means nothing to whoever finds it.</li>
<li>Record the derivation path, the address format and the first address of each account in a document stored apart from the recovery material.</li>
<li>Rehearse the full restore from the second copy, offline, at least once a year. Delete the test wallet afterwards and confirm the original still opens the expected addresses.</li>
</ol>
<h2>Sizing a cold storage setup against your balance</h2>
<p>Cold storage is not free; it charges in minutes rather than in fees. That cost is paid every time you sign, so the question is how much of the balance sits behind the slow path and how much stays liquid.</p>
<p>A workable split makes the frequent transactions cheap and the infrequent loss survivable. If a signing session takes twenty minutes and you transact twice a week, you spend about seventy minutes a month on friction. If the amount you would lose from a hot wallet compromise is a month of income, that friction is worth it; if it is a week of spending money, it usually is not.</p>
<div class="fog-table not-prose my-6 overflow-x-auto rounded-2xl border border-ink-200/70 bg-surface" data-fog-table><table>
<thead>
<tr>
<th>Tier</th>
<th>Reachable from the internet</th>
<th>Time to move funds</th>
<th>What usually defeats it</th>
</tr>
</thead>
<tbody>
<tr>
<td>Venue balance</td>
<td>Yes, by the venue</td>
<td>Minutes to days</td>
<td>Account takeover, withdrawal holds</td>
</tr>
<tr>
<td>Phone hot wallet</td>
<td>Yes, by the app</td>
<td>Seconds</td>
<td>Malicious approval, clipboard swap, lost phone</td>
</tr>
<tr>
<td>Desktop wallet with keys on disk</td>
<td>Yes, by anything running on the machine</td>
<td>Minutes</td>
<td>Infostealers, unencrypted backups, sync folders</td>
</tr>
<tr>
<td>Hardware signer with keys offline</td>
<td>Only while signing</td>
<td>Minutes</td>
<td>Approving what you did not read</td>
</tr>
<tr>
<td>Offline signer with a second-location backup</td>
<td>No</td>
<td>Hours to days</td>
<td>Fire, flood, theft, an untested restore</td>
</tr>
</tbody>
</table></div>
<p>The tier you choose should match how long you could tolerate being unable to move. Someone who rebalances weekly needs a fast signing path; someone holding for years can accept a day of latency and should take it.</p>
<blockquote><p>A cold storage setup that has never been restored is not a backup. It is a claim about a backup, made by the person with the most to lose if the claim is wrong.</p></blockquote>
<h2>Failure modes the setup must survive</h2>
<p>Most large-balance losses at this tier come from a predictable short list. Each is cheap to prevent and expensive to discover late.</p>
<h3>The backup that exists but cannot be read</h3>
<p>Handwriting fades, ink runs, a word is misspelled in a way that still looks plausible. The failure is silent for years and total on the day you need it. The defence is a restore rehearsal on separate hardware, done once now and once a year afterwards, with the resulting address compared against your record.</p>
<h3>Single-location storage</h3>
<p>Three copies in one flat are one copy with extra steps. Independent failure modes mean different buildings and different threats. A backup only you can find also dies with you, which is a failure mode rather than a feature.</p>
<h3>The approval you did not read</h3>
<p>The device will sign a transaction that grants spending authority to someone else if you approve it. Hardware solves key exfiltration and does nothing about consent. Read the destination address on the device screen, not on the computer screen.</p>
<h3>The undocumented passphrase</h3>
<p>A passphrase that exists only in memory converts a working backup into an empty wallet for everyone else. Record that a passphrase exists, store it separately from the words, and make sure the restore procedure tells the next person what to do with both.</p>
<p>The post <a href="https://www.fogment.com/cold-storage-large-balance/">Cold Storage Setup for a Large Balance</a> appeared first on <a href="https://www.fogment.com">FogChain</a>.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://www.fogment.com/cold-storage-large-balance/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>Hardware Wallet Without a Computer</title>
		<link>https://www.fogment.com/hardware-wallet-mobile-only/</link>
					<comments>https://www.fogment.com/hardware-wallet-mobile-only/#respond</comments>
		
		<dc:creator><![CDATA[]]></dc:creator>
		<pubDate>Tue, 27 Oct 2026 21:22:08 +0000</pubDate>
				<category><![CDATA[Wallets]]></category>
		<category><![CDATA[Address Verification]]></category>
		<category><![CDATA[Air Gapped Signer]]></category>
		<category><![CDATA[Bluetooth Wallet]]></category>
		<category><![CDATA[Firmware Update]]></category>
		<category><![CDATA[Hardware Wallet Phone]]></category>
		<category><![CDATA[Mobile Signing]]></category>
		<category><![CDATA[Mobile Wallet]]></category>
		<category><![CDATA[QR Signing]]></category>
		<category><![CDATA[Self Custody]]></category>
		<category><![CDATA[Wallet Security]]></category>
		<guid isPermaLink="false">https://www.fogment.com/hardware-wallet-mobile-only/</guid>

					<description><![CDATA[<p>A hardware wallet phone setup now covers the whole signing loop for most people, and it removes a computer from the chain rather than a guarantee. The key stays on [&#8230;]</p>
<p>The post <a href="https://www.fogment.com/hardware-wallet-mobile-only/">Hardware Wallet Without a Computer</a> appeared first on <a href="https://www.fogment.com">FogChain</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p>A hardware wallet phone setup now covers the whole signing loop for most people, and it removes a computer from the chain rather than a guarantee. The key stays on the device; the phone becomes the screen, the connection and the camera.</p>
<p>What changes is the transport. A hardware wallet phone pairing typically runs over Bluetooth, USB-C or animated QR codes, and each transport exposes something different. Understanding that difference is most of what the decision actually involves.</p>
<ul>
<li><strong>The phone is a terminal, not a vault.</strong> If the key ever reaches the phone, the hardware device is no longer doing anything.</li>
<li><strong>Transport decides exposure.</strong> Bluetooth has range, cables have physical access, and QR codes have a camera and a screen in between.</li>
<li><strong>Verification must happen on the device screen.</strong> A phone screen can be lying to you in ways the signer&#8217;s screen cannot.</li>
<li><strong>Firmware updates are the weak link.</strong> They are the one routine task that often still wants a computer, and the one most worth doing deliberately.</li>
</ul>
<h2>What a phone replaces, and what it does not</h2>
<p>The phone replaces the computer as a transaction builder and broadcaster. It holds the watch-only view of your addresses, assembles the unsigned transaction, passes it to the signer, receives the signature and submits it. None of that requires the key, and none of it weakens the setup.</p>
<p>It does not replace the signer&#8217;s screen. The device exists so the address and amount you approve are displayed by hardware the phone cannot rewrite. A phone showing one address while the signer shows another is the exact scenario the hardware is for, and it only works if you look at the small screen.</p>
<h3>The part people get wrong</h3>
<p>Almost every phone-only failure comes from importing the recovery material into the phone wallet &#8220;just in case&#8221;. At that moment the phone becomes a hot wallet with an expensive accessory attached. The companion app should hold public keys and nothing else, which is why it can be reinstalled on a new phone without risk to the balance.</p>
<h3>What genuinely needs a desktop</h3>
<p>Multisignature coordinators, some firmware recovery utilities and a few older chain-specific tools are still desktop-first. Check whether the workflows you actually use exist on mobile rather than assuming the app is a full replacement.</p>
<h2>Connection options for a hardware wallet phone</h2>
<p>Three transports dominate, and they trade convenience against a different kind of exposure each time.</p>
<h3>Bluetooth</h3>
<p>The device pairs with the phone and signs over a short-range radio link. It is the most convenient option and the only one that works with the signer in a pocket. The exposure is proximity: a paired device can be reached from a few metres, so pairing details matter and an unfamiliar device in the list should be treated as a warning.</p>
<h3>USB-C and OTG</h3>
<p>A cable connects the signer to the phone directly. There is no radio, no pairing and no range, and the connection ends when the cable is removed. The trade is physical: you need the cable, the port survives a finite number of insertions, and a public charging cable is not something to sign over.</p>
<h3>Animated QR codes</h3>
<p>The phone displays a sequence of QR frames, the signer&#8217;s camera reads them, and the signed result comes back the same way. Nothing is transmitted, so the signer can stay permanently offline. The cost is speed, since a large transaction becomes dozens of frames, and a camera-to-screen loop that fails in bright light.</p>
<div class="fog-table not-prose my-6 overflow-x-auto rounded-2xl border border-ink-200/70 bg-surface" data-fog-table><table>
<thead>
<tr>
<th>Transport</th>
<th>What it needs</th>
<th>What it exposes</th>
<th>Signer can stay offline</th>
</tr>
</thead>
<tbody>
<tr>
<td>Bluetooth</td>
<td>Pairing, charged battery in both devices</td>
<td>A short-range radio link and a paired-device list</td>
<td>No</td>
</tr>
<tr>
<td>USB-C or OTG</td>
<td>A cable and a working port</td>
<td>Physical access and cable trust</td>
<td>No</td>
</tr>
<tr>
<td>Animated QR</td>
<td>Camera, screen, patience</td>
<td>Shoulder surfing and camera permissions</td>
<td>Yes</td>
</tr>
<tr>
<td>MicroSD exchange</td>
<td>Card, reader, file transfer discipline</td>
<td>Stale files and card handling errors</td>
<td>Yes</td>
</tr>
<tr>
<td>NFC tap</td>
<td>Device held against the phone</td>
<td>Very short range, but no confirmation of what was tapped</td>
<td>No</td>
</tr>
</tbody>
</table></div>
<blockquote><p>The phone is allowed to be compromised. The design assumption is that it is, which is why the address on the signer&#8217;s screen is the only one that counts.</p></blockquote>
<h2>Setting up a hardware wallet phone in order</h2>
<p>The order matters more than the steps. Most of the avoidable mistakes happen when a step is moved earlier for convenience.</p>
<ol>
<li>Install the companion app from the vendor&#8217;s own published address rather than from a search result, and check the publisher name before opening it.</li>
<li>Initialise the signer on the device itself, generating the recovery material there, and never accept a pre-generated phrase from any source.</li>
<li>Write the recovery material by hand and confirm it on the device. Do not photograph it, and do not let the phone&#8217;s keyboard see it.</li>
<li>Complete the pairing from inside the app, and confirm the code shown on the phone matches the code shown on the signer before accepting.</li>
<li>Turn off cloud backup for the app, and check that the operating system is not syncing the app&#8217;s data to an account you do not control.</li>
<li>Verify the receive address on the signer&#8217;s screen, character by character, against the one the app displays. Do this once fully, then spot-check the ends on later use.</li>
<li>Send a small test amount, confirm it arrives at that verified address, then move the balance in one deliberate transfer.</li>
<li>Record the app version, the firmware version and the first address of each account somewhere that is not the phone.</li>
</ol>
<h2>Where a phone-only setup breaks</h2>
<p>Four failure modes account for most of the losses, and three of them are about the phone rather than the signer.</p>
<h3>A counterfeit companion app</h3>
<p>The app store listing looks right, the icon matches, and the first screen asks for your recovery words to &#8220;restore your wallet&#8221;. No legitimate companion app needs them. Install from the vendor&#8217;s published link, check the publisher, and treat any in-app request for the phrase as the end of that app&#8217;s usefulness.</p>
<h3>The address you did not compare</h3>
<p>Phone screens are small, and the middle of an address is easy to skip. Clipboard malware on a phone is less common than on a desktop but it exists, and a swap is invisible unless you read the signer&#8217;s display. Compare the full string on the first transfer, then compare the first and last six characters every time after that.</p>
<h3>A firmware update over the wrong link</h3>
<p>Firmware updates are the one task where the phone&#8217;s network connection reaches the signer&#8217;s trust boundary. Update through the official app, with the device connected directly. If the flow requires a computer, use one you control rather than skipping the update indefinitely.</p>
<h3>Bluetooth pairing drift</h3>
<p>A signer that pairs automatically with a remembered phone is convenient and slightly worse. Unpair devices you no longer use, and treat an unexpected pairing prompt as evidence that something nearby is trying to talk to the device.</p>
<p>The post <a href="https://www.fogment.com/hardware-wallet-mobile-only/">Hardware Wallet Without a Computer</a> appeared first on <a href="https://www.fogment.com">FogChain</a>.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://www.fogment.com/hardware-wallet-mobile-only/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
	</channel>
</rss>
