Security & Privacy
Encrypting data at rest in mobile apps
A practical guide for teams deciding how to protect locally stored data on phones. It focuses on what to encrypt, where keys live and how to confirm the protection works after release.
01
Step one: inventory what the app stores
List every place the app writes data: databases, preference files, caches, logs, downloaded documents and image thumbnails. Mark each item as public, personal or sensitive. A notes app, for example, might find that note bodies and attachments are sensitive, the account email is personal, and theme settings are public. Teams often forget caches and crash logs, which can quietly hold readable copies. Encrypting everything equally wastes effort and slows the app, so the inventory decides scope. Keep the list in the repository, assign an owner, and update it whenever a feature adds a new storage location or third-party library.
02
Step two: choose where keys are kept
Encryption is only as strong as the place its key sits. Use the platform keystore or secure enclave facilities so keys are generated and held by the operating system, never hardcoded or bundled in the binary. Decide whether the key is tied to device unlock, biometric confirmation or a user passphrase. In the notes example, a key bound to device unlock protects bodies during normal use, while a passphrase option protects a locked folder. Document what happens when the user changes biometrics or restores to a new phone, because lost keys mean unreadable data and need a deliberate recovery decision.
03
Step three: verify and plan for rotation
After implementing, inspect the stored files on a test device and confirm sensitive content is not readable as plain text. Check backups, since cloud or local backups may copy data in unexpected forms. Then define how keys rotate: on logout, on a schedule, or after a suspected compromise, with a migration that re-encrypts existing records safely. In the notes app, a version flag on each record lets old and new keys coexist during the transition. Add a test that fails if sensitive fields are written unencrypted, so later changes cannot silently remove the protection. Record decisions for reviewers.