React Native Keychain and secure storage: what to use, what to skip

By React Native Rescue · Published April 15, 2026 · Updated September 13, 2026

The storage question in React Native sounds like a tooling question. It's a security question dressed as a tooling question.

AsyncStorage is the default option every tutorial reaches for. It's plaintext. It lives on disk. On a jailbroken or rooted device it's a file. On a backed-up device, the backup often includes it. And it's where most teams still put the access token the moment they ship.

Here's the field guide.

The three options, ranked by when you should use them

1. Expo SecureStore — the right default for managed Expo apps

If you're on managed Expo, start here. SecureStore is part of the Expo SDK: install it with npx expo install expo-secure-store. It stores values in the iOS Keychain and in SharedPreferences encrypted with the Android Keystore. You don't touch native code. Expo's docs note two limits: large values can be rejected, and on Android the stored entries should be excluded from Auto Backup because they can't be decrypted after a restore. The API is four functions and they all do the right thing.

import * as SecureStore from 'expo-secure-store';

await SecureStore.setItemAsync('refreshToken', token);
const token = await SecureStore.getItemAsync('refreshToken');
await SecureStore.deleteItemAsync('refreshToken');

Works. Ship it. The only time to reach past SecureStore on managed Expo is when you need something it doesn't expose — biometric-gated access, access groups, item sharing across apps, or fine-grained accessibility flags.

2. react-native-keychain — the right default for bare React Native

On bare React Native, react-native-keychain is the one. It's the most common choice in the apps we audit. Same underlying primitives (iOS Keychain, Android Keystore), richer API surface.

import * as Keychain from 'react-native-keychain';

// Store
await Keychain.setGenericPassword('user', token, {
  accessible: Keychain.ACCESSIBLE.WHEN_UNLOCKED_THIS_DEVICE_ONLY,
  accessControl: Keychain.ACCESS_CONTROL.BIOMETRY_ANY,
});

// Retrieve
const credentials = await Keychain.getGenericPassword();
if (credentials) {
  const { username, password } = credentials;
}

// Delete
await Keychain.resetGenericPassword();

The interesting part is the options object. Get these wrong and you get security theater. Get them right and the data is genuinely protected.

3. Encrypted AsyncStorage libs — only when you can't use the above

Libraries like react-native-encrypted-storage exist because some teams need a drop-in replacement for AsyncStorage with encryption on top. Check what they wrap before you adopt one. react-native-encrypted-storage, for example, wraps iOS Keychain and Android's EncryptedSharedPreferences, which Jetpack deprecated in androidx.security:security-crypto 1.1.0 in favor of using Android Keystore directly, and its last npm release was in November 2022.

Use it only when you've got a concrete reason you can't use Keychain or SecureStore. Migrating away from AsyncStorage gradually is a legit reason. "I heard it was simpler" is not.

The options that actually matter on react-native-keychain

Most Keychain bugs we find in audits are misconfigured options, not missing ones. The library is correct. The config is wrong.

accessible — when the item is readable

Controls when iOS will unlock the item. Most teams want WHEN_UNLOCKED_THIS_DEVICE_ONLY. It means: only when the device is unlocked, and don't back this up to iCloud / restore to another device.

The footgun: accessibility values without THIS_DEVICE_ONLY let the item move to a new device through a backup restore, so the token travels with it. Check the default in the library version you use instead of relying on it, and set the value explicitly for auth material.

accessControl — who can read the item

This is the biometric gate. Options like BIOMETRY_ANY, BIOMETRY_CURRENT_SET, and USER_PRESENCE mean the OS requires Face ID / Touch ID / PIN before releasing the value.

The tradeoff: every getGenericPassword() becomes a biometric prompt. Put access-token refresh behind biometry and your app prompts constantly. Gate the long-lived credential (refresh token, keychain-wrapped password) with biometry; keep short-lived access tokens in memory or in a separate, non-gated entry.

service — namespace your entries

If your app stores more than one secret, use service to namespace them. Otherwise every call reads and writes the same slot and you get weird bugs where logging out of one identity also wipes credentials for another.

What never to store in AsyncStorage

Not a complete list. A starting list.

• Auth tokens (access and refresh tokens)
• OAuth client secrets and privileged API keys (these shouldn't ship in a mobile app at all; keep them on your server)
• User credentials (username + password, biometric seeds)
• Session identifiers that grant server access
• Encryption keys for other stored data
• PII governed by HIPAA / GDPR / CCPA
• Anything you'd be embarrassed to see in a breach disclosure

AsyncStorage is fine for UI state, last-viewed IDs, cached non-sensitive API responses, feature flags, onboarding progress. Anything an attacker with file-system access wouldn't care about.

The network-side complement: SSL pinning

Secure storage protects data at rest. SSL pinning protects it in transit — specifically against interception with a certificate the device trusts but you didn't authorize, such as a mis-issued one. On Android 7 and later, apps already ignore user-installed CAs by default. If you pin, start with platform configuration (Android Network Security Config, iOS NSPinnedDomains) before a library such as react-native-ssl-public-key-pinning.

Pin public keys rather than certificates. Ship the pins in the app bundle. If the server presents a cert whose key doesn't match, the request fails closed.

The honest downside: pinning creates a rotation problem. If your server's certificate chain changes and you didn't ship a new app with an updated pin, every user gets a hard failure. We've seen this take down apps for a full day because nobody in the rotation playbook remembered the mobile app.

Pragmatic stance:

• High-value targets (banking, payments, apps with explicit security requirements): consider it, if your threat model includes interception with a trusted-but-rogue certificate and you can run the rotation process.
• Most other apps: skip it. Apple says pinning is not necessary in most cases and should be avoided, and Android does not recommend it. Invest the effort in token storage and the auth flow instead.

If you pin, pin at least two public keys, including a backup key fully in your control, and document the rotation procedure in the same place as your DNS and TLS cert rotation playbook. The mobile app has to ship before the server cut-over.

Decision table

Migrating off AsyncStorage without breaking users

If you're reading this and you have tokens in AsyncStorage today, the migration is a one-shot, version-gated function on app launch.

const MIGRATION_VERSION = 'v1-2026-05';

async function migrateToSecureStorage() {
  const done = await AsyncStorage.getItem('migration:secureStorage');
  if (done === MIGRATION_VERSION) return;

  const token = await AsyncStorage.getItem('refreshToken');
  if (token) {
    await Keychain.setGenericPassword('user', token, {
      accessible: Keychain.ACCESSIBLE.WHEN_UNLOCKED_THIS_DEVICE_ONLY,
    });
    await AsyncStorage.removeItem('refreshToken');
  }

  await AsyncStorage.setItem('migration:secureStorage', MIGRATION_VERSION);
}

Run it in your app-launch bootstrap, before any authenticated request fires. Version the marker so it doesn't re-run. Drop the AsyncStorage read path in the next release — leaving it behind is how legacy code wins.

Common mistakes, ranked by frequency

1. Tokens in AsyncStorage. The default mistake. Most prevalent.
2. Keychain with wrong accessible flag. Allowing iCloud backup of auth material.
3. Biometric prompt on every token refresh. Destroys UX; users turn off biometry.
4. SSL pinning without a rotation plan. The cert changes, the app breaks, the team gets paged.
5. Storing OAuth client secrets in the app bundle. They're extractable from any compiled binary. Move the flow.
6. "JavaScript-layer encryption" of AsyncStorage with a hardcoded key. The key is in the bundle. This is not encryption.
7. Leftover debug logging of secrets. console.log(token) in production. Check your Sentry / Crashlytics breadcrumbs.

What this looks like in an audit

When we run a React Native security audit, secure storage is the first thing we check. It takes 30 minutes and it's the highest-signal finding we ever deliver. Auth material in the wrong place is one of the most common findings. Usually it's one of: AsyncStorage, a plaintext config file, a hardcoded OAuth client secret, or a debug log that still prints tokens.

Fix this layer and you've closed the most common path to a serious breach. Then worry about pinning, obfuscation, jailbreak detection — the layers above.