Fundamentals

End-to-end encryption: what it protects and where its limits lie

By Daniel Sardá · Published on October 22, 2026

6 min read1,265 words

End-to-end encryption prevents intermediaries from reading a communication’s content, but it does not amount to complete privacy or anonymity.

Ana writes a message to Bruno and presses “send.” Between them lie a network, servers, and perhaps several devices. End-to-end encryption is designed so that the content leaves Ana’s device encrypted and can be decrypted only at the intended endpoints, such as Bruno’s phone. The service can carry the message without holding the key required to read it.

That is an important protection for privacy because it reduces the trust we must place in those who operate the infrastructure. It does not, however, make every communication invisible. Nor does it ensure that phones are secure, that backups receive the same protection, or that no one can know who spoke with whom.

Key idea: End-to-end encryption protects content between the intended participants; it is not a promise of complete privacy.

What “end to end” means

Encryption, in simplified terms, transforms readable information into data that cannot be understood without the appropriate key. In a well-designed end-to-end system, the keys that allow access to the content remain under the control of the participating clients, rather than the server that delivers the messages.

The “ends” are usually the authorized devices or clients of the people communicating. If Bruno uses a phone and a computer, for example, the system may need to encrypt the message for each authorized device. The particular implementation varies, but the essential property remains the same: the intermediary should not receive the content in readable form or possess the keys needed to recover it.

The secure-messaging standard Messaging Layer Security describes precisely an environment in which a delivery service can route protected messages without accessing their content. That does not mean every application uses that protocol or offers the same guarantees. “Encryption” is a broad term; what matters is where information is decrypted and who controls the keys.

The path of an encrypted message

Return to Ana’s message. Her app encrypts the text before sending it. The server receives a set of data that it can temporarily store or route to Bruno, but it should not be able to turn it back into the original message. When the content reaches one of Bruno’s authorized devices, that device uses the corresponding key to decrypt it.

The image of a courier carrying a sealed package helps convey the idea. The courier knows delivery details—such as origin, destination, or time—but cannot open the package. The analogy has a limit: digital systems may expose more operational information.

This design distributes power in a meaningful way. If the provider does not hold the keys, its goodwill is no longer the only barrier against reading the content. For an open society, reducing reliance on public or private intermediaries protects a sphere of personal choice. Even so, the design and the endpoints must be trustworthy.

It is not the same as encryption in transit

A connection protected by TLS—the technology commonly used behind HTTPS—also encrypts information while it travels. TLS 1.3 creates a confidential, integrity-protected channel between two peers. The difference is who those peers are.

In a service without end-to-end encryption, there may be one TLS channel between Ana and the server and another between the server and Bruno. The message is protected from someone trying to intercept it on the network, but the server may receive it in readable form before forwarding it. With E2EE, by contrast, the content stays encrypted as it passes through the server.

The two layers complement each other. An end-to-end messaging service may still use secure transport to protect additional information and make alteration or observation in transit more difficult.

Useful distinction: TLS protects a channel between peers; E2EE aims to protect content from the sending device to authorized receiving devices.

What it protects, and from whom

End-to-end encryption limits intermediaries’ access to the content of messages, calls, or files covered by the system. It can provide protection against:

• people intercepting traffic on an insecure network;
• infrastructure operators that carry or store encrypted content;
• intruders who obtain server data but not the endpoints’ keys.

These guarantees depend on the threat model: whom the information is meant to be protected from and what capabilities that party has. E2EE avoids treating every intermediary as a potential reader, but the participants themselves can access the content. It would therefore be inaccurate to say that “no one can read the messages.”

What remains exposed

The first limit is communications metadata: information about a communication rather than necessarily its content. Depending on the service architecture, it can include identifiers, IP addresses, times, recipients, message size, or frequency of contact. The Electronic Frontier Foundation notes that end-to-end encryption does not necessarily hide this information.

This also explains why confidentiality and anonymity are not synonyms. A conversation may be unreadable to the server while still being connected to identifiable accounts, phone numbers, or network connections.

The second limit lies at the endpoints. Once decrypted, a message appears on a screen. An infected, unlocked, or shared phone can expose it. Digital privacy and security also depend on that everyday protection. The recipient can copy the message, photograph it, export it, or show it to someone else. Encryption protects the channel; it does not control everything that happens after delivery.

Notifications and backups matter as well. A preview on a lock screen can reveal part of the text. A backup stored through another system may have different safeguards. One should not assume that because a conversation uses E2EE, all its copies do too.

Warning: A confidential channel does not repair a compromised device or automatically extend its protection to screenshots, exports, and backups.

Keys, identity, and authentication

Encryption answers one question: who holds the key needed to read? Authentication answers another: does that key really belong to Bruno?

If an attacker manages to pose as the recipient during key exchange, Ana could encrypt for the wrong person. Modern systems include mechanisms to detect such substitution; some allow people to verify security codes or fingerprints through another channel. Signal’s Sesame specification illustrates how sessions, identities, and multiple devices are part of the problem, though its details do not generalize to every service.

For especially sensitive communications, verifying the identity associated with a key provides an additional safeguard. It is a decision tied to context, the consequences of an error, and the person from whom protection is sought.

How to assess a privacy promise

The label “encrypted” alone says little. Before entrusting sensitive information to a service, it is useful to ask:

• Is content decrypted on the server or only on the intended devices?
• Who controls the keys, and can the provider obtain them?
• Which content is covered: messages, calls, files, and groups?
• What metadata does the system retain, and for how long?
• How are new devices added and authenticated?
• Do backups have the same protection or a different one?

The answers can vary between services, features, and settings. It is therefore better to review specific technical documentation than to extend a feature’s guarantee to an entire application.

End-to-end encryption does not remove the need to protect passwords, updates, devices, and backups. Its value is more specific and, for that reason, more solid: it reserves access to content for the intended endpoints and reduces the number of third parties able to read it. Understanding where the keys are, which data falls outside that protection, and what happens after decryption makes it possible to use E2EE without turning it into a false sense of invulnerability.