Your mobile app uses encryption. What does that actually protect?

“Is the data encrypted?” is a reasonable question to ask before building an app. But a yes or no answer leaves quite a lot unexplained.

Which data? While it travels to the server, while it sits on the phone, or both? Who holds the keys? Can the service provider read it?

Those questions turn a reassuring word into something you can actually evaluate. Here’s how I would approach that conversation for a mobile product.

Follow one piece of information

Imagine a private notebook app. Someone writes a note, saves it offline, and later syncs it to their account. This is a hypothetical product we can use to examine the decisions.

The note may exist in the app’s memory, in local storage, in transit, and in the backend’s database or backups. A diagnostic log or notification could create another copy.

Before choosing an encryption library, draw that short journey. Mark where the information is stored, who should be allowed to read it, and what kind of access you’re trying to protect against. Protecting a network connection and protecting a downloaded database are different requirements.

HTTPS protects the connection

HTTPS uses TLS to protect data in transit between the app and the server it connects to. Proper certificate validation is part of establishing that connection. Disabling it to get past a development error undermines the protection. OWASP TLS guidance

That doesn’t mean the receiving server cannot read the note. It also doesn’t tell you how the server stores the data afterward.

For the notebook example, the first review question is straightforward: does every path carrying private content use the intended protected connection, including uploads and downloads? The next question concerns the copies at either end.

Local encryption needs a key-management plan

Encrypting a local file introduces another responsibility: managing the key that can decrypt it. Putting a shared secret directly in the app’s source code or packaged assets is not a sound way to keep that secret from someone inspecting the app.

Android Keystore can keep cryptographic key material non-exportable and restrict how keys are used. Hardware-backed protection depends on the device and key configuration. It doesn’t make a compromised app harmless: an attacker may still be able to use a key on the device even when they cannot extract it. Android Keystore documentation

For an Android implementation, use the platform’s cryptographic facilities and documented guidance rather than inventing a cipher. The specific algorithm, mode, and handling of nonces or initialization vectors need to fit the design. Copying an encryption snippet is not a complete storage strategy. Android cryptography guidance

For our notebook, I’d want the proposal to explain how keys are created, when they can be used, and what happens if they become unavailable. Other platforms need their own storage and key-management decisions too.

End-to-end encryption changes the product

If the requirement is that the service provider cannot decrypt note content, ordinary HTTPS alone doesn’t meet it. End-to-end encryption puts content encryption and decryption at the intended endpoints, with a key design that prevents the intermediary service from decrypting it.

That requirement affects more than saving a file. How does a second phone obtain access? How does sharing work? What can a password reset recover? Which information, such as account identifiers or communication metadata, remains visible?

For the example app, we’d need to decide whether losing every authorized device and recovery secret means losing access to the notes. A promise of recovery needs an explicit mechanism and an explanation of who can use it.

I would settle these choices before advertising end-to-end encryption. Established protocols and a review of the complete design matter more than adding the label to a feature list.

Encryption doesn’t decide who is authorized

Suppose the backend sends one person’s note to another signed-in account because it checks the wrong owner. An encrypted network connection would still deliver the note to the wrong person.

Access control remains a separate responsibility. So do session handling and deciding what the app writes to logs, backups, notifications, and exported files.

In a review of our notebook app, I’d check those paths alongside encryption. A carefully protected database is less useful if diagnostic logging records every note in plain text.

Ask for evidence you can understand

A useful delivery discussion should answer these questions:

• Which data is protected in transit and in storage?
• Which components or people can decrypt it?
• Where are keys managed, and what happens when they are lost or replaced?
• What happens after logout, reinstall, backup restoration, or adding another device?
• How are private contents kept out of logs and notifications?

Test the agreed behavior, including failed decryption and unavailable keys. The app should explain a recovery problem without silently overwriting the only remaining copy of someone’s work. Passing those checks supports the implementation review; it isn’t proof that a product has no security weaknesses.

Encryption is valuable when its boundaries are understood. As a client, you don’t need to choose every cryptographic parameter yourself. You do need a clear explanation of what the app protects and how that protection affects the people using it.

If your app also keeps data without a connection, read what should happen when an app goes offline. Storage, synchronization, and recovery need to be planned together.