Bring Your Own Key: Enterprise Encryption Control
How Mandraki's BYOK encryption lets enterprises retain full cryptographic control over their collaboration data, including key management, rotation, and revocation.
Note: This article describes Mandraki’s architecture and design. Some features discussed are being rolled out progressively and may not yet be available in all plans.
For many enterprise security teams, encryption is a necessary condition but not a sufficient one. The critical question is not whether data is encrypted, but who holds the keys. If the platform vendor controls the encryption keys, then the vendor — or anyone who can compel the vendor — can decrypt the data. The encryption exists, but the customer does not truly control it.
Mandraki’s Bring Your Own Key (BYOK) feature addresses this directly. It allows organisations to supply their own encryption keys, ensuring that cryptographic control remains with the customer at all times.
The three-layer key hierarchy
To understand BYOK, it helps to understand Mandraki’s overall encryption architecture. We use an envelope encryption model with three layers.
At the top sits the Master Key, which protects everything below it. In a standard deployment, Mandraki generates and manages this key. In a BYOK deployment, the customer provides it.
The second layer consists of Organisation Keys — one per organisation. Each Org Key is encrypted (wrapped) by the Master Key and stored in the database in its wrapped form. When needed, the Org Key is unwrapped in memory, used, and then discarded. Unwrapped keys are held in an in-memory LRU cache with a five-minute time-to-live for performance, but are never written to disk or stored in Redis.
The third layer consists of Data Encryption Keys (DEKs), one per purpose: messages, files, recordings, and transcripts. Each DEK is wrapped by its organisation’s Org Key. The DEK is what actually encrypts and decrypts the data using AES-256-GCM.
This layered approach means that rotating a key at one level does not require re-encrypting all the data below it. Rotating the Org Key requires re-wrapping the DEKs, but not re-encrypting every message. Rotating a DEK means new data is encrypted with the new key, while old data remains readable with the old DEK (which is marked as rotated but retained).
How BYOK works in practice
When an organisation enables BYOK, they provide their Master Key through a secure import process. Mandraki accepts a 256-bit AES key provided through a secure channel. The organisation is responsible for the key’s lifecycle, backup, and availability. For organisations with their own HSMs or key management infrastructure, the key can be generated externally and imported into Mandraki.
The principle is straightforward: Mandraki never generates or stores the root of the key hierarchy. The customer does. If the customer revokes or withholds their key, Mandraki can no longer decrypt any of that organisation’s data. The ciphertext remains in the database, but it is inert.
Critically, the entire key management process happens within EU-sovereign infrastructure. There are no dependencies on non-European key management services — no external cloud KMS providers, no third-country API calls. Your encryption keys stay under your control, within European borders.
The implications of key revocation
This is where BYOK becomes a genuinely powerful security control, and where organisations need to understand the consequences clearly.
If you revoke your BYOK key, all of your organisation’s encrypted data becomes permanently inaccessible. Messages cannot be read. File attachments cannot be downloaded. Call recordings cannot be played. Transcripts cannot be retrieved. This is by design — it is the entire point of BYOK.
This capability is particularly relevant for regulated industries. A financial services firm subject to DORA can demonstrate to regulators that it retains the ability to render all collaboration data inaccessible if needed. A healthcare organisation can ensure that patient-adjacent communications are cryptographically controlled. A government body can enforce data lifecycle policies through key management rather than trusting a vendor’s deletion processes.
BYOK and AI features
Mandraki’s AI features — transcription, summarisation, smart replies, and recording analysis — require server-side access to plaintext. When a BYOK organisation uses AI features, the processing pipeline decrypts data using the organisation’s key hierarchy, processes it through our AI models (running entirely within EU infrastructure), and encrypts the results back with the organisation’s DEK.
However, BYOK organisations are automatically restricted to transient AI data retention. This means that plaintext exists in memory only during processing and is not persisted to disk. The AI-generated outputs (transcripts, summaries) are encrypted with the organisation’s keys before storage, ensuring they fall under the same BYOK protection as the source data.
If the organisation later revokes its BYOK key, the encrypted AI outputs become inaccessible along with everything else.
Key rotation
BYOK does not mean static keys. Organisations should rotate their keys regularly, and Mandraki supports this through a straightforward process.
When an Org Key is rotated, a new Org Key is generated and wrapped with the current Master Key (or BYOK key). Existing DEKs are re-wrapped with the new Org Key. The old Org Key is marked as rotated and retained in wrapped form for historical data access. New data uses new DEKs wrapped with the new Org Key.
The rotation process is non-disruptive. Users experience no interruption, and historical data remains accessible through the retained key chain.
Who should use BYOK
BYOK adds operational complexity. The customer becomes responsible for key availability — if the key is lost and there is no backup, the data is gone permanently. This is a feature, not a bug, but it requires mature key management practices.
We recommend BYOK for organisations that have dedicated security teams with key management experience, operate in regulated industries where cryptographic control is a compliance requirement, need the ability to cryptographically sever access to their data, or have existing investment in HSMs or key management infrastructure.
For organisations that do not need this level of control, Mandraki’s standard encryption — where we manage the Master Key — provides strong protection with lower operational overhead. Both modes use the same underlying AES-256-GCM encryption and the same three-layer key hierarchy. The only difference is who controls the top of the tree.