Which encryption algorithms and modes should mobile apps use?

Which encryption choices are safest for mobile apps?

Use modern, standardized cryptography rather than designing your own. For most mobile use cases, authenticated encryption should be the default because it gives confidentiality and tamper detection together. That matters on mobile, where data may be stored locally, synced, cached, or intercepted between the app and its backend. Prefer platform APIs and rely on well-reviewed library primitives instead of custom wrappers.

AEAD modes are the practical baseline because they fail closed when ciphertext has been altered. That is especially important for mobile data that is decrypted later, reused across sessions, or passed into business logic. A well-chosen algorithm is only part of the answer, the mode and nonce handling determine whether the encryption is actually safe.

Prefer the mobile platform's cryptography stack where possible, because it reduces the chance of implementation errors and makes hardware-backed key protection easier to use. For app data, encryption should usually be paired with authentication of the ciphertext, not just secrecy of the bytes. When the app consumes decrypted data, it should be able to trust that the data was not modified after encryption.

What should mobile teams avoid?

Do not rely on weak, legacy or homegrown cryptography. Outdated ciphers, unauthenticated encryption modes and ad hoc padding schemes often fail in ways that are hard to detect during development but easy to exploit later. Mobile apps are especially vulnerable when developers assume that “encrypted” automatically means “protected against tampering.”

Custom cryptography is a common failure pattern because it tends to copy only the appearance of security, not the details that make the scheme safe in practice. The same caution applies to rolling your own key derivation, reusing nonces, or treating encryption as a substitute for access control. If the platform or a mature library already provides the primitive you need, use that instead of inventing a variant.

The safest rule is simple: if the algorithm or mode is not a current, reviewed standard with authenticated encryption support, it should not be the default choice for a mobile app. If a legacy format must be supported, isolate it, document the exception and plan a migration path rather than normalising it in new code.

How should keys and decrypted data be handled on-device?

Key handling matters as much as the algorithm. Use hardware-backed storage where the device and platform support it, because it raises the cost of key extraction and limits what a rooted, jailbroken or malware-infected device can recover. That said, hardware-backed storage does not remove the need for careful app design, because decrypted data can still be exposed after legitimate use.

When mobile data is decrypted, minimise how long it stays in memory and where it can be copied. Sensitive values should not be cached longer than necessary, logged, or passed through loosely controlled helper components. For a practical overview of key storage, cipher selection and mobile crypto pitfalls, see the Mobile App Security Guide.

If the app protects API keys, refresh tokens, certificates or other secrets, the encryption design should assume those values may be targeted directly. A second useful reference point is the Encryption Guide, which covers key custody, envelope encryption and the difference between confidentiality and integrity protection.

Risk and Threat Considerations

Mobile encryption failures usually become serious when the app trusts decrypted content without verifying that it is authentic. An attacker who can tamper with local storage, intercept data in transit, or manipulate a backup can sometimes turn weak encryption into a logic flaw, not just a confidentiality issue.

Failure mechanism: unauthenticated encryption, nonce misuse, or custom crypto allows modified ciphertext to decrypt into attacker-influenced plaintext, or causes predictable data recovery across repeated uses.

Impact: the app may accept forged records, expose sensitive data, or make security decisions on altered input, which can cascade into account abuse, transaction fraud or privilege misuse.

Practitioner Guidance

What to verify: confirm that every mobile encryption flow uses a current, approved library primitive with authentication built in, and verify that the app rejects modified ciphertext before any business logic consumes it.

Common mistake: teams often protect storage but forget integrity, then assume that “encrypted at rest” means the data is safe to trust after decryption. On mobile, that assumption breaks quickly if a local attacker or malicious app can alter the payload.

Practitioner takeaway: choose the simplest standard primitive that gives both secrecy and tamper resistance, then make key storage and ciphertext verification first-class requirements, not optional hardening.

Related resources from NHI Mgmt Group

• Why do mobile apps need PKCE even when they already use an identity provider?
• How should security teams govern mobile apps that use LLMs?
• How should security teams handle unofficial mobile apps that use real APIs?
• Why do APIs that use standing identifiers and weak authorization fail so often in mobile apps?