If you are storing a token or a credential in an Expo app, you want to know the value is not sitting in plain text where any file browser on a rooted device can read it. On Android, Expo SecureStore does encrypt what you store, using the platform's own key system rather than rolling its own. But "encrypted" comes with conditions worth understanding, and SecureStore is built for small secrets, not bulk data. Here is how it works and where its protection ends.
Short answer
Yes. On Android, Expo SecureStore stores your values in SharedPreferences encrypted with the Android Keystore system, so values are not stored in plain text, and the encryption is hardware-backed when the device provides a secure hardware module. Each app has its own isolated SecureStore, and the entries are removed from the Keystore when the app is uninstalled, which is also why SecureStore excludes itself from Android Auto Backup. It is designed for small, sensitive values like tokens, not large datasets. So SecureStore is the right place for a credential on Android, with the caveat that its strength depends on the device's Keystore and secure hardware.
What you should know
- Values are encrypted, not plain text: SecureStore uses the Android Keystore to encrypt entries.
- Hardware-backed when available: the Keystore uses secure hardware if the device has it.
- Per-app isolation: one app cannot read another app's SecureStore entries.
- Cleared on uninstall: entries are removed from the Keystore, and backups are excluded.
- For small secrets only: it is meant for tokens and credentials, not bulk data.
How does SecureStore store data on Android?
It encrypts each value and keeps the encryption keys in the Android Keystore. When you call SecureStore to save a value, the data is written to the app's SharedPreferences in encrypted form, and the key that encrypts it is generated and held by the Android Keystore rather than stored alongside the data. On devices with a secure hardware module, that key is hardware-backed, meaning it is kept in hardware that the app and even the OS cannot extract directly. Because the keys live in the Keystore tied to your app, the entries become undecryptable once the app is uninstalled, so SecureStore deletes them and configures Auto Backup to skip its data, avoiding a restored backup of values that can no longer be decrypted.
SecureStore vs AsyncStorage
The contrast with AsyncStorage is the reason SecureStore exists. The table shows the difference.
| Aspect | Expo SecureStore | AsyncStorage |
|---|---|---|
| Encryption at rest | Yes, via Android Keystore | No, stored in plain text |
| Intended data | Small secrets like tokens | General app data and preferences |
| Key protection | Keys held in the Keystore | Not applicable |
| On uninstall | Entries removed, backup excluded | Data follows normal app storage rules |
The takeaway is simple: a token, session credential, or API value belongs in SecureStore, while AsyncStorage is for non-sensitive app state. Putting a secret in AsyncStorage leaves it readable in plain text, which is exactly what SecureStore prevents.
What SecureStore does and does not protect
It protects data at rest on the device, within the limits of the Keystore. SecureStore makes sure a stored value is encrypted, isolated to your app, and not trivially readable from the file system, and you can add requireAuthentication so a value is only released after biometric or device-credential authentication. What it does not do is protect a value once your running app has decrypted it and is using it in memory, or guarantee the same strength on every device, since a phone without secure hardware falls back to a software-backed Keystore, and a compromised or rooted device weakens the guarantees. It also is not a place for large data, given its small-value design. So SecureStore is the correct tool for storing a secret, not a blanket promise that the secret can never be reached.
What to watch out for
The first trap is assuming SecureStore means a secret is safe to ship in the app at all; storing a long-lived API key encrypted on the device is still riskier than keeping it on your backend and never putting it on the device. The second is using AsyncStorage for tokens out of habit, which stores them in plain text. The third is treating SecureStore's encryption as uniform, when device hardware varies. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK or AAB against OWASP MASVS and checks how your app stores sensitive data, flagging secrets that sit in insecure storage or are hardcoded in the bundle, so you can confirm tokens actually go through SecureStore rather than plain storage. Moving long-lived secrets off the device entirely is the stronger design.
What to take away
- On Android, Expo SecureStore encrypts values using the Android Keystore, so they are not stored in plain text, and the keys are hardware-backed when the device supports it.
- Entries are isolated per app and removed on uninstall, and SecureStore excludes itself from Auto Backup so undecryptable values are not restored.
- Use it for small secrets like tokens, not bulk data, and prefer it over AsyncStorage, which stores values in plain text.
- Its strength depends on device hardware, so keep long-lived secrets on your backend and use a pre-submission scan such as PTKD.com to confirm sensitive data goes through secure storage.
