Author: Yishi (@ohyishi, OneKey janitor)
Compiled by: Shenchao TechFlow
Shenchao Introduction: Taking an iPhone offline and using it as a cold wallet to store crypto assets sounds reasonable, but the author Yishi (a maintainer at OneKey) draws a hard bottom line: at least an iPhone 17 or newer, iOS 27 or above, and migrate to a newer device every one to two years. Being offline does not eliminate the risk brought by "someone else physically obtaining this phone." The article covers border searches, mnemonic storage, the mobile forensics industry, BFU/AFU key states, the USB attack surface, the difference between chip-off and decryption, wallet key management, and finally explains why the hardware floor should start at iPhone 17, ending with a signing-device configuration of his own. Conclusion first: taking a phone offline is only one of many precautions. What truly determines the level of security is the hardware generation, patch version, BFU/AFU state, device passcode, and the wallet's own key management.
You can do this, but I would require at least an iPhone 17 or newer running iOS 27 or later, and migration to a newer device every one to two years. I would not entrust large crypto assets to an old iPhone running an old iOS.
This is my minimum requirement for this use case, not an Apple certification, and it does not mean that anything above this line is safe. The reason is straightforward: taking a phone offline does not eliminate the risk brought by "someone having physical access to it."
To understand these risks, look at what happens when a phone arrives at a border checkpoint or a forensic lab.
Border searches do not require your phone to be online
In U.S. Customs and Border Protection's (CBP) fiscal year 2025 annual report, 55,318 electronic device searches were recorded: 50,922 basic searches and 4,396 advanced searches. The fiscal year ran from October 1, 2024 to September 30, 2025. These are search statistics, not 55,318 successfully cracked iPhones. CBP Statistics and Policy
A basic search usually involves an officer viewing the contents on the device. An advanced search involves connecting external equipment (wired or wireless) to copy or analyze its contents. A basic search may also include entering relevant information into CBP systems.
One easily missed detail in a January 2026 directive: merely using the device to make content available for inspection (including bypassing a passcode or defeating encryption) does not by itself constitute an "advanced" search under that policy. So the basic-versus-advanced dichotomy cannot cleanly count which phones encountered unlocking tools and which did not. This is the current policy definition, and it cannot tell us how every search in the previous fiscal year was actually conducted. CBP Directive 3340-049B, §3.4
Under CBP policy, an advanced search requires reasonable suspicion of a violation within its enforcement authority, or a national security concern, and supervisory approval. The directive also requires compliance with binding case law. These are agency rules, and they do not mean the legal standard is the same everywhere.
There are also practical details. A phone that cannot be inspected may be seized. CBP says U.S. citizens will not be denied entry because a device cannot be inspected; for foreigners seeking admission, noncompliance is considered along with other circumstances. The directive says searches should generally be conducted in the person's presence, but that does not mean the person gets to watch the inspection process. CBP FAQ Directive, §5.1.6
The point most relevant to cold storage is that CBP policy limits inspection to information stored locally on the device. Officers must disable network connections, or ask travelers to disable them, to avoid obtaining information stored only remotely. A phone is deliberately taken offline before its local contents are inspected. A locally saved photo or note does not become inaccessible just because Wi-Fi is off. Directive, §5.1.2
A lawful law enforcement inspection and theft are two different things. But the lesson about custody is the same: you must consider that another person may inspect the data you carry with you.
A mnemonic in Notes or Photos is still a mnemonic
I would not take a photo of a recovery phrase, store it in Photos, and then call it cold storage because the iPhone is offline. I also would not paste it into an ordinary note.
These files are still protected by iOS encryption and Data Protection, and they are not necessarily sitting in plaintext on NAND. The problem is that once someone obtains those contents, the secret is right there, readable as text or an image. The wallet's own password, transaction approval, and signing controls are no longer standing between "that copy" and "someone reconstructing the wallet." If an additional recovery passphrase was used, that is still required.
Locked Notes deserve a precise distinction. Apple supports locking notes with the device passcode or a separate custom password, and locked notes have additional encryption protection. A strong custom password is a different situation from an ordinary unlocked note. But it is still a general-purpose document store, and the authentication method matters: using the same device passcode does not give you an independent password. Apple also notes that after unlocking one note, other locked notes under that account will also be unlocked within a few minutes. Apple: Locked Notes Apple: Notes Security
Likewise, the Hidden album and the Recently Deleted album use Face ID, Touch ID, or the device passcode. Hiding a photo does not equal adding an independent layer of protection to a recovered secret. Deleted photos are usually kept in Recently Deleted for 30 days. Turning off the network today also does not revoke copies that may already have been synced or backed up. Apple: Delete or hide photos
If your recovery phrase has already been exposed, moving the same phrase to a better device cannot repair that exposure. You need to generate a new wallet in a trusted environment, then, after verifying recovery and first doing a small test transaction, perform an on-chain transfer.
Mobile forensics is a mature industry
Cellebrite, Magnet's Graykey, Oxygen, and China's SDIC Intelligence (the company behind Meiya Pico) are all active in mobile forensics. Their products and capabilities differ. Device access, password recovery, extraction, and analysis are different parts of this work; model, OS version, and device state determine which methods are available. Magnet Training Oxygen SDIC Intelligence
You will see the term FFS, meaning full file system extraction. It is different from partial extraction, and both are different from recovering the lock screen passcode. Obtaining a file system copy does not mean every encrypted file inside it has been decrypted.
Cellebrite's spring 2026 briefing named iPhone 17 and iOS 26.3.1 in its expanded Inseyets support. Page 4 gives a narrower and more useful statement: Cellebrite Advanced Services (CAS) claims AFU access support for iPhone 11 through 16 devices running iOS 26 or later. These are vendor capability claims, not proof that "every supported combination can export every wallet's secrets." Cellebrite Briefing
In the same release announcement, Cellebrite said that 75% of devices received by North American forensic labs are locked. This is an intake statistic, not a 75% unlock success rate. But it does tell you that locked devices are routine work for this industry. Cellebrite Announcement
Graykey also has historical evidence. In November 2024, 404 Media reported, based on internal documents, that newer iPhones running iOS 18 and 18.0.1 could produce partial extractions. Public reporting did not specify exactly what each extraction contained. "Partial" does not mean private keys were recovered, but the lock screen clearly cannot be treated as evidence that "no data can be accessed." 404 Media Original Report
The most critical detail is this: whether the phone has ever been successfully unlocked since boot.
BFU and AFU describe the state of the keysBFU is Before First Unlock. The phone has booted, but nobody has entered the correct passcode yet. AFU is After First Unlock. Locking the screen again does not send it back to BFU.
iOS organizes file protection around per-file keys, protection class keys, and the keybag. The first unlock makes keys for certain protection classes available. Some keys remain available after the screen is locked so that background tasks can continue.
The important example is Class C: NSFileProtectionCompleteUntilFirstUserAuthentication. Apple's documentation states that its class key remains in memory after the screen is locked again. It is also the default file protection class for third-party apps when no other class is specified. Class A behaves more strictly: under the system protection policy, its decrypted class key is discarded after the screen is locked. Apple: Data Protection classes
With a suitable exploit chain and privileges, AFU can therefore expose app data that the same attacker cannot obtain under BFU. This is the useful "hot" state that forensic examiners try to preserve. A wallet may add stronger file protection, Keychain access controls, or its own encryption, so Class C does not prove that every wallet mnemonic is readable. What it explains is why pressing the lock button once is not enough to close the issue.
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 back to the Secure Enclave Processor (SEP). Her later notes also describe an earlier seven-day interval. The SEP tracks the time since the last unlock and triggers a reboot; this is more than an ordinary background timer. These historical timings should not be assumed to apply to every later iOS version. Classen reverse engineering
A normal reboot returns the phone to BFU and clears some useful decrypted state. Forensic vendors are responding. Cellebrite's spring 2026 release page says that Safeguard Mode can maintain access after a reboot. Its public materials do not fully disclose the mechanism, the preconditions, or the exact access retained on each device. This claim should be included in the discussion, but with those limitations attached. Cellebrite: Safeguard Mode
Apple wants to close the extraction window, and forensic vendors want to keep it open. This is why I power off a dedicated signing phone when I store it, and why I would never treat an automatic reboot feature as my entire custody plan.
When the network is off, USB is still an attack surface
USB Restricted Mode (often abbreviated USBRM) limits wired data access on a locked device. It is an important barrier, but 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 used in extremely sophisticated attacks against specific targets. Apple security advisory
Amnesty's investigation into the use of forensic tools in Serbia provides a concrete example of a related technique on Android. It documented reaching kernel drivers by emulating USB peripherals, with a chain involving CVE-2024-53104, CVE-2024-53197, and CVE-2024-50302. The relevant device classes include video, audio, and HID. Amnesty technical report
This is an Android exploit chain, not evidence that "these same bugs also affect iPhone." But the general technique is worth understanding: peripheral emulation → driver attack surface → kernel exploitation → privilege escalation → extraction. These are concrete stages of an attack, not security jargon.
Taking the phone off the network reduces network exposure. It does not remove the physical interfaces, their drivers, or the software that enforces access restrictions.
Chip-off is not decryption
This is exactly where 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, plus escalating delays and attempt limits. As long as this hardware binding holds, brute force must do the 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 cluster can attack in parallel at will. Apple also documents that the UID is not exposed through JTAG or other debugging interfaces. Apple: Secure Enclave
In embedded forensics, chip-off refers to removing the memory chip to read it; ISP (in-system programming) can gain access while the chip remains on the board. These techniques solve the problem of "accessing the stored bytes." They do not automatically recover the keys needed for decryption.
Fault injection and power side-channel analysis are different attack directions. Each class requires the relevant weakness and experimental evidence. "They can take the phone apart" is not an explanation of how its private keys become readable.
The device passcode still matters enormously. Consider a deliberately simplified case: the attacker bypasses attempt limits and escalating delays, but each guess still takes 80 milliseconds, guesses are sequential, and there is no shortcut.
Six random digits: 10⁶ possibilities. Exhausting the entire space takes about 22.2 hours, with an average of 11.1 hours.
Ten random lowercase letters plus digits: 36¹⁰ possibilities. Exhausting the entire space takes about 9.27 million years.
Twelve random mixed-case letters plus digits: 62¹² possibilities. Exhausting the entire space takes about 8.18 trillion years.
These are calculations under stated assumptions, not measured speeds for any forensic product. They show how much the device passcode itself matters when another line of defense fails. A birthday, a phone number, or "dictionary word plus year" does not have the entropy of a uniformly random string.
I would use at least 12 truly random alphanumeric characters, together with an independent offline recovery plan. Security that permanently locks the owner out is also a custody failure.
Once device access is obtained, wallet key management is the next boundary
Recovering the device passcode does not necessarily reveal a wallet's recovery phrase. A wallet can encrypt its own secrets and help protect them with a non-exportable key generated in the Secure Enclave, with access controlled by Keychain rules. In that case, a file system extraction may 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, which is a different curve. "It uses the Secure Enclave" does not prove that an arbitrary BIP39 recovery phrase lives entirely inside the enclave, or that every on-chain signature is produced there. This is a limitation of that interface, not an assertion about every cryptographic capability inside the SEP. Apple developer documentation
A wallet may also use key wrapping: a hardware-protected key helps protect the recovery phrase, or protects the key that encrypts it. After authorization, the app unwraps or decrypts what it needs, derives the blockchain keys, and signs within its own process.
This gives us two separate questions: how is the secret protected at rest, and where does the plaintext appear when in use?
Keychain configuration matters. AfterFirstUnlock and WhenUnlocked have different access conditions. WhenPasscodeSetThisDeviceOnly adds restrictions, including not syncing to iCloud Keychain and not being included in backups. A Face ID icon does not tell you these things. Apple: Keychain data protection
A compromised kernel does not automatically mean a compromised Secure Enclave. But controlling the environment in which the wallet runs can 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 two different things.A different design has a different failure mode. A wallet might derive a key from an app password via PBKDF2 or Argon2, then use it to encrypt the mnemonic on disk. If an attacker extracts the ciphertext, salt, and parameters, can verify guesses, and does not need an additional hardware-bound secret, that password can be attacked on an external machine. This is offline cracking.
The 80-millisecond figure for the device passcode no longer describes this attack. The cost depends on the entropy of the app password, the PBKDF2 iteration count or Argon2 memory and time settings, plus the attacker's implementation and hardware. Shouting a good KDF name does not save a weak password. Argon2 spec PBKDF2 spec
The worst case is simpler: the phone becomes accessible, the app password only stands in front of the interface, with no effective independent protection or fresh transaction authorization. Someone can open the wallet and move funds without extracting any mnemonic at all.
These are the questions I would ask wallet developers: Does the app password actually participate in decryption? Does biometric authentication fall back to the device passcode? Does every signature require fresh authorization? How long does decrypted key material stay in memory? What does a backup carry out?
Why my hardware floor starts at iPhone 17
The defenses above do not make hardware generations interchangeable. iPhone 17 and iPhone Air, with the A19 generation, introduce Memory Integrity Enforcement (MIE). Its components work together against memory corruption exploits:
Typed allocators constrain how different object types share memory.
Enhanced Memory Tagging Extension (EMTE) synchronously checks pointers and memory tags.
Tag confidentiality makes tags harder to discover and thus harder to bypass those checks.
Exploit developers typically 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 memory allocations to make the bug useful. The end result is an exploit primitive; arbitrary kernel read/write (kernel R/W) is especially valuable.
MIE interferes with several of these steps. Apple describes its deployment in the kernel and more than 70 userland processes, and evaluates it using historical real-world exploit chains. It first shipped with iOS 26 on supported new hardware, not with iOS 27. Older phones cannot gain the missing EMTE hardware through a software update. Apple MIE technical note
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 that extra layer of hardware defense, and a wallet that uses the available protections. Apple: Enhanced security for apps
Older devices have another well-known problem: checkm8, a BootROM vulnerability affecting A5 through A11 devices (including the iPhone X generation). A normal iOS update cannot replace vulnerable BootROM code. Exploiting the boot chain does not automatically decrypt all user data or break the Secure Enclave, but it remains a permanent disadvantage for those devices. checkm8 original project
iOS 27 is my current software floor, with the latest stable security patches installed. This is a hosting policy, not an assertion that "every old version is exploitable and every new version is safe." Apple still ships ongoing updates across multiple supported branches. Apple security releases
A phone's history matters, and its effective security lifespan is finite
Apple patches vulnerabilities and adds hardware defenses. Forensic vendors keep developing access methods. A public "support matrix" is a snapshot statement of capability, not a promise about next year. That is why I migrate every one to two years, or sooner if a serious issue appears or the device loses support. This interval is my maintenance policy, not a scientifically determined expiration date.
Before declaring an old phone "cold," there is one more question to ask: Was it ever compromised while it was still your daily phone?
Google's 2026 Coruna research documented five iOS exploit chains and 23 vulnerabilities, including modules targeting wallet apps. Its DarkSword research also described payloads that collect encrypted wallet data. These are attacks against specific vulnerable iOS ranges, fixes are available, but they are by no means evidence that "these chains can remotely compromise a fully patched, offline phone." They illustrate why a device's history matters. Coruna research DarkSword research
If your recovery phrase leaked before you went offline, airplane mode cannot take it back. Neither can powering off or enabling Lockdown Mode.
QR codes also do not eliminate the need to trust the signer. Dark Skippy demonstrated that a maliciously controlled signer can encode secret material into transaction signatures through its choice of nonces. The transaction puts the output on-chain. This attack requires a compromised signer; it is not an assertion that "a normal iPhone wallet does this." It illustrates why an offline signer still has an output channel. Dark Skippy research
When migrating, do not create new exposure by putting the recovery phrase into AirDrop, iCloud, screenshots, chat logs, or a shared clipboard. Moving hardware and protecting recovery secrets are both part of this.
If I use an iPhone, this is how I would configure it
iPhone 17 or newer, iOS 27 or later, and current security patches. Verify the hardware protections of the actual model. Plan to migrate every one to two years, and respond sooner to major security changes.
A random device passcode of at least 12 alphanumeric characters. Do not rely entirely on the system's guess limits.
A wallet with effective independent protection. Review mnemonic encryption, KDF parameters, keychain classes, hardware-backed key wrapping, and transaction authorization. A Face ID popup is not a security architecture.
A separate offline recovery backup. No recovery phrase in ordinary Notes, Photos, or screenshots. Verify that recovery actually works before committing large funds.
Reduce unnecessary interfaces and access. Turn off Control Center access from the lock screen and unnecessary accessory access. Turn off Wi-Fi and Bluetooth in Settings; disconnecting them from Control Center is not the same as fully disabling them. Apple explanation
Keep it powered off when in storage. The next normal boot enters BFU. Also protect the device physically.
Use a dedicated device initialized from a trusted state. No jailbreak, no unrelated apps, no everyday Apple account, and no restoring a full daily phone data set. Lockdown Mode can reduce exposure for high-risk users, but it is not a substitute for updates, and it cannot revoke secrets that have already leaked. Apple: Lockdown Mode
Maintain the entire signing flow. Use a controlled offline signing process, including QR code transfer when supported. Verify addresses, amounts, networks, and permissions. Plan updates carefully and verify isolation afterward. Account for physical access, travel, and recovery, not just internet access.
For long-term custody of large assets, I would rather have a dedicated signing device with a transparent security design, ongoing maintenance, and the ability to verify transactions on the device itself. Its firmware, supply chain, and recovery process still require scrutiny.
Taking a phone offline is a precaution. The hardware, patch level, BFU/AFU state, passcode, and the wallet's key management determine what that precaution actually buys you.