What Is Envelope Encryption? Data Keys and KEKs Explained

Envelope encryption is the practice of encrypting your data with one key, called a data encryption key (DEK), and then encrypting that data key with a second key, called a key encryption key (KEK). The encrypted data and the encrypted data key are stored together; the KEK stays locked inside a key management service or hardware security module and never touches your application’s disk. To read the data, you first ask the key service to decrypt, or “unwrap,” the data key.

It’s the default pattern behind cloud storage encryption, database encryption, and most well-designed secrets systems, because it combines fast local encryption with centralized control of the keys that matter.

Why not encrypt everything with one key?

The simplest approach is to keep a single master key and encrypt all data with it. That runs into several problems quickly:

• Exposure. The master key has to be loaded into every application that reads or writes data. Every server, container, and log file becomes a place it could leak.
• Performance. If the master key lives in a key management service (KMS) or hardware security module (HSM) to keep it safe, every encryption call becomes a network round trip. Those services are built to process small payloads, not gigabytes of files.
• Rotation. Changing the master key would mean decrypting and re-encrypting every byte of data you’ve ever stored.
• Blast radius. If the key is compromised, everything is compromised at once.

Envelope encryption solves each of these by splitting the job between two layers of keys.

How envelope encryption works

Encrypting data:

1. The application asks the KMS for a new data key. The KMS returns two things: the data key in plaintext, and the same data key encrypted under a KEK that never leaves the KMS.
2. The application encrypts the data locally with the plaintext data key, typically using a fast authenticated cipher such as AES-GCM.
3. The application discards the plaintext data key from memory.
4. It stores the ciphertext alongside the encrypted data key, the “envelope.”

Decrypting data:

1. The application reads the ciphertext and its encrypted data key.
2. It sends only the encrypted data key to the KMS, which checks permissions and returns the plaintext data key.
3. The application decrypts the data locally, then discards the data key.

The bulk of the work, encrypting and decrypting the actual data, happens locally with symmetric encryption, which is fast. Only a tiny key ever crosses the network to the KMS.

The two kinds of keys

	Data encryption key (DEK)	Key encryption key (KEK)
Encrypts	Your actual data	Other keys
Where it lives	Stored encrypted next to the data	Inside the KMS or HSM
Exposure	Briefly in application memory	Never leaves the key service
How many	Often one per object, file, or tenant	Few, centrally managed
Rotation cost	Requires re-encrypting the data it protects	Cheap, re-wrap the DEKs only

KEKs can themselves be nested: a root key protects intermediate keys, which protect data keys. Large cloud providers use exactly this kind of key hierarchy internally, with a small number of highly protected root keys at the top.

The benefits in practice

• The master key never leaves the vault. Your application only ever handles data keys, and only briefly. An attacker who steals a disk or a database backup gets ciphertext and wrapped keys, both useless without KMS access.
• Access control is centralized. Because every decryption requires a KMS call, permissions on the KEK become the real gate on your data. Revoking a role’s access to the key revokes its ability to decrypt, no matter where copies of the ciphertext ended up. This pairs naturally with the principle of least privilege.
• Every use is auditable. KMS calls are logged, so you get a record of which identity unwrapped which key and when.
• Rotation is cheap. Rotating a KEK means re-encrypting the small data keys under the new KEK. The data itself doesn’t have to be touched.
• Blast radius is small. With a separate data key per object or per tenant, a leaked data key exposes only what it encrypted.
• Crypto-shredding. Deleting a data key, or the KEK that wraps it, renders the corresponding ciphertext permanently unreadable. That’s a practical way to honor deletion requests across backups you can’t easily edit.

Rotation, revisited

Key rotation is where envelope encryption earns its keep, but it’s worth being precise about what rotation achieves.

Rotating the KEK limits how much data any one version of the master key protects and satisfies compliance requirements, without a mass re-encryption job. Many key services keep old KEK versions available for decryption while using the newest version for new data, so rotation is seamless.

Rotating the KEK does not change the data keys. If a data key itself was exposed, you must generate a new data key and re-encrypt the data it protected. Rotation of the outer key doesn’t fix compromise of an inner one.

Common implementation mistakes

• Persisting plaintext data keys. Writing the unwrapped key to disk, a cache, or a log defeats the point. Keep plaintext keys in memory only, for as short a time as possible.
• Reusing one data key forever. A single data key for all data reintroduces the single-key problem one layer down.
• Unauthenticated encryption. Use an authenticated mode so tampering is detected. Unauthenticated modes let attackers modify ciphertext undetected. If you’re fuzzy on the distinction, hashing vs encryption is a good primer on integrity versus confidentiality.
• No encryption context. Many key services let you bind additional authenticated data, such as a tenant ID or object path, to the wrapped key. That prevents one tenant’s wrapped key from being swapped onto another’s ciphertext.
• A KMS call per tiny read. Caching unwrapped data keys in memory for a short time is a common, reasonable trade-off. Bound the cache by time and count of uses.

Where envelope encryption shows up

You’re likely already using it. Server-side encryption in cloud object storage and managed databases follows this pattern, as do client-side encryption libraries from cloud providers. Kubernetes can encrypt its stored Secrets with a KMS provider using envelope encryption, and dedicated secrets management tools rely on similar key hierarchies. It’s the backbone of most encryption at rest in the cloud.

The takeaway

Envelope encryption encrypts data with a data key and encrypts that data key with a master key that never leaves a KMS or HSM. Bulk encryption stays fast and local, the master key stays protected, every decryption is access-controlled and audited, and rotating the master key only means re-wrapping small data keys. Use a fresh data key per object or tenant, authenticated encryption, and never store unwrapped keys.