Envelope encryption and key rotation: data keys, KMS keys and backups

Envelope encryption encrypts data with a data-encryption key (DEK), then protects that DEK with a key-encryption key (KEK), usually through a managed key service. A stored record contains the encrypted data, nonce/tag and context information, wrapped DEK, and identifiers needed to select the approved wrapping key.

On read, the application authorizes the request, asks the key service to unwrap the DEK under the expected context, and uses the DEK to authenticate and decrypt the data. The key service can enforce who may unwrap, but once plaintext or a DEK reaches the authorized process, a compromise of that process can expose it.

Rewrapping changes protection of the DEK without necessarily changing the data ciphertext or DEK. Re-encryption creates new data ciphertext, usually with a new DEK and nonce. If the DEK itself was compromised, merely rewrapping it under a new KEK does not remove the attacker’s ability to decrypt a captured old ciphertext.

In layers, choosing each by who must not be able to read the data. Storage encryption with provider-managed keys protects against lost disks and discarded hardware and is usually on by default (Amazon S3 has encrypted every new object since January 2023). Encryption with a customer-managed key in your KMS adds access control, an audit trail of every decryption and the option to crypto-shred. Application-level envelope encryption of sensitive fields or records, as on this page, is the only layer that also keeps the data unreadable to database administrators, database dumps, backups and services that can query the database but cannot use the key.

Every layer decrypts transparently for anyone who reaches the data through the path that holds the key, so none of them stops SQL injection or a compromised application server with decryption rights. Start with storage encryption everywhere, use customer-managed keys for regulated or sensitive stores, and add application-level encryption for the fields whose exposure would hurt most, such as identity documents, health data, payment tokens and secrets.

Bind tenant, record identity, purpose, and format to data authentication and, where supported, to the wrapping operation’s context. Store key versions explicitly enough to locate the correct old KEK during migration. An alias named current is useful for new writes but insufficient to explain how an old wrapped DEK can be opened.

Keep encryption permission separate from decryption and administration where the service supports it. A worker that writes new records may not need to unwrap all historical data. A key administrator should not automatically become an application data reader merely because both operations live in one console.

Per-record DEKs limit compromise and deletion scope but add metadata and key-service calls. Reusing one DEK across many records reduces those calls but enlarges what one leaked key exposes and creates a nonce budget: with random 96-bit nonces, AES-GCM allows at most 2^32 encryptions per key. The AWS Encryption SDK caps a cached data key at 2^32 messages for the same reason. Caching unwrapped DEKs reduces latency and dependence on the key service but keeps them in application memory longer and delays the effect of revoking unwrap permission.

The design must state behavior during a key-service outage. New writes should not silently downgrade to plaintext or a hard-coded fallback key. Reads may use previously authorized cached keys only within a documented policy; availability decisions should not bypass tenant or key-context checks.

The three services implement the same pattern with different names and limits. Pass record context to the key service where it accepts it, and always bind the same context in the data-layer AEAD, so a wrapped key or a ciphertext copied to another record fails to open.

None of the three re-encrypts data when it rotates a key. Rotation adds a new key version for new wraps; old versions stay usable for decryption until you disable or destroy them. Re-encrypting records is your migration job, and deleting a key version is irreversible once its waiting period ends.

For planned KEK rotation, make K2 available for wrapping new DEKs and keep K1 enabled for existing reads. Migrate old wrapped DEKs to K2 with a supported rewrap call (such as AWS KMS ReEncrypt) or an unwrap and rewrap inside your service. Authenticate the existing metadata, write the replacement envelope atomically, and record enough version state to retry safely. With managed automatic rotation the service does the key-version part for you, but old versions stay in use until your own records stop referencing them.

Consider a crash after creating a new wrapped DEK but before committing the record. A retry must either recognize the committed new version or repeat the safe operation from the old version. It must not delete the only usable wrapped key first. A conditional update on the record version prevents a migration worker from overwriting a concurrent application update.

Before disabling K1, measure remaining live references, queued jobs, replicas, exports, and retained backups. A live-table count of zero does not mean every recoverable snapshot uses K2. Restore an old backup in a controlled environment and follow its documented key-access path.

For compromise, distinguish which keys and ciphertexts the attacker may have copied. Rewrapping can reduce future access through a stolen service credential after revocation, but cannot make previously disclosed DEKs or plaintext secret again. Choose re-encryption and incident containment based on that exposure, not simply the desire to finish a rotation dashboard.

This example uses the cryptography package and a dictionary standing in for the KMS, so the logic can run locally. Each record gets its own 256-bit DEK, the same versioned context is authenticated at both layers, and rewrapping changes only the wrapped key. It was tested with cryptography 50 on Python 3.14: a record moved to another tenant or ID fails, a tampered wrapped key fails, and a backup copy that was never rewrapped cannot be opened once the old KEK is retired. In production, replace wrap and the KEK lookup with your KMS client’s encrypt and decrypt calls, passing the same context. The AEAD record guide at /domains/identity-crypto/encryption/authenticated-record-design/ and its project practice the record-binding half with real Web Crypto AES-GCM.

import json
import os

from cryptography.hazmat.primitives.ciphers.aead import AESGCM

# Stand-in for a KMS: key-encryption keys (KEKs) by ID. In production the KEK never leaves the KMS
# and wrap/unwrap are KMS calls that take the same context as encryption context or AAD.
KEKS = {"kek-2": AESGCM.generate_key(bit_length=256)}
CURRENT_KEK = "kek-2"


def context(tenant: str, record_id: str, purpose: str) -> bytes:
    return json.dumps([1, tenant, record_id, purpose]).encode()  # unambiguous, versioned


def wrap(kek_id: str, dek: bytes, aad: bytes) -> dict:
    nonce = os.urandom(12)
    return {"kek": kek_id, "nonce": nonce, "wrapped": AESGCM(KEKS[kek_id]).encrypt(nonce, dek, aad)}


def encrypt_record(tenant: str, record_id: str, plaintext: bytes) -> dict:
    aad = context(tenant, record_id, "invoice")
    dek = AESGCM.generate_key(bit_length=256)  # one data key per record: no shared nonce budget
    nonce = os.urandom(12)
    return {"dek": wrap(CURRENT_KEK, dek, aad), "nonce": nonce,
            "ciphertext": AESGCM(dek).encrypt(nonce, plaintext, aad)}


def decrypt_record(tenant: str, record_id: str, record: dict) -> bytes:
    aad = context(tenant, record_id, "invoice")  # from the authorized lookup, not the record
    w = record["dek"]
    dek = AESGCM(KEKS[w["kek"]]).decrypt(w["nonce"], w["wrapped"], aad)
    return AESGCM(dek).decrypt(record["nonce"], record["ciphertext"], aad)


def rewrap(tenant: str, record_id: str, record: dict) -> dict:
    """KEK rotation: same DEK and data ciphertext, new wrapping. Does not help if the DEK leaked."""
    aad = context(tenant, record_id, "invoice")
    w = record["dek"]
    dek = AESGCM(KEKS[w["kek"]]).decrypt(w["nonce"], w["wrapped"], aad)
    return {**record, "dek": wrap(CURRENT_KEK, dek, aad)}

Crypto-shredding deletes data by destroying the only key that can decrypt it. Give each tenant or data subject its own KEK or DEK, and deleting that key makes every copy of their ciphertext unreadable, including copies in backups that cannot be edited. NIST SP 800-88 Rev. 2 (September 2025) treats this as cryptographic erase.

It works only when no other copy of the key or of the plaintext survives. Exported key backups, cached DEKs, plaintext exports, search indexes and logs all defeat it. The deletion safeguards above also delay it: erasure is complete when the waiting or soft-delete period ends and the key is purged, not when someone clicks delete. Record that date as the completion time for the deletion request; the retention guide at /domains/identity-crypto/privacy/data-minimization-retention/ covers the rest of deletion.

Cloud key services already keep KEKs in hardware security modules. You need to choose a specific HSM tier, a dedicated HSM or an external key store when a regulation, contract or threat model requires it, such as a mandated FIPS 140-3 security level or keys held outside the provider. Check the provider’s current CMVP certificate rather than a product page.

NIST moved all FIPS 140-2 validations to its historical list in September 2026. Existing systems may keep using those modules, but agencies decide when to require FIPS 140-3 modules, so record the certificate and standard that each key service relies on.

Verify new writes use K2, old records remain readable during overlap, migrated records authenticate and yield identical plaintext, and K1 retirement produces the intended outcome. A wrong tenant context or modified wrapped-key metadata must fail. Include a crash/retry and a concurrent record update.

Key destruction is irreversible for data that has no other usable key path. Disable the key first where the service supports it, run a restore test while it is disabled, and destroy it only after that test. State which archives remain decryptable, which have expired, and who accepted that retention decision.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. NIST SP 800-57 Part 1 Revision 5: Key Management. Revision 5 (May 2020).
2. OWASP Key Management Cheat Sheet
3. AWS KMS: rotate keys
4. AWS KMS: encryption context
5. Google Cloud KMS: key rotation
6. Google Cloud KMS: additional authenticated data
7. Azure Key Vault: configure key rotation
8. AWS Encryption SDK: data key caching thresholds
9. NIST SP 800-88 Rev. 2: Guidelines for Media Sanitization. Revision 2 (September 2025).
10. AWS: Amazon S3 now automatically encrypts all new objects (January 2023)

Reference information

Tags

EncryptionKey managementPrivacy engineeringCloud security

SDLC phase

DesignMaintenance

Role

DevelopersPlatform engineers and SREs

ASVS 5.0.0 requirements

v5.0.0-11.1.1 · v5.0.0-11.1.2 · v5.0.0-11.3.3 · v5.0.0-11.3.4 · v5.0.0-13.3.1 · v5.0.0-13.3.3

Download this guide as Markdown

Continue exploring