Almost every service now describes itself as encrypted. The term is accurate in each case and means something materially different in each case, and the distinction determines who is able to read your data — which is usually the question people are actually asking.
Encryption in transit
This protects data while it moves between your device and a server, and is what the padlock in a browser indicates. It is now close to universal and prevents anyone on the network — a shared wireless connection, an internet provider, an intermediary — from reading the contents.
Related: what changes when you switch to passkeys
It says nothing whatsoever about what happens at either end. Data is decrypted on arrival at the server, where the operator can read it. Transit encryption is necessary and entirely insufficient as a privacy claim on its own.
Encryption at rest
This protects stored data. Files on a server, or on your phone’s storage, are encrypted so that physical theft of the hardware does not expose the contents.
The critical question is who holds the key. In most server-side implementations the provider holds it, because the service needs to decrypt data to function — to index it for search, to display it in a web interface, to scan it, or to comply with a legal demand. Encryption at rest defends against stolen drives and misconfigured storage. It does not defend against the provider itself, or against anyone who compromises the provider’s systems while running.
Related: what political polling can and cannot tell you
End-to-end encryption
This is the arrangement most people have in mind. Data is encrypted on the sender’s device with keys that only the participants hold, and can only be decrypted on the recipient’s device. The service transports ciphertext it cannot read.
The defining test is simple and worth applying: if you lose every device and forget every credential, can the provider restore your data? If yes, they hold a key, and it is not end-to-end encrypted in the strict sense. Irrecoverable data is the price and the proof.
The metadata problem
End-to-end encryption protects content. It generally does not protect metadata — who communicated with whom, when, how often, message sizes, and from what network location.
Metadata is frequently more revealing than content, because it is structured, easily analysed at scale, and does not require interpretation. A record showing a pattern of contacts between specific parties at specific times can support strong inferences without a single message being read. Services differ enormously in how much metadata they retain, and this is where meaningful differences between apps with identical content encryption usually lie.
Where the weak points actually are
Strong encryption pushes attackers towards the endpoints, and that is where practical compromise now happens. If a device is compromised, encryption is irrelevant — the attacker sees what the user sees, after decryption.
Backups are the most common accidental leak. A messaging app can be perfectly end-to-end encrypted while its backups are stored in a cloud account in a form the cloud provider can read, which makes the backup setting as consequential as the app choice.
Key verification is the other. End-to-end encryption assumes you have the correct public key for the person you are messaging. If a provider could substitute a key, it could intercept messages. This is why security-conscious applications offer a way to verify contact keys directly, and why notifications about a contact’s security code changing are worth a moment’s attention rather than dismissal.
Reading a privacy claim
A few questions cut through most marketing language. Is it end-to-end encrypted by default, or only in a mode that must be enabled — and if the latter, does it work across all features and devices? Can the provider recover your data, and by what mechanism? What metadata is retained and for how long? Has the implementation been independently audited, and is the result public?
Vague phrasing such as “military-grade encryption” carries no information; the underlying algorithms are standardised and public, and the strength of a system lies entirely in key management and implementation rather than in the choice of cipher.
A realistic conclusion
None of this means transit and at-rest encryption are worthless — they eliminate whole classes of attack and are the correct default for the overwhelming majority of services. The point is narrower: only end-to-end encryption changes who can read your data, and the strength of any encryption claim is determined by key custody, endpoint security and metadata retention rather than by the word itself.
More from PressBBC
- Passkeys vs Passwords: What Actually Changes When You Switch
- How Large Language Models Actually Work — A Plain-English Explanation
- What Political Polling Can and Cannot Tell You
- Browse everything in our Technology section.
Sources and further reading
- National Cyber Security Centre — practical guidance on secure communications
- NIST — Cryptography — the standards most implementations rely on
