Envelope encryption means two layers of keys. A data encryption key (DEK) encrypts your data. A key encryption key (KEK) encrypts the DEK. You store the encrypted DEK next to the data and keep the KEK somewhere else, so stealing the data alone gets an attacker nothing readable.
The two layers
OWASP's cryptographic storage guidance describes the same hierarchy: the DEK encrypts the data, the KEK encrypts the DEK, and the KEK must be stored separately from the DEK and be at least as strong as it.
Managed key services follow this pattern. AWS KMS documentation, for example, calls the top key a KMS key and describes data keys as keys generated on hardware security modules and protected by a KMS key. A service can ask for a data key in two forms: plaintext, for use right now, and encrypted, for storing with the data.
What a typical write and read look like
On write, your application asks the key service for a data key. It encrypts the record with the plaintext key, throws the plaintext key away, and stores the encrypted key beside the ciphertext.
On read, the application sends the encrypted data key back to the key service. The service checks permissions, decrypts the key, and returns it. The application decrypts the record and discards the key again.
The big data never travels to the key service. Only the small key does. AWS notes that data under 4 KB can be encrypted directly under a KMS key, which is why larger payloads use data keys.
Why bother
- One place to enforce access. Every decryption needs a call to the key service, so permissions and audit logs sit at one choke point.
- Cheap re-keying. If you change the KEK, you re-wrap the stored DEKs. You do not have to rewrite terabytes of data.
- Limited blast radius. A DEK can be unique per object or per tenant, so one leaked data key exposes only what it encrypted.
OWASP adds a caution: this layering offers limited value when both keys live on the same system, such as shared hosting. The separation is the point.
Context binding
AWS KMS supports an encryption context, a set of key-value pairs bound into the authenticated encryption. If you supply one on encrypt, you must supply the same one on decrypt. It also shows up in audit logs, which helps you see why a key was used. Binding a record to its tenant or table name this way stops an encrypted blob being replayed into the wrong place.
Common mistakes
- Logging or caching plaintext data keys longer than needed.
- Storing the KEK in the same database as the encrypted DEKs.
- Assuming rotation of the KEK re-encrypts data. It does not. See does rotating a KMS key re-encrypt your data.
Quick check
Is envelope encryption the same as double encryption?
No. Double encryption applies two ciphers to the data. Envelope encryption encrypts the data once and protects the key used for that.
Where should the encrypted data key be stored?
Next to the data it protects. It is safe there because only the separately stored KEK can unwrap it.
Safeguard's compliance and evidence automation can help you collect proof that key access and encryption settings are in place, once you have decided on the design.
Sources
Last reviewed: 19 October 2026.
