DEK, KEK, EKM, and CMK: encryption key terms, explained

If you read enough vendor security pages, you'll run into DEK, KEK, EKM, and CMK — often deployed to imply a level of protection the architecture doesn't actually provide. They're real, useful concepts, and they describe a real technique (envelope encryption). They also get used to make 'the customer controls the keys' sound like 'the vendor can't read your data,' which is a different and much stronger claim. Here's each term, and where the gap is.

Almost all cloud encryption uses two layers of keys, called envelope encryption. You don't encrypt a terabyte of data directly with one precious key. Instead you generate a fresh key for the data, encrypt the data with it, then encrypt ("wrap") that data key with a second, more-protected key. The two layers are the DEK and the KEK.

Why two layers: you can re-key or revoke access by changing only the outer key, without re-encrypting the data; and you can give each object its own data key so compromising one doesn't expose everything.

The DEK is the symmetric key (typically AES-256) that actually encrypts a specific piece of content — a message, a file, a document. Often there's one DEK per object ("per-object key"). The DEK is stored alongside the ciphertext, but in wrapped (encrypted) form, so it's safe at rest.

The KEK is the key that encrypts (wraps) the DEK. It's the higher-value key you protect more carefully — typically in a hardware security module (HSM) or a key-management service (KMS). The KEK never touches the data directly; it only ever wraps and unwraps DEKs. In an end-to-end design like Koaich's, the equivalent of the KEK is derived on your own device and never leaves it — which is the whole difference. See key custody, explained.

EKM is a vendor feature (Slack's is the best-known example; cloud providers offer equivalents) that lets a customer bring and control their own root key instead of letting the vendor hold every key. With EKM, the vendor wraps your per-object DEKs with a key you control. You typically get two things from it: an audit log of every time a vendor service unwrapped a DEK to read content, and a kill switch — revoke your key and the vendor can't perform new operations on your stored data.

What EKM does not do: stop the vendor's servers from decrypting your content during normal operation. See why Slack EKM is not end-to-end encryption for the full version.

The CMK is the root key you own and control — usually living in a KMS or HSM you administer (e.g., AWS KMS). In the envelope scheme, the CMK plays the KEK role: it wraps the DEKs. "Customer-managed" is the operative word — you control its lifecycle, rotation, and revocation, rather than the vendor. EKM is the system that ties your CMK to the vendor's DEKs and logs the unwraps.

Top to bottom: your CMK (the root key you control, acting as the KEK) wraps each DEK (per-object data key), which encrypts your content. EKM is the framework that connects your CMK to the vendor's DEKs and records every unwrap. A concrete example: when Slack shows a file thumbnail or runs search, a Slack service unwrapped that file's DEK and read the content — EKM logged it and your CMK could have blocked it, but the read happened.

Here's the distinction these terms tend to blur. EKM and a CMK give you administrative control — audit and revocation — over a vendor that still decrypts your content at runtime to power its features. That means a subpoena served on the vendor still returns cleartext, and an insider with the right access can still read content; you'd just see it in the log afterward.

Cryptographic secrecy is different: the key that wraps the DEKs lives only on the user's device, so the vendor holds wrapped DEKs it cannot open — there's nothing to log because there's no access. That's the line between 'the vendor could read it but commits not to' and 'the vendor cannot read it.' It's the same idea as can vendors read your encrypted data and zero-knowledge vs. end-to-end encryption.

When a vendor highlights EKM/CMK/BYOK (bring-your-own-key), the right question isn't "do I control a key?" — it's "can the vendor's servers decrypt my content during normal operation?" If yes (because search, AI, previews, or indexing need cleartext), then EKM gives you accountability, not secrecy. If the answer is no — keys only on your devices — that's end-to-end encryption, and the vendor genuinely can't read your data. Koaich is built for the second answer across messages, documents, and files.