Documentation / Platform glossary / Key Encryption Key
A key encryption key encrypts other keys rather than data. Wrapping a data encryption key allows it to be stored next to the ciphertext it protects without being readable, which is the mechanism that makes key rotation affordable at scale.
A KEK performs exactly two operations: wrap, which encrypts a data key, and unwrap, which recovers it. It never touches the payload. A stored object therefore consists of ciphertext plus a wrapped key blob, and the blob is useless without unwrap authority.
This solves a problem with no other good answer. A data key must be available to decrypt its object, so it has to be stored somewhere — but storing it in plaintext defeats the encryption, and storing it in a separate system that must be consulted on every read adds a dependency to the read path. Wrapping resolves the tension: the key travels with the data and remains protected.
Rotation is where the layer earns its keep. Retiring a KEK requires unwrapping each data key and re-wrapping it under the new KEK — an operation proportional to the number of keys, not to data volume. The payload ciphertext is never touched, so rotation cost stays flat as storage grows.
The KEK also concentrates access control. Unwrap authority is the effective boundary on decryption, so restricting and auditing that authority is what actually protects the corpus. It follows that a KEK's blast radius is every data key it wraps, which is why KEK scope — per tenant, per environment, or global — is a deliberate design decision rather than an implementation detail.
Without a wrapping layer the only options are storing data keys in plaintext or re-encrypting all content on every rotation. The first is indefensible and the second is expensive enough that it stops happening.
The KEK is therefore the layer that turns key lifecycle from an aspiration into an operation, and the scope of each KEK determines how much a single compromise reaches.
QueryTek wraps document data keys under a separate key tier so keys can be rotated without re-reading stored content, and treats unwrap authority as a restricted, audited capability. Key scoping and rotation procedures are not published.
