How should mobile app developers protect tokens and sensitive data stored on-device?

Treat on-device storage as hostile and store as little sensitive data as possible. If tokens or PII must remain on the device, place them in platform-provided protected storage, encrypt the data, and encrypt all network communications. Developers should also assume rooted or jailbroken devices can expose local data, so security depends on minimizing exposure, validating necessity, and reducing what an attacker can recover.

Why on-device token storage is a security problem

Mobile apps should treat local storage as recoverable by the user, the operating system, and an attacker with enough device control. That means the real question is not whether data is stored, but whether the app has limited what is stored, reduced the value of what is exposed, and made offline access harder to abuse. Tokens and personal data deserve especially strict handling because they can unlock servers, sessions, or user records.

On-device storage becomes risky when developers assume the handset itself is a trustworthy boundary. In practice, backups, logs, cached files, screenshots, clipboard use, and rooted or jailbroken access can all widen exposure. A protected storage layer helps, but it does not make a stolen device, a compromised runtime, or a debug-friendly build safe by default.

Good mobile design starts with data minimization. If an app can re-fetch a value from the server, derive it from a shorter-lived credential, or avoid persisting it at all, that is usually better than keeping a durable copy on the device. The less sensitive material stored locally, the smaller the offline attack surface and the less damage a local compromise can cause.

Which storage and encryption choices matter most

High-value values such as refresh tokens, API tokens, session material, and PII should be placed in platform-provided protected storage rather than custom files or plaintext preferences. Use the operating system’s secure storage primitives where possible, because they are designed to bind data to the device and to the app context more safely than home-grown storage schemes.

Encryption should be used in two places, but for different reasons. Encrypt stored data to reduce the value of local extraction, and encrypt network traffic to protect credentials and personal data while they move between device and backend. Neither control is a substitute for the other. A secure transport channel does not protect data already sitting on the handset, and local encryption does not protect data while it is in transit.

Token design matters as much as storage design. Short-lived tokens, scoped permissions, and rotation reduce the blast radius if a device is lost, rooted, jailbroken, or instrumented. If a token can survive for a long time and reaches multiple systems, local compromise becomes much more valuable to an attacker.

What developers should assume about compromised devices

Mobile developers should assume that rooted and jailbroken devices can expose local data even when the app appears to be using secure APIs. That assumption changes the engineering goal: the app should not try to make local storage invulnerable, but should make it low-value, time-limited, and hard to reuse elsewhere.

That is why protected storage, encryption, and short-lived credentials need to be combined with server-side controls. If a token is stolen, the backend should be able to limit reuse, invalidate it quickly, and detect abnormal access patterns. If a device is tampered with, the app should fail closed on high-risk actions rather than continuing to trust stored state indefinitely.

Risk and Threat Considerations

When sensitive data lives on-device, the main risks are local extraction, replay, and silent reuse after theft or compromise. Attackers do not need to break the backend if they can recover tokens from storage, memory, backups, or instrumentation and then use them from another environment.

Failure mechanism: Weak local protection, long-lived credentials, or custom storage patterns let an attacker extract material that was supposed to remain private, then replay it against the server as if the app were still trusted.

Impact: The result can be session hijacking, unauthorized account access, data disclosure, and persistent abuse until the token is revoked or expires.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP API Security Top 10 addresses the attack surface, OWASP ASVS and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
OWASP ASVS	V14 — Data Protection	Mobile on-device data protection needs secure storage and encryption controls.
Recommendation — Protect sensitive mobile data with secure storage, encryption, and minimal persistence.
NIST SP 800-53 Rev 5	SC-28 — Protection of Information at Rest	Stored tokens and PII require protection when resident on-device.
	IA-5 — Authenticator Management	Tokens are authenticators whose lifecycle and revocation determine exposure.
Recommendation — Encrypt sensitive on-device data at rest and limit what is stored locally. Set short lifetimes, rotate credentials, and revoke compromised tokens quickly.
ISO/IEC 27001:2022	A.8.24 — Use of cryptography	Local sensitive-data protection depends on cryptographic safeguards.
Recommendation — Apply approved cryptography to protect sensitive mobile data at rest and in transit.
OWASP API Security Top 10	API2 — Broken Authentication	Stolen mobile tokens can be replayed as broken authentication against APIs.
Recommendation — Harden API token handling so stolen mobile tokens cannot authenticate freely.

Practitioner Guidance

What to verify: Confirm that the app stores only the minimum data required for the shortest practical time, and that anything sensitive is kept in platform secure storage rather than plain files, logs, or shared preferences. If a value can be re-derived from the backend, do not persist it locally unless there is a clear offline requirement.

Decision rule: If the item would grant access on a different device, treat it as a credential, not as ordinary app data. Use short lifetimes, narrow scope, and server-side revocation so device compromise does not become durable access.

Common mistake: Teams often encrypt local data but leave tokens, backups, debug artifacts, or verbose logs exposed. That creates a false sense of safety because the easiest extraction path is still open.

Practitioner takeaway: On mobile, the safest token is the one you do not store, and the second-safest is the one that is short-lived, tightly scoped, and recoverable only through platform-provided protections.