End-to-end encryption for team chat: what it really means

End-to-end encryption is one of the most misused terms in team-chat marketing. Vendors describe their products as "encrypted" when what they mean is "encrypted in transit," which is the minimum bar of every HTTPS site on the internet. If you are evaluating a chat product on privacy grounds, the question is not whether it is encrypted — the answer is always yes — but who holds the keys. That distinction sounds technical. It is not. It is the difference between a door that only you can open and a door the landlord has a spare key to.

What the guarantee actually is

End-to-end encryption means the keys required to decrypt message content are held only by the participating clients. Not by the server, not by the vendor, not by anyone in between. In a well-designed system, a vendor with full administrative access to their own infrastructure cannot read your messages. They cannot hand them to a subpoena. They cannot expose them in a database dump. They cannot train a model on them.

That is a strong guarantee, and it is the one the term is supposed to carry. A product that holds your keys server-side may still encrypt messages on disk, but the vendor can decrypt them whenever they choose, and so can anyone who compromises the vendor's infrastructure. The encryption is a lock on the door, but the landlord kept the key.

Three flavours of "encrypted" chat

Not all encryption is created equal, and the differences matter far more than most marketing pages would have you believe.

The first and most common model is in-transit only. Messages are encrypted between client and server, and between server and other clients, but stored in cleartext or with a vendor-held key on the server. This is the default across most of the landscape — Slack, Teams, Discord, and Zoom chat all operate this way. It protects against someone intercepting the message on the wire, but not against the vendor itself.

The second is server-side encryption with vendor keys. The database is encrypted at rest using keys the vendor holds in a key-management service. This raises the bar against lost backup disks and rogue storage admins, but the vendor can still decrypt content when needed. It is a better lock on the same door with the same spare key.

The third is true end-to-end encryption. Message content is encrypted with keys only the clients have. The server sees ciphertext and nothing more. Signal does this for direct messages, Matrix and Element do it for encrypted rooms, and TheChatApp does it for channels and direct messages by default.

What it does not guarantee

E2EE is not magic, and it is worth being honest about what it leaves on the table.

Metadata is usually not end-to-end encrypted. The server still needs to know who is messaging whom and when in order to deliver messages. Some designs minimise this surface, but none eliminate it entirely. If someone can see that you messaged a journalist at two in the morning, the content of that message matters less than you think.

Clients can be compromised. E2EE protects against server-side attackers. It does not protect against malware on your laptop, a shoulder surfer, or an admin with physical access to an unlocked session. The encryption is only as strong as the device it runs on.

Key management is where E2EE products actually break. Losing a device should not lose message history. Onboarding a new device should not hand an attacker the old keys. The difference between a good E2EE product and a fragile one lives almost entirely in this area, and it is the area most vendors gloss over because it is genuinely hard to get right.

Zero-knowledge modes

Some products go a step further with what is sometimes called a "zero-knowledge" server: a configuration where persistent server-side artifacts are not enough to reconstruct content keys. That is a specific deployment mode, not a synonym for "encrypted at rest."

TheChatApp's current managed enterprise direction uses server-managed tenant content keys, with Scaleway KMS wrapping when configured. That improves protection for copied tenant directories and stolen backups, but it is not zero-knowledge against a live host or operator with production infrastructure access. Tenant-controlled Mode 2 is the path for stronger separation, and the strong claim only applies once that mode is enabled, confirmed, and committed.

How to verify the claim

When a vendor says their product is end-to-end encrypted, three questions separate marketing from substance. First, is E2EE on by default, or is it a per-room beta feature the admin has to enable? Second, which content types are actually covered — channels and direct messages, or just one-to-one calls? Third, where is the encryption described? A dedicated security page that names the ciphers — ChaCha20-Poly1305, AES-GCM, P-256 ECDH — is a good sign. A marketing page that says "encrypted" without naming the algorithm or the key model is a weaker signal. The specificity tells you whether the engineering team wrote the page or the marketing team did.

What TheChatApp does

TheChatApp uses ChaCha20-Poly1305 for native session traffic, P-256 ECDH for key agreement, and AES-GCM for message and file content at rest. Managed cloud deployments should be described as encrypted and KMS-capable, not blanket zero-knowledge, unless the tenant-controlled Mode 2 requirements are actually enabled and committed.

If you are comparing products on privacy grounds, the comparison pages for Slack, Microsoft Teams, and Mattermost cover how each handles encryption by default.