What end-to-end encryption protects, and what it doesn't
End-to-end encryption keeps message content protected between devices. Saved copies, backups and the people at either end still need attention.
Suppose you send a colleague a confidential project update in an end-to-end encrypted chat. They read it, then copy a paragraph into a shared document. Anyone with access to that document can now read the paragraph too.
End-to-end encryption is designed to keep message content readable only at the communicating endpoints. For a private conversation, those are the participants' devices. In a correctly designed and implemented system, the service carrying the encrypted messages cannot decrypt their content. The IETF's messaging security architecture describes this separation between the participants and the delivery service.
Encrypted between which devices?
A message can be encrypted while travelling across the internet and still be readable by the service handling it.
Take a simple service that uses TLS to protect the connection between your phone and its server. The server is one end of that protected connection. It can receive readable text, process it, then send it through another encrypted connection to the recipient. TLS protects communication between its endpoints, which may be a device and a server.
End-to-end encryption moves the content protection across that middle step. The sender's device encrypts the message before delivery, and the recipient's device decrypts it. A system may use TLS as well, protecting the network connections that carry the already encrypted message.
| Stage in a simple end-to-end encrypted exchange | What happens to the content |
|---|---|
| Sender's device | The text is composed and encrypted. |
| Delivery service | The service carries encrypted data. It does not have the keys needed to decrypt the content. |
| Recipient's device | The message is decrypted so the recipient can read it. |
This is a simplified example. Group chats and accounts with several linked devices have more endpoints to consider.
Your devices are part of the conversation
You need to read the text before sending it. Your recipient needs to read it after receiving it. At those moments, the words are available on the devices at either end.
Someone who can view an open conversation may be able to read it without breaking any encryption. Malware with sufficient access to a device may also capture text as it is typed or displayed. The consequences of a device compromise depend on the access gained and the system's design, as the IETF's discussion of endpoint compromise explains.
The same conversation may also be accessible on a linked computer or tablet. Review those devices, remove access you no longer need and keep the software up to date. These are practical precautions included in CISA's mobile communications guidance.
A backup has its own protection
The settings used for a live conversation do not, by themselves, tell you how a saved backup is protected.
Check whether the backup is encrypted, who controls the keys and how recovery works. If a provider keeps a key that can open the backup, it may be able to access that copy. If only you hold the secret needed to open it, recovery depends on keeping that secret safe. The fact that a backup is stored in the cloud doesn't answer those questions.
The Electronic Frontier Foundation's encryption guide specifically recommends checking backup encryption alongside the protection used in transit.
The words are only part of the information
Keeping message content secret does not automatically hide the surrounding activity.
Depending on the service and the observer, information such as connection times, account identifiers, network addresses or the amount of data exchanged may remain available. These details are often called metadata. A network observer and a messaging provider will not necessarily see the same information.
Patterns can still reveal something about an exchange even when its content is unreadable. The IETF's privacy guidance calls this traffic analysis.
Check who is at the other end
A familiar profile name or photograph is not enough to verify a sensitive exchange.
Where the application provides contact verification, compare the fingerprint or security code with the other person in person, or through an independent channel you already trust. If someone unexpectedly contacts you from a new account, confirm the change through a known route before sharing confidential information.
This helps connect a cryptographic identity to the person you intend to reach. The EFF's explanation of fingerprint verification shows why that check matters.
Before your next confidential message
Start with the information you actually need to send. Leave out details the recipient doesn't need. Then check the parts of the exchange that matter for that information:
- Whether this conversation uses end-to-end encryption, including any linked devices.
- Whether you have verified the recipient through a trustworthy method.
- Which devices can open the conversation.
- How saved copies and backups are protected.
- Whether the recipient needs to keep, copy or share the text.
For work conversations, agree with your colleague which documents or people may receive that project detail before you send it.
Where Layergram fits
Layergram lets you compose and encrypt selected text locally before sharing it through a compatible channel. The recipient decrypts it locally in Layergram. Both people use Layergram and verify their identities.
That puts the chosen content in a separate encrypted layer before it reaches the transport chat. The chat can still retain information about the exchange, and the devices and recipient remain part of the risk. You can follow the workflow in How Layergram works and read the specific limits in our security explanation.