End-to-End Encryption for Enterprise

Encryption That Means What It Says

The term “end-to-end encryption” has been diluted by years of marketing misuse. Many platforms claim encryption while retaining the ability to access message content on their servers, or while encrypting only certain types of data, or while managing keys in ways that leave a backdoor for the provider.

Mandraki implements end-to-end encryption as defined by its cryptographic meaning: data is encrypted on the sender’s device and can only be decrypted on the intended recipients’ devices. The server transports ciphertext. It cannot read, analyse, or disclose the plaintext content of messages, calls, or files — not to Mandraki staff, not to infrastructure operators, and not to any government.

How It Works

Mandraki’s end-to-end encryption is built on two open, peer-reviewed protocols.

MLS for Messaging (RFC 9420)

The Messaging Layer Security protocol provides group key agreement for channels and direct messages. When a new group is created or a member is added or removed, the group’s cryptographic state advances to a new epoch. Each epoch has a unique set of encryption keys that are derived collaboratively by group members, without the server ever learning the key material.

Key properties of MLS in Mandraki:

• Forward secrecy. Compromising a device today does not allow decryption of past messages. Each epoch’s keys are independent.
• Post-compromise security. If a device is compromised and later recovered, the protocol self-heals as the group state advances.
• Scalable group sizes. MLS is designed for groups of thousands. Key operations scale logarithmically, not linearly.
• Multi-device support. Each user device has its own MLS credential. Key packages are uploaded in batches and consumed on use, ensuring that adding a new contact does not require them to be online.

SFrame for Media (RFC 9605)

For video and audio calls, Mandraki uses the Secure Frame protocol to encrypt media at the frame level. Each video or audio frame is encrypted on the sender’s device before being transmitted to the Selective Forwarding Unit (SFU). The SFU routes encrypted frames to the correct recipients without ever decrypting them.

This approach is compatible with modern SFU architectures because the SFU does not need to decode media to perform its routing function. It forwards opaque, encrypted payloads, preserving the scalability benefits of server-mediated routing while maintaining true end-to-end confidentiality.

Server-Side Encryption: A Complementary Layer

In addition to end-to-end encryption, Mandraki provides server-side envelope encryption for data at rest. This protects against infrastructure-level threats such as storage breaches or unauthorised physical access.

The encryption hierarchy operates in three layers:

1. Master Key — the root of trust, optionally managed by the customer via BYOK.
2. Organisation Key — one per organisation, wrapped by the master key.
3. Data Encryption Keys (DEKs) — per-purpose keys for messages, files, and recordings, wrapped by the organisation key.

Server-side encryption and end-to-end encryption are complementary. Server-side encryption protects data from infrastructure threats. End-to-end encryption protects data from application-level access, including by Mandraki itself.

Bring Your Own Key (BYOK)

For organisations that require full control over their encryption keys, Mandraki supports BYOK. Customers can import a master key from their own key management service — whether AWS KMS, Azure Key Vault, or a manual import — and all organisation-level encryption will be rooted in that customer-controlled key.

Revoking a BYOK key renders all server-side encrypted data for that organisation permanently inaccessible, providing a cryptographic “kill switch” for data sovereignty.

Trade-Offs and Transparency

End-to-end encryption introduces certain trade-offs that we believe customers should understand clearly.

• Server-side search is not possible on end-to-end encrypted content. Mandraki provides a client-side search index using the browser’s local storage.
• AI features (transcription, summarisation) cannot operate on end-to-end encrypted calls or channels. Organisations must choose between AI assistance and E2EE on a per-call or per-channel basis.
• New devices see messages only from the point they join a group. Historical messages are not retroactively decrypted for new devices.

These are inherent properties of genuine end-to-end encryption, not limitations of our implementation. Any platform that claims to offer E2EE without these constraints is likely not providing true end-to-end encryption.