Our self-custody guide covers the basic deal: whoever holds the private key controls the funds, and your recovery phrase is the master copy of that key. But there is a question that guide leaves open. Every time you open your wallet app and it is just sitting there, unlocked and ready to sign, where is that key actually living, and why does a stranger who steals your phone not simply have access to it?
The short answer is that almost no wallet stores your raw private key in a form anyone can read. It stores an encrypted version of it, and getting from that encrypted blob back to a usable key takes a password, a piece of hardware, or both.
The keystore file, the original model
The pattern most Ethereum tooling still uses traces back to what is called a keystore file, a format standardized early in Ethereum's history as the Web3 Secret Storage specification. A keystore file is a small JSON document. Inside it, your private key has been run through an encryption cipher, almost always AES, using a key that is itself derived from your password through a deliberately slow function such as scrypt. The file also stores a MAC, a checksum that lets the software confirm you typed the right password before it even tries to decrypt anything.
The "deliberately slow" part is the whole point. Scrypt is designed to be memory hungry as well as CPU hungry, so that guessing passwords one by one against a stolen keystore file is expensive even with specialized hardware. A weak password still fails fast, but a strong one turns brute forcing into a genuinely impractical project.
This design has an important consequence: the security of a keystore file is really the security of two things, your password and the file's backup hygiene. If someone copies the encrypted file and later guesses or steals your password, they have everything they need. If you back the file up somewhere unencrypted, or reuse your wallet password on a site that gets breached, the encryption stops mattering.
Mobile and browser wallets, one layer down
Most people today are not clicking on a raw keystore file, they are using a mobile app or a browser extension. Under the hood, the same idea still applies, just wrapped in more layers.
On mobile, modern wallet apps lean on protections built into the phone itself. iOS keeps sensitive data in a hardware backed Secure Enclave, a separate chip that handles cryptographic operations without ever exposing raw key material to the main operating system. Android has an equivalent called the Android Keystore system, which can also tie key material to hardware. A wallet app can ask the OS to store an encrypted key such that decrypting it requires the device to be unlocked, or requires a biometric check, without the app itself ever handling your password in the clear.
It is worth being precise about what biometrics are doing here. Face ID or a fingerprint is not a second private key. It is a local convenience gate that authorizes the device to release or use the encrypted key that is already sitting there. If someone has your unlocked phone in hand, they effectively have that gate open.
Browser extension wallets follow a similar pattern with different plumbing. The encrypted key sits in the browser's own storage for that extension, protected by the password you set when you installed the wallet. That is why extension wallets ask you to re-enter a password after the browser restarts or the extension locks itself, it is decrypting that stored key fresh each time, not remembering it in plain form between sessions.
Hardware wallets change the question entirely
Our hardware wallet guide and our hot vs cold wallet explainer cover this from a different angle, but it is worth repeating here because it is a genuinely different storage model. A hardware wallet does not just encrypt the key on a general purpose device, it generates and holds the key inside a dedicated secure element chip that is built to never let the private key leave it at all. Signing happens inside the chip. The connected computer or phone only ever sees the finished, signed transaction, never the key itself. That is a stronger guarantee than software encryption on a phone or laptop, because there is no general purpose operating system in the loop that malware could compromise.
A different model entirely: splitting the key
Not every modern wallet stores one whole key, encrypted, in one place. Our MPC and embedded wallets article covers wallets that use multi party computation to split key material across separate parties from the start, so no single device or server ever holds a complete private key to encrypt in the first place. It is a different answer to the same underlying problem: minimizing the number of places a complete, usable key ever sits.
What this actually means for you
None of this changes the advice in our guide on keeping your recovery phrase safe. The phrase is still the master key that can regenerate everything, and it is the one thing that has to be written down offline and kept away from cameras, cloud notes, and screenshots. What this does explain is why your day to day wallet app is reasonably safe to leave installed on your phone: the key it uses is encrypted at rest, gated behind your device lock or a separate wallet password, and in the case of hardware wallets, never even fully present on the device you are typing on.
The practical takeaways are simple. Use a real, unique password for your wallet, not one you have reused elsewhere, since a keystore's encryption is only as strong as that password. Keep your phone and computer's operating system updated, since Secure Enclave and hardware backed keystore protections are maintained through OS updates. And be alert to malware that tries to grab a key at the moment it is briefly decrypted in memory, which is the same family of risk covered in our clipboard hijacking article. Encryption protects the key while it is sitting still. It cannot protect a key that malware catches the instant it gets used.
Sources: Ethereum keystore file format, Medium, Ethereum wallet encryption (AES, scrypt, MAC), Practical Cryptography for Developers