Visit Website →
← Back to blog

Mobile App Encryption for Developers: Catch TLS and Key Gaps in CI

October 12, 2026
Mobile App Encryption for Developers: Catch TLS and Key Gaps in CI

Use platform-native, hardware-backed key stores, audited cryptographic primitives such as AES-GCM and ECC, and a disciplined key lifecycle to protect mobile app data. These three controls, applied together, cover the overwhelming majority of real-world mobile data breaches. Everything else, from TLS configuration to end-to-end messaging, builds on this foundation.

TL;DR:

  • Android Keystore and iOS Keychain can bind keys to secure hardware; older devices may need software backed keys or server held key encryption keys.
  • Use envelope encryption with hardware backed keys, and protect sensitive SQLite databases with SQLCipher; never store secrets in plain preferences or shared storage.
  • Require TLS 1.2 at minimum and prefer TLS 1.3; certificate pinning can block interception, but poor rotation planning can lock out users.
  • Use end to end encryption for sensitive peer messaging only when servers do not need to search, moderate, or support users by reading message content.
  • Build key rotation, revocation, attestation, and recovery into releases; biometric changes and device restores can invalidate keys or strand encrypted data.
Pocketapp
Build Security Into Your Mobile App
Pocket App designs and develops mobile applications, bringing UX/UI design, strategic discovery and cross-platform development together.
Explore Pocket App

Table of Contents

Why encryption matters: attacker models and what protection should achieve

Encryption serves two distinct jobs: protecting data at rest on the device and protecting data in transit across networks. Confusing the two leads to gaps, such as a beautifully encrypted database that sends its contents over plain HTTP.

The attacker models worth designing against are concrete. A lost or stolen phone exposes local storage to anyone with physical access and enough patience. A rooted or jailbroken device lets an attacker bypass app sandboxing and inspect memory, files and keychains directly. A hostile network, whether a fake Wi-Fi hotspot or a compromised carrier gateway, lets an attacker intercept or tamper with traffic if transport security is weak.

Encryption at rest defends against the first two scenarios by making stored data unreadable without the correct key, ideally one that never leaves secure hardware. Encryption in transit defends against the third by making intercepted traffic useless to anyone without the session keys. Neither approach protects metadata (who contacted whom, when, how often) or a device that has already been compromised at the operating system level; those risks need separate controls.

Regulatory and platform pressure make this non-optional for most teams:

  • OWASP MASVS requires apps to use current strong cryptography and manage keys according to industry best practice, under its MASVS-CRYPTO controls.
  • Data protection regimes such as GDPR expect appropriate technical measures for personal data, with encryption commonly cited as evidence of that standard.
  • Healthcare and financial apps face sector rules (HIPAA in US markets, similar expectations elsewhere) that treat encryption as baseline due diligence, not an optional enhancement.

Platform-native protections: Android Keystore and iOS Keychain

Both major platforms give developers hardware-backed key storage out of the box, and using it is almost always preferable to anything built independently.

On Android, the Android Keystore generates and stores keys so the private material never leaves secure hardware and is never exportable in plain text. Where a device includes StrongBox or a Trusted Execution Environment (TEE), keys can be bound to that hardware, and the Keystore API lets you require user authentication (PIN, biometric) before a key can be used.

On iOS, the Secure Enclave stores private keys in dedicated hardware and prevents the app, and even the operating system, from reading them directly. Apple's developer documentation notes that Secure Enclave keys are limited to NIST P-256 elliptic curve pairs, so plan your cryptographic design around that constraint rather than discovering it mid-project. The Keychain wraps this with biometric gating through Face ID or Touch ID for an additional access check.

Older or budget devices sometimes lack StrongBox or an equivalent TEE. In that case, fall back to software-backed Keystore entries rather than custom storage, and for the most sensitive operations, consider keeping key material server-side entirely, releasing only short-lived session tokens to the device.

  • Always request key attestation where the sensitivity of the data justifies it, to confirm a key is genuinely hardware-bound rather than software-emulated.
  • Treat biometric gating as a usability and defence-in-depth layer, not a replacement for proper key scoping.
  • Audit which devices in your supported range lack hardware-backed storage before committing to a design that assumes it everywhere.

Pro Tip: Check attestation certificates server-side during key provisioning rather than trusting a client-reported flag, since a compromised device can lie about its own capabilities.

Encrypting data at rest: envelope encryption and secure storage patterns

Envelope encryption is the pattern worth standardising on: a data encryption key (DEK) encrypts the actual content, and a key encryption key (KEK), held in Android Keystore or the Secure Enclave, encrypts the DEK. This keeps bulk encryption fast while anchoring the sensitive key material in hardware.

For structured data, SQLCipher remains the practical choice for encrypting SQLite databases on both platforms, applying transparent encryption at the page level without rewriting your data access layer. Plain SharedPreferences on Android and unencrypted UserDefaults on iOS should never hold secrets, tokens or personal data; both store values in readable files that a rooted device or backup extraction can expose.

Jetpack Security's EncryptedFile and EncryptedSharedPreferences were the recommended interim answer for simple key-value encryption on Android, but the library has since been deprecated. OWASP's guidance is to keep using it until an official replacement ships, rather than reverting to unencrypted storage or a hand-rolled alternative.

  • Wrap every DEK with a hardware-backed KEK rather than storing DEKs in plain configuration files.
  • Use SQLCipher or an equivalent audited library for any database holding personal or financial data.
  • Respect app sandbox boundaries: never write sensitive files to shared or external storage where other apps or the user can reach them.

Filesystem permissions matter as much as the cryptography itself. A correctly encrypted file written to a world-readable directory still fails the threat model it was meant to satisfy.

Encrypting data in transit: TLS, certificate validation and pinning

Require TLS 1.2 as a minimum and prefer TLS 1.3 wherever your backend and client libraries support it. Deprecated ciphers and protocol versions (SSL 3.0, early TLS, RC4, export-grade suites) should be disabled at the server, not merely avoided at the client, since a misconfigured server undermines even a careful app.

Certificate pinning adds a layer against certificate authority compromise or interception by a malicious proxy, but it carries real operational cost: a mishandled certificate rotation can lock out your entire user base until an app update ships. Pin to a backup key or use public key pinning with a rotation plan, and consider whether your threat model justifies the maintenance burden before adopting it by default.

Platform networking stacks (URLSession on iOS, OkHttp or the platform's default HttpsURLConnection on Android) implement TLS correctly out of the box and validate certificate chains automatically; avoid custom socket-level implementations unless you have a specific, well-understood reason.

  • Enforce TLS 1.2 minimum, TLS 1.3 preferred, with deprecated ciphers disabled server-side.
  • Treat certificate pinning as a deliberate trade-off, not a default, given its rotation overhead.
  • Handle flaky mobile networks by retrying failed TLS handshakes gracefully rather than falling back to unencrypted connections.

End-to-end encryption for messaging: when Signal Protocol applies

End-to-end encryption (E2EE) ensures that only the sending and receiving devices can read message content, with the server acting as a relay that never holds usable plaintext or keys. It protects content confidentiality but not metadata: who messaged whom, when and how often remains visible to anyone who controls the server infrastructure, including the client if required to disclose it.

Encrypted messages routed through a metadata-visible server

The Signal Protocol is the industry reference implementation here, combining a double ratchet algorithm with per-message key rotation and long-term identity keys, so that compromising one message's key does not expose the rest of the conversation. It is open source, has been independently audited, and underpins several major messaging platforms beyond Signal's own app.

Adopting E2EE introduces real engineering trade-offs: push notifications must avoid leaking content into notification payloads, multi-device support needs careful key synchronisation across a user's devices, and your servers still carry responsibility for delivery, spam filtering and abuse reporting without reading the content they relay.

  • Reserve full E2EE for genuinely peer-to-peer sensitive communication, such as messaging or health consultations.
  • Use server-side encryption at rest instead when your product needs to search, analyse or moderate content centrally.
  • Plan multi-device key distribution early; retrofitting it into an existing E2EE system is substantially harder than designing for it upfront.

Key management lifecycle: generation, rotation and revocation

A strong algorithm cannot protect data if the keys guarding it are weak, exposed or impossible to rotate. Treat the key lifecycle as the primary design problem, not an implementation detail to settle late.

  1. Generate keys inside hardware (Android Keystore or Secure Enclave) and never export private key material outside that boundary, even temporarily.
  2. Rotate data encryption keys on a defined schedule or trigger, re-wrapping them under a current key encryption key rather than re-encrypting the entire dataset each time.
  3. Request key attestation to confirm hardware backing before trusting a key for sensitive operations, particularly on devices you have not pre-validated.
  4. For legacy devices without reliable hardware-backed storage, consider holding the KEK server-side and releasing it only after authenticating the session.
  5. Design revocation paths for account changes, lost devices and biometric re-enrolment, so a compromised credential cannot be used indefinitely.

Recovery deserves equal attention. When a user changes their biometric enrolment or resets a device PIN, some platforms invalidate associated keys automatically; your app needs a defined recovery flow (re-authentication, backup codes, or server-assisted re-provisioning) rather than silently losing access to encrypted data.

Pro Tip: Build key rotation into your release cycle from day one, since retrofitting rotation onto a system with years of unrotated keys is a far larger project than designing it in from the start.

Common anti-patterns that quietly break your encryption

Most encryption failures in mobile apps come from a short list of repeated mistakes rather than exotic attacks.

  • Rolling your own cryptographic algorithm or protocol instead of using audited primitives like AES-GCM and ECC; custom crypto is one of the most consistently flagged issues in mobile security reviews.
  • Hard-coding encryption keys directly in source code or storing them in SharedPreferences, UserDefaults or public external storage, where extraction requires no special tooling.
  • Using deprecated TLS versions or insecure cipher modes, such as CBC without an accompanying message authentication code, which leaves ciphertext open to tampering.
  • Ignoring runtime threats: a rooted or jailbroken device can dump process memory, so plaintext secrets should exist in memory for the shortest time possible and never linger in logs or crash reports.

Key management, not algorithm choice, is where most real-world mobile encryption implementations fail: a correctly implemented AES-GCM scheme with a poorly protected key offers little more security than no encryption at all.

Testing and verification: building encryption checks into CI

Verification needs to happen continuously, not as a one-off audit before launch.

  1. Run static secrets scanning on every commit to catch hard-coded keys, tokens or credentials before they reach a build artefact.
  2. Include dependency and software composition checks to flag outdated or vulnerable cryptographic libraries.
  3. Execute MASTG storage tests during QA, covering SharedPreferences, local databases and external storage, which OWASP recommends pairing with envelope encryption for higher assurance levels.
  4. Verify key attestation and confirm hardware backing on representative test devices, not just emulators.
  5. Add runtime fuzzing and penetration testing passes before each major release, particularly after changes to storage or networking code.

Wiring these checks into your continuous integration pipeline, rather than treating them as a pre-launch checklist, catches regressions when a dependency update or refactor quietly removes a protection that was working last sprint.

Practical libraries and reference documentation for faster adoption

Three primary sources are worth bookmarking directly: OWASP MASVS and MASTG for verification requirements, the Android Keystore documentation for platform API behaviour, and Apple's Secure Enclave guidance for iOS key handling.

For implementation, SQLCipher remains the most widely adopted library for encrypted SQLite databases across both platforms. Jetpack Security's encrypted storage helpers are deprecated but still usable in the interim per OWASP's own guidance.

  • Read the MASVS-CRYPTO control set before finalising your architecture, not after.
  • Cross-check any third-party crypto wrapper against its maintenance history and audit record before adopting it.
  • Favour sample code from the platform vendors themselves over blog-post snippets of unknown provenance.

How we build encryption into delivery at Pocket App

As an independent mobile app development company working across retail, charity, healthcare and consumer engagement, we treat encryption decisions as part of the discovery phase, not an afterthought bolted on before launch. Across more than 300 projects, we have found that security choices made early, around key storage, data flows and platform APIs, cost far less to get right than those retrofitted later. Our cross-platform deployment process reflects that: we assess what data actually needs protecting, then build the storage and transport architecture around it.

Keeping data encrypted through offline use and synchronisation

Offline-first apps complicate key management because devices need to decrypt and re-encrypt data without a live connection to a server that might otherwise hold part of the key material. The safest pattern keeps the data encryption key wrapped by a hardware-backed key encryption key on the device itself, so decryption works offline without ever exposing the DEK outside secure storage.

Synchronisation introduces a second risk: data queued for upload sits on the device, sometimes for extended periods on poor connections, and needs the same protection as data already synced. Encrypt records before they enter a sync queue, not after, so a crash or forced app termination never leaves plaintext sitting in a pending-upload table.

Conflict resolution during sync should operate on encrypted payloads wherever possible, decrypting only transiently in memory to merge changes, then re-encrypting immediately. When your backend needs to inspect or index data for conflict resolution, that is a signal to use server-side encryption at rest rather than full end-to-end encryption, since true E2EE would make server-side merging impossible by design.

Retry logic matters here too: a failed sync should never fall back to an unencrypted transport channel as a convenience measure, and queued encrypted records should carry integrity checks so a partially transmitted or corrupted payload is detected before it overwrites good data on the server.

Protecting data in backups and across app updates

Platform backup systems (iCloud Backup, Android's auto-backup to Google Drive) can inadvertently capture sensitive files unless you explicitly exclude them. On Android, mark sensitive files and databases with android:allowBackup settings and backup rules that exclude encrypted stores containing keys or tokens; on iOS, set the NSURLIsExcludedFromBackupKey attribute on files that should never leave the device.

Keys themselves should generally never be included in backups at all. A hardware-backed key in Android Keystore or the Secure Enclave is non-exportable by design, so it will not transfer with a cloud backup regardless of settings, which means your app needs a defined re-provisioning flow for a user restoring to a new device rather than assuming continuity.

App updates carry a quieter risk: a schema or encryption scheme change between versions can leave existing encrypted data unreadable if the migration path is not planned. Version your encryption scheme explicitly (store a scheme identifier alongside encrypted data), and write migration logic that decrypts under the old scheme and re-encrypts under the new one during the update process, rather than assuming all installed versions share identical key handling.

Test update paths on devices carrying real encrypted data from the previous release, not just fresh installs, since migration bugs rarely surface in a clean test environment.

What actually matters: an editorial take on mobile encryption advice

Most mobile encryption guidance overindexes on algorithm selection and underindexes on key management, and that emphasis is backwards. AES-GCM versus ChaCha20 rarely decides whether an app gets breached; a hard-coded key or an unrotated credential usually does. If you take one priority from this guide, make it the key lifecycle: generation, hardware backing, rotation and revocation.

The second place conventional advice falls short is treating encryption as a checkbox satisfied once, at launch. Keys age, biometric enrolments change, devices get lost, and schemes need versioning across updates. Teams that bake rotation and attestation checks into their release pipeline from the outset spend far less effort catching up later than teams that treat encryption as a one-time MASVS compliance exercise.

Finally, resist the pull towards full end-to-end encryption as a default for anything labelled "sensitive". E2EE solves a specific problem, content confidentiality between two parties, at the cost of server-side visibility you may genuinely need for moderation, search or support. Match the control to the actual threat, not to whichever pattern sounds most secure on a conference slide.

— Paul

How we can help with your app's security review

If your team would rather have an experienced partner implement or audit this work, our Discover, Design, Develop and Deploy process builds security considerations into the earliest discovery workshops, not as a late-stage patch. We bring that same thinking to every project, drawing on work across retail, healthcare and charity sectors where data protection expectations are high.

  • Discover: we map data flows and threat model before writing a line of code.
  • Design and Develop: we implement platform-native key storage, encryption and secure sync as standard practice.
  • Deploy: we carry those protections through to release and ongoing maintenance.

For a focused check on an existing app, book a session through our Mobile App Clinics and get a practical read on where your current encryption stands.

Pocketapp

FAQ

How can I encrypt my Android phone?

Android devices offer full-disk encryption by default on modern versions, enabled through the device's security settings without any developer action required. For app-level data, developers should rely on the Android Keystore to generate and store keys in hardware rather than building separate device encryption.

What is mobile app security?

Mobile app security covers the practices that protect an app's data, code and communications from unauthorised access, including encryption at rest and in transit, secure key storage, authentication and defences against reverse engineering. OWASP's MASVS defines the verification standard most teams build against.

What other apps are encrypted?

Most reputable messaging, banking and health apps apply encryption in transit via TLS and encryption at rest for stored data, with some messaging apps adding full end-to-end encryption using protocols like the Signal Protocol. The specific approach varies by what the app needs to protect and whether the provider needs server-side access to content.

Should encryption be on or off?

Encryption should be on by default for any data that is personal, financial, health-related or otherwise sensitive, both at rest and in transit. Leaving sensitive data unencrypted exposes it to device loss, interception and unauthorised access with no meaningful offsetting benefit.

How do I choose between Keystore and Keychain approaches?

The choice is largely made for you by platform: Android apps use Android Keystore, iOS apps use the Keychain backed by the Secure Enclave. Cross-platform apps typically implement a thin abstraction layer that calls the correct native API per platform rather than a single shared encryption library.

Sources