End-to-end encryption is easiest to understand by asking who can unlock a message. In an encrypted conversation, the intended endpoints hold the keys needed to read it; the service carrying the encrypted content does not receive those keys to read it.
The endpoints are not always just two phones. A linked computer or an encrypted backup can introduce another device or recovery key into the picture. Signal’s documentation provides concrete examples of how a service handles these boundaries.
Transport encryption and end-to-end encryption
A secure connection can protect information while it travels between a device and a server. That alone does not say whether the server can read the content it receives.
End-to-end encryption concerns the content’s keys and intended recipients. Signal describes its service as unable to read messages or listen to calls. The claim is about the protected content, not proof that every fact about communicating disappears.
A reader should distinguish the message from other information an application handles, such as account setup or connection data. Assessing those details requires the service’s own documentation rather than inferring them from a padlock symbol.
Linked devices become endpoints
Signal’s linked-device explanation describes how a new desktop or iPad can receive message history and recent media from the primary device.
The transfer is encrypted. For new messages, Signal explains that each linked device has its own keys and receives an individually encrypted copy. Adding a device therefore extends the set of authorized endpoints rather than requiring the service to read the conversation.
That has a practical consequence: check which devices are linked to your account. The encryption protects delivery to an authorized device; it does not decide whether a particular computer should remain authorized.
A backup needs its own key boundary
Signal’s Secure Backups guidance says the optional archive is end-to-end encrypted with a 64-character recovery key. The key is not shared with the service.
According to that documentation, neither Signal nor anyone else can read or restore the archive without the recovery key. Losing the key therefore has a different consequence from forgetting an ordinary account password: the service cannot decrypt the backup for you.
This example shows why “encrypted backup” needs a fuller question. Who holds the recovery key, and who can request or perform decryption? A service holding the decryption key would create a different trust boundary.
Encryption does not protect an unlocked screen
A message eventually has to become readable on its recipient’s device. Once displayed, its protection depends on that endpoint as well as the protocol.
Someone with access to an unlocked device can see content the device is authorized to decrypt. A recipient can also copy what they read. End-to-end encryption does not undo those actions or make the recipient unable to share the message.
The useful distinction is between protection from the intermediary and protection at the device. Screen locks, linked-device review and careful recovery-key storage address the latter.
Read the claim by following the key
| Situation | Question to ask |
|---|---|
| A secure connection | Can the destination server read the content? |
| An encrypted chat | Which endpoints have decryption keys? |
| A linked device | How is it authorized and removed? |
| An encrypted backup | Who holds the recovery key? |
| A lost device | What access remains on that endpoint? |
These questions work across services without assuming that all products using the same phrase share the same architecture. Follow the provider’s explanation for each part of the communication path.
For a separate threat to encryption systems, see post-quantum cryptography. The end-to-end boundary and the algorithms’ resistance to future attacks are different aspects of security.
