Category: Key Management

Data Encryption Key

Also known as: DEK, data-encryption key

Simply put

A Data Encryption Key (DEK) is a cryptographic key used to directly encrypt and decrypt data, such as files, database records, or messages. To keep the DEK itself safe, it is often encrypted (or 'wrapped') by another key called a key encryption key (KEK), an approach known as envelope encryption. This layered arrangement is intended to help protect sensitive data while allowing the key that protects it to be managed separately.

Formal definition

A Data Encryption Key (DEK) is a symmetric or asymmetric key used to encrypt and decrypt data other than keys, as distinguished from a key encryption key (KEK), which is used to encrypt keys. In common key-management architectures, the DEK operates directly on protected data (for example, files, database entries, or messages) and is itself wrapped by a KEK under a scheme referred to as envelope encryption, enabling separation between the key that protects data and the key that protects the DEK. Implementations may scope a DEK at various levels—for example, a tenant-level DEK used to protect sensitive data in a specific service. Note that the effect of any DEK-based encryption on PCI DSS scope depends on the specific implementation, key-management controls, and validation, not on the use of encryption alone; confirm applicable key-management requirements against the current published PCI DSS.

Why it matters

Separating the key that protects data from the key that protects that key is a foundational key-management practice. When a Data Encryption Key (DEK) operates directly on sensitive data—files, database records, or messages—wrapping it under a key encryption key (KEK) through envelope encryption allows the two keys to be stored, rotated, and access-controlled independently. This separation is intended to limit exposure: compromise of encrypted data at rest does not by itself yield usable plaintext unless the corresponding DEK and, in turn, its wrapping KEK are also obtained.

For teams handling payment data, the distinction matters because encryption alone does not determine how a control affects PCI DSS scope. Whether DEK-based encryption reduces scope, and how it must be managed, depends on the specific implementation, the surrounding key-management controls, and how the design is validated—not on the presence of encryption as a label. Sensitive authentication data such as full track data, card verification values, and PIN blocks must not be stored after authorization even when encrypted, so applying a DEK to such data does not create an exception to that prohibition.

Because requirement numbering and wording for key-management controls differ between PCI DSS versions, teams should confirm the applicable key-management obligations against the current published standard rather than assuming a fixed requirement. Treating the DEK and KEK as separately governed assets supports clearer key-lifecycle management, but the security benefit is realized only when generation, storage, access, rotation, and retirement are all implemented and validated correctly.

Who it's relevant to

Security engineers and architects

Those designing encryption for data at rest use DEKs to encrypt files, database records, or messages, and pair them with KEKs under envelope encryption so the data-protecting key and the key-protecting key can be stored and rotated independently. Design decisions such as DEK scoping—for example, a tenant-level DEK for a specific service—shape how key material is isolated and managed.

Compliance officers

Because the effect of DEK-based encryption on PCI DSS scope depends on implementation, key-management controls, and validation rather than on the use of encryption alone, compliance teams should assess how DEKs and KEKs are generated, stored, accessed, and retired, and confirm applicable key-management requirements against the current published PCI DSS, whose numbering and wording differ between versions.

Platform and cloud operations teams

Teams operating key-management services implement the wrapping and unwrapping of DEKs by KEKs and enforce separation between the two. They are responsible for the operational lifecycle—access control, rotation, and retirement—that determines whether the intended protection is actually achieved.

Inside DEK

Data-Encrypting Function

A DEK is the cryptographic key used to directly encrypt and decrypt stored data, such as cardholder data at rest. It operates on the data itself rather than on other keys.

Key Hierarchy Position

In a typical key management hierarchy, the DEK sits at the data layer and is itself often protected (encrypted) by a separate key-encrypting key (KEK), so that the DEK is never stored in the clear alongside the data it protects.

Symmetric Key Material

DEKs are commonly symmetric keys, meaning the same key value is used for both encryption and decryption, which makes secure storage and controlled access to the key value critical.

Applicable Data Elements

A DEK may be used to protect cardholder data such as the PAN when stored. Sensitive authentication data (for example, full track data, CAV2/CVC2/CVV2/CID, and PINs/PIN blocks) must not be stored after authorization even if a DEK is available to encrypt it.

Lifecycle Attributes

A DEK has an associated lifecycle including generation, secure distribution or storage, usage, rotation, retirement, and destruction, all of which are subject to key management controls.

Common questions

Answers to the questions practitioners most commonly ask about DEK.

Does encrypting a Primary Account Number with a Data Encryption Key remove it from PCI DSS scope?

No. Encryption transforms cardholder data but does not by itself remove it from scope. Whether encrypted PAN affects scope depends on the implementation and validation, not on the fact that a DEK was applied. In particular, systems that have access to the DEK, the key-encrypting key, or the decryption process generally remain in scope. Encryption is distinct from tokenization, truncation, masking, and hashing, and each affects scope differently based on how it is deployed and validated against the current published standard. You should confirm scope treatment with your assessor rather than assume encryption alone descopes an environment.

Can a DEK be used to store sensitive authentication data such as full track data or CVV2 after authorization?

No. Sensitive authentication data — including full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks — must not be stored after authorization, even when encrypted. Applying a DEK does not create an exception. Encryption governs how certain cardholder data may be protected when it is permitted to be stored under defined controls; it does not authorize retention of sensitive authentication data. The prohibition on storing sensitive authentication data post-authorization applies regardless of the encryption method used.

How should a DEK be protected relative to the data it encrypts?

A DEK is intended to be protected at least as strongly as the data it protects. A common approach is to encrypt the DEK using a separate key-encrypting key (KEK), so the DEK is not stored in the clear alongside the ciphertext. The KEK and the DEK should be managed so that no single location or role provides both the encrypted data and the means to decrypt it without appropriate controls. Confirm the specific key-management requirements and their wording against the current published version of the standard, as requirement numbering and details differ between versions.

Where should DEKs be stored so they remain distinct from the encrypted data?

The general principle is separation: a DEK should not be stored in the same location or accessible in the same way as the ciphertext it protects. Storing the DEK in an encrypted form under a KEK, or within a dedicated key-management system or hardware security module, are common patterns for keeping the key separated from the protected data. The goal is to ensure that access to the encrypted data does not automatically grant access to a usable key. Validate the chosen approach against your assessor and the current standard.

What is involved in rotating a DEK?

Key rotation typically involves generating a new DEK and re-encrypting affected data, or transitioning new data to the new key while retiring the old one under a defined process. Rotation is intended to limit the amount of data protected by any single key and to reduce exposure if a key is compromised. The specifics — including cryptoperiods, procedures for retiring or replacing keys, and handling of keys suspected of compromise — should be governed by documented key-management procedures. Confirm the applicable expectations against the current published standard rather than assuming fixed intervals.

How does a DEK differ from a key-encrypting key (KEK) in a layered key hierarchy?

In a layered key hierarchy, the DEK directly encrypts data, while the KEK encrypts the DEK rather than the data itself. This separation is intended to allow the DEK to be stored in encrypted form and to make certain operations, such as rotating the key that protects the DEK, more manageable without re-encrypting all underlying data. The two key types serve different roles and should be managed and protected according to their function; conflating them can weaken the intended separation of duties and access controls.

Common misconceptions

Encrypting data with a DEK means sensitive authentication data can be stored safely after authorization.

Encryption with a DEK does not permit storage of sensitive authentication data after authorization. Full track data, card verification values (CAV2/CVC2/CVV2/CID), and PINs/PIN blocks must not be retained post-authorization even when encrypted. Only certain cardholder data may be stored under defined controls.

A DEK and encryption in general remove data from PCI DSS scope automatically.

Encryption transforms data but does not inherently remove it from scope the way a validated tokenization approach might. Whether and how scope is affected depends on the implementation, key management, and validation against the current published PCI DSS, not on the label 'encrypted' alone. Encryption also differs from truncation, masking, and hashing, which reduce or transform data differently.

Storing the DEK alongside the encrypted data is acceptable as long as the data is encrypted.

If the DEK is accessible in the same location and under the same controls as the data it protects, the protection is undermined. DEKs are intended to be protected separately, often by a distinct key-encrypting key, and access to key material should be strictly controlled.

Best practices

Protect the DEK separately from the data it encrypts, for example by encrypting the DEK with a distinct key-encrypting key and restricting access to key material.

Do not use a DEK to justify retaining sensitive authentication data after authorization; ensure such data is not stored post-authorization even in encrypted form.

Define and enforce a full key lifecycle for each DEK, including secure generation, storage, rotation, retirement, and destruction.

Limit access to DEKs to the fewest necessary custodians and processes, and log and monitor key usage.

Do not assume that using a DEK removes data from PCI DSS scope; validate the actual scope impact of your encryption implementation against the current published standard.

Distinguish encryption via DEKs from tokenization, truncation, masking, and hashing when designing data protection, choosing the mechanism appropriate to the data element and required access.