# How to Turn Your iPhone Into a Cold Wallet

Source: https://x.com/ohyishi/status/2110203652015345926?s=46

## Summary

Taking an iPhone offline does not remove the risks of physical access, so the text sets a minimum of an iPhone 17 or newer running iOS 27 or later, replaced every one to two years, for holding substantial crypto. U.S. Customs and Border Protection reported 55,318 electronic-device searches in fiscal 2025, and its policy limits examinations to information stored on the device, with network connectivity disabled. Seed phrases saved in Photos or Notes remain readable once someone gains access to the phone. Apple's Class C file protection keeps some data keys available after the screen locks.

## Article

You can do it, but I would require an iPhone 17 or newer, running iOS 27 or later, and migrate to a newer device every one to two years. I would not trust an old iPhone running an old version of iOS to secure substantial crypto holdings.

That is my minimum for this use case, not an Apple certification or a guarantee that everything above that line is safe. The reason is straightforward: taking a phone offline does not remove the risks that come with someone getting physical access to it.

To understand those risks, look at what happens when a phone reaches a border checkpoint or a forensic lab.

A border search does not need your phone to be online

In its annual account of fiscal year 2025, U.S. Customs and Border Protection reported 55,318 electronic-device searches: 50,922 basic searches and 4,396 advanced searches. That fiscal year ran from October 1, 2024, through September 30, 2025. These are search statistics, not 55,318 successfully cracked iPhones. [CBP statistics and policy]

A basic search generally involves an officer reviewing content on the device. An advanced search involves connecting external equipment, wired or wireless, to copy or analyze its contents. A basic search can still include recording relevant information in CBP systems.

There is a detail in the January 2026 directive that is easy to miss: using equipment merely to make content available for inspection—including bypassing a password or overcoming encryption—does not, by itself, make a search “advanced” under that policy. So the basic-versus-advanced split is not a clean count of phones that did or did not encounter unlocking tools. This is the current policy definition; it does not tell us how every search in the previous fiscal year was performed. [CBP Directive 3340-049B, §3.4]

Under CBP policy, advanced searches require reasonable suspicion of a violation within its enforcement authority or a national-security concern, plus supervisory approval. The directive also requires compliance with binding court precedent. These are agency rules, not a claim that the legal standard is identical in every jurisdiction.

There are practical details, too. A phone that cannot be examined may be detained. CBP says a U.S. citizen will not be denied entry solely because the device cannot be inspected; for foreign nationals applying for admission, noncompliance can be considered alongside other circumstances. The directive says a search should generally take place in the person’s presence, but that does not necessarily mean the person gets to watch the examination itself. [CBP FAQ] [Directive, §5.1.6]

Most relevant to cold storage, CBP’s policy limits the examination to information resident on the device. Officers must disable network connectivity, or ask the traveler to do so, to avoid retrieving material stored only remotely. The phone is deliberately taken offline before its local contents are examined. A locally saved photo or note does not become inaccessible just because Wi-Fi is off. [Directive, §5.1.2]

Figure 3. Original excerpt: CBP Directive 3340-049B, page 5, section 5.1.2. The examination covers resident information; network connectivity is disabled. Source: CBP Directive 3340-049B, January 2026.

A lawful inspection and a theft are different events. The custody lesson is the same: you have to account for another person being able to examine the data you carry.

A seed phrase in Notes or Photos is still a seed phrase

I would not photograph a recovery phrase, save it in Photos, and call that cold storage because the iPhone has no internet connection. I would not paste it into an ordinary note, either.

Those files still benefit from iOS encryption and Data Protection. They are not necessarily sitting unencrypted on the NAND. The problem is what happens once somebody gains access to the content: the secret is right there, readable as words or a picture. The wallet’s own password, transaction approval and signing controls no longer stand between that copy and someone reconstructing the wallet. Any additional recovery passphrase would still be needed, if one was used.

Locked Notes deserve a precise distinction. Apple supports locking notes with the device passcode or with a separate custom password, and locked notes have additional cryptographic protection. A strong custom password is a different situation from an ordinary unlocked note. It is still a general-purpose document store, and the authentication choice matters: using the same device passcode does not give you an independent password. Apple also notes that unlocking one note unlocks the account’s other locked notes for several minutes. [Apple: Lock notes] [Apple: Notes security]

Likewise, the Hidden and Recently Deleted albums use Face ID, Touch ID or the device passcode. Hiding a photograph is not the same as giving the recovery secret an independent protection layer. Deleted photos normally remain in Recently Deleted for 30 days. Turning off the network today also does not revoke copies that may already have synced or been backed up. [Apple: Delete or hide photos]

If your recovery phrase is exposed, moving the same phrase to a better device does not repair the exposure. You need a new wallet generated in a trusted environment, followed by an on-chain transfer after checking recovery and a small test transaction.

Phone forensics is an established industry

Cellebrite, Magnet’s Graykey, Oxygen and China’s SDIC Intelligence, the company behind Meiya Pico, all operate in mobile forensics. Their products and capabilities differ. Device access, password recovery, extraction and analysis are separate parts of the job; the model, OS build and device state help determine which methods are available. [Magnet training] [Oxygen] [SDIC Intelligence]

You will see the term FFS, or full file system extraction. That is different from a partial extraction, and both are different from recovering the screen-lock passcode. Having a file-system copy does not mean every encrypted file in it has been decrypted.

Cellebrite’s Spring 2026 fact sheet names iPhone 17 and iOS 26.3.1 in its expanded Inseyets support. Page 4 makes a narrower, more useful claim: Cellebrite Advanced Services, or CAS, advertises AFU access for iPhone 11–16 devices running iOS 26 or later. These are vendor capability claims, not proof that every supported combination yields every wallet’s secrets. [Cellebrite fact sheet]

In the same release announcement, Cellebrite said 75% of devices arriving at North American forensic labs were locked. That is an intake statistic, not a 75% unlocking success rate. It does tell you that locked devices are routine work for this industry. [Cellebrite announcement]

There is historical evidence for Graykey, too. In November 2024, 404 Media reported from internal documents that newer iPhones on iOS 18 and 18.0.1 could yield partial extractions. The public report does not establish exactly what every extraction contained. “Partial” does not prove private-key recovery, but a lock screen clearly cannot be treated as proof that no data is accessible. [404 Media’s original reporting]

One of the most consequential details is whether the phone has been successfully unlocked since it booted.

BFU and AFU describe the state of the keys

BFU means Before First Unlock. The phone has booted, but nobody has entered the correct passcode yet. AFU means After First Unlock. Locking the screen again does not take it back to BFU.

iOS organizes file protection around per-file keys, protection-class keys and keybags. The first unlock makes certain protected class keys available. Some remain available after the screen locks so that background work can continue.

The important example is Class C: NSFileProtectionCompleteUntilFirstUserAuthentication. Apple documents that its class key remains in memory after relocking. It is also the default file-protection class for third-party apps that do not specify another one. Class A has stricter behavior: its decrypted class key is discarded after locking, according to the system’s protection policy. [Apple: Data Protection classes]

With a suitable exploit chain and privileges, AFU can therefore expose app data that the same attacker could not obtain in BFU. This is the useful, “hot” state forensic operators try to preserve. The wallet may add stronger file protection, Keychain access controls or its own encryption, so Class C does not establish that every wallet seed is readable. It explains why pressing the lock button is not enough to settle the question.

Apple has been narrowing this window. iOS 18 introduced inactivity reboot. Researcher Jiska Classen documented a 72-hour interval in the versions she tested and traced the timer into the Secure Enclave Processor, or SEP. Her subsequent notes also describe an earlier seven-day interval. The SEP tracks the time since the last unlock and prompts a reboot; this is more than an ordinary background timer. Those historical timings should not be assumed to describe every later iOS build. [Classen’s reverse engineering]

A normal reboot returns the phone to BFU and removes some of the useful decrypted state. Forensic vendors are responding. Cellebrite’s Spring 2026 launch page says Safeguard Mode can maintain access even after a reboot. Its public material does not fully disclose the mechanism, prerequisites or exact access retained on each device. That claim belongs in this discussion, with those limits attached. [Cellebrite: Safeguard Mode]

Apple wants to close the extraction window; forensic vendors want to keep it open. That is why I shut down a dedicated signing phone when storing it, and why I would never make an automatic reboot feature my entire custody plan.

USB remains an attack surface when the network is off

USB Restricted Mode, often shortened to USBRM, limits wired data access on a locked device. It is an important barrier, and it has had vulnerabilities.

CVE-2025-24200 allowed a physical attack to disable USB Restricted Mode on a locked device. Apple fixed it in iOS 18.3.1 and said it may have been exploited in an extremely sophisticated attack against specific targeted individuals. [Apple security advisory]

Amnesty’s investigation of forensic-tool use in Serbia gives a concrete example of a related technique on Android. It documented USB peripherals being emulated to reach kernel drivers, with a chain involving CVE-2024-53104, CVE-2024-53197 and CVE-2024-50302. The relevant device classes included video, audio and HID. [Amnesty technical report]

This was an Android exploit chain, not evidence that those same bugs affect iPhones. The general technique is worth understanding: peripheral emulation → driver attack surface → kernel exploitation → privilege escalation → extraction. These are concrete stages of an attack, not just security jargon.

Taking the phone offline reduces network exposure. It does not remove its physical interfaces, their drivers or the software enforcing access restrictions.

Chip-off is not the same as decryption

Here is where the iPhone’s design deserves credit. The device passcode is bound to a hardware UID key. Apple says the relevant derivation is calibrated to about 80 milliseconds per attempt, in addition to escalating delays and attempt limits. As long as that hardware binding holds, a brute-force attack has to perform critical work on the target device. [Apple: Passcodes and passwords]

Desoldering the NAND and dumping it does not, by itself, turn the device passcode into something a GPU farm can freely attack in parallel. Apple also documents that the UID is not exposed through JTAG or other debugging interfaces. [Apple: Secure Enclave]

In embedded forensics, chip-off means removing a storage chip to read it; ISP, or in-system programming, can allow access while the chip remains on the board. Those techniques address access to stored bytes. They do not automatically recover the keys needed to decrypt them.

Fault injection and power side-channel analysis are different attack directions. Each needs a relevant weakness and experimental evidence. “They can take the phone apart” is not an explanation of how its private keys become readable.

The passcode still matters enormously. Consider a deliberately simplified case: the attacker has bypassed attempt limits and escalating delays, but each guess still takes 80 milliseconds, guesses run sequentially, and there is no shortcut.

Six random digits: 10⁶ possibilities. About 22.2 hours to exhaust the space, or 11.1 hours on average.

Ten random lowercase letters and digits: 36¹⁰ possibilities. About 9.27 million years to exhaust the space.

Twelve random mixed-case letters and digits: 62¹² possibilities. About 8.18 trillion years to exhaust the space.

These are calculations under stated assumptions, not measured speeds for a forensic product. They show how much the passcode itself matters if another defense fails. A birthday, phone number or dictionary word followed by a year does not have the entropy of a uniformly random string.

I would use at least 12 genuinely random alphanumeric characters, with a separate offline recovery plan. Security that locks the owner out permanently is a custody failure, too.

After device access, the wallet’s key management is the next boundary

Recovering the device passcode does not necessarily reveal the wallet’s recovery phrase. A wallet can encrypt its secret and use a non-exportable key generated inside the Secure Enclave to help protect it, with Keychain rules controlling access. A file-system extraction may then yield only ciphertext.

There is an important API detail. Apple’s documented Security framework interface for Secure Enclave keys uses P-256 keys generated inside the enclave; it does not import arbitrary existing plaintext private keys. Bitcoin and Ethereum commonly use secp256k1, a different curve. “Uses Secure Enclave” does not establish that an arbitrary BIP39 recovery phrase lives entirely inside it, or that every blockchain signature is produced there. This is a limitation of that interface, not a claim about every cryptographic capability inside the SEP. [Apple developer documentation]

A wallet may instead use key wrapping: a hardware-protected key helps protect the recovery phrase or the key that encrypts it. After authorization, the app unwraps or decrypts what it needs, derives blockchain keys and signs in its own process.

That gives us two separate questions: how is the secret protected at rest, and where does plaintext appear in use?

Keychain configuration matters. AfterFirstUnlock and WhenUnlocked have different access conditions. WhenPasscodeSetThisDeviceOnly adds restrictions including no iCloud Keychain synchronization and no inclusion in backups. A Face ID logo tells you none of this. [Apple: Keychain data protection]

Kernel compromise does not automatically mean Secure Enclave compromise. But control of the environment where the wallet runs may still let an attacker read app memory or abuse available authorization to make it sign. A key being non-exportable and a wallet refusing an unauthorized transaction are separate properties.

Another design has a different failure mode. A wallet may derive a key from an app password using PBKDF2 or Argon2, then use it to encrypt a seed on disk. If an attacker extracts the ciphertext, salt and parameters, can verify guesses, and needs no additional hardware-bound secret, the password can be attacked on external machines. That is offline cracking.

The device passcode’s 80-millisecond figure no longer describes that attack. The cost depends on the app password’s entropy, PBKDF2 iterations or Argon2 memory and time settings, plus the attacker’s implementation and hardware. Naming a good KDF does not rescue a weak password. [Argon2 specification] [PBKDF2 specification]

The worst case is simpler: the phone becomes accessible, the app password only gates the interface, and there is no effective independent protection or fresh transaction authorization. Someone can open the wallet and transfer funds without ever extracting a seed.

These are the questions I would ask a wallet developer: Does the app password actually participate in decryption? Can biometric authentication fall back to the device passcode? Does each signature need fresh authorization? How long does decrypted key material remain in memory? What leaves the device in a backup?

Why my hardware minimum starts at iPhone 17

The defenses above do not make hardware generations interchangeable. iPhone 17 and iPhone Air introduced Memory Integrity Enforcement, or MIE, with the A19 generation. Its components work together against memory-corruption exploitation:

Typed allocators constrain how different object types share memory.

Enhanced Memory Tagging Extension, or EMTE, checks pointer and memory tags synchronously.

Tag confidentiality makes it harder to learn the tags and defeat those checks.

Exploit developers often start with a heap overflow, a use-after-free (UAF), or an out-of-bounds (OOB) read or write. Heap grooming, sometimes called heap feng shui, arranges allocations so the bug becomes useful. The resulting capability is an exploit primitive; arbitrary kernel read/write, or kernel R/W, is a particularly valuable one.

MIE interferes with several of those steps. Apple describes deployment in the kernel and more than 70 user-space processes, and evaluates it against historical real-world exploit chains. It first shipped with iOS 26 on supported new hardware, not with iOS 27. Older phones cannot acquire missing EMTE hardware through a software update. [Apple’s MIE technical explanation]

A third-party wallet’s use of hardware memory tagging still depends on its build configuration. MIE also does not fix a bad authorization decision or a logic bug. I want the extra hardware defense and a wallet that uses the available protections. [Apple: Enhanced Security for apps]

Much older devices have another well-known problem: checkm8, the BootROM exploit affecting A5–A11 devices, including the iPhone X generation. An ordinary iOS update cannot replace vulnerable BootROM code. Exploiting the boot chain does not automatically decrypt all user data or defeat the Secure Enclave, but it is still a permanent disadvantage for those devices. [Original checkm8 project]

iOS 27 is my current software floor, with the latest stable security patches installed. It is a custody policy, not a claim that every older release is exploitable or every newer release is safe. Apple continues to publish updates across multiple supported branches. [Apple security releases]

The phone’s history matters, and its useful security life is finite

Apple patches vulnerabilities and adds hardware defenses. Forensic vendors keep developing access methods. A public support matrix is a dated statement of capability, not a promise about next year. That is why I would migrate every one to two years, sooner if a serious issue appears or the device loses support. The interval is my maintenance policy, not a scientifically established expiration date.

There is also a question to ask before declaring an old phone “cold”: was it compromised while it was still your everyday phone?

Google’s 2026 Coruna research documented five iOS exploit chains and 23 exploits, including modules targeting wallet apps. Its DarkSword research also described payloads collecting crypto-wallet data. These were attacks against specific vulnerable iOS ranges, with fixes available—not evidence that those chains remotely compromise a fully patched, disconnected phone. They demonstrate why the device’s history matters. [Coruna research] [DarkSword research]

If a recovery phrase leaked before you disconnected the phone, airplane mode cannot take it back. Neither can shutting down the device or enabling Lockdown Mode.

QR codes do not remove the need to trust the signer, either. Dark Skippy demonstrated that a maliciously controlled signer can encode secret material into transaction signatures through its nonce choices. The transaction carries the output onto the blockchain. That attack requires a compromised signer; it is not a claim that normal iPhone wallets do this. It shows why an offline signer still has an output channel. [Dark Skippy research]

When migrating, do not create a new exposure by putting the recovery phrase into AirDrop, iCloud, screenshots, chat history or a shared clipboard. Moving the hardware and protecting the recovery secret are both part of the job.

If I used an iPhone, this would be my setup

iPhone 17 or newer, iOS 27 or later, and current security patches. Verify the actual model’s hardware protections. Plan to migrate every one to two years and respond sooner to material security changes.

A random device passcode of at least 12 alphanumeric characters. Do not rely entirely on the system’s guessing limits.

A wallet with effective independent protection. Examine seed encryption, KDF parameters, Keychain classes, hardware-backed key wrapping and transaction authorization. A Face ID prompt is not a security architecture.

A separate offline recovery backup. No recovery phrase in ordinary Notes, Photos or screenshots. Verify that recovery works before committing substantial funds.

Reduce unnecessary interfaces and access. Disable lock-screen Control Center access and unnecessary accessory access. Turn off Wi-Fi and Bluetooth in Settings; disconnecting them in Control Center is not the same as fully disabling them. [Apple’s explanation]

Shut it down when putting it into storage. The next normal boot starts in BFU. Protect the device physically as well.

Use a dedicated device initialized from a trusted state. No jailbreak, unrelated apps, everyday Apple Account or restoration of an everyday phone’s entire data set. Lockdown Mode can reduce exposure for higher-risk users, but it does not replace updates or revoke leaked secrets. [Apple: Lockdown Mode]

Maintain the whole signing workflow. Use a controlled offline signing process, including QR transfer where supported. Check addresses, amounts, networks and permissions. Plan updates deliberately and verify isolation afterward. Account for physical access, travel and recovery—not just internet access.

I would not use an iPhone 16 or older as my long-term signing device for substantial holdings. Even iPhone 17 plus iOS 27 is only the minimum I would currently accept.

For long-term custody of large amounts, I would prefer a dedicated signing device with a transparent security design, continued maintenance and transaction verification on the device itself. Its firmware, supply chain and recovery process still need scrutiny.

Taking a phone offline is one precaution. The hardware, patch level, BFU/AFU state, passcode and wallet’s key management determine what that precaution actually buys you.