Field Journal

Key Management / Rotation

Rotation, Versioning, Rewrapping & Re-encryption

Rotation changes the key material used for new protection. It normally does not rewrite existing ciphertext, remove old dependencies, or repair a compromise by itself. Safe retirement requires a provider-resolvable historical read path; application-visible version models also require explicit version references and a separate decision about rewrapping or re-encrypting old data.

Rotation models expose different version controls

Rotation first changes the material used for new protection, but providers expose historical material through two different operating models:

Rotation model Historical resolution Customer-visible controls Retirement implication
Opaque in-place material rotation The provider retains internal material behind one logical key and selects the required material during decryption. The caller normally addresses the logical key, not an individual internal material version. Per-material usage, disablement, and destruction may not be customer-visible or customer-controlled.
Explicit key version or manual logical-key rotation Ciphertext or application metadata identifies a selectable key version or distinct logical key. The customer can resolve, measure, disable, and sometimes destroy specific versions or keys. Version-level telemetry and reversible disablement can support staged retirement.

AWS KMS automatic and on-demand rotation normally use the opaque model: AWS KMS retains prior material and selects the correct material for decryption, while callers continue to address the same KMS key. AWS manual rotation creates a distinct KMS key and repoints an alias, so old ciphertext still requires the original key. Google Cloud KMS rotation uses explicit CryptoKeyVersion objects: it creates a new primary version but does not re-encrypt data or disable or destroy previous versions.

All three behaviors preserve historical processing, but their observability and retirement controls differ. Inventory remains necessary; version-level usage telemetry and disablement tests apply only when the provider exposes the relevant version or logical key.

Scheduled and event-driven rotation solve different problems

Trigger Purpose Required follow-through
Scheduled cryptoperiod end Limit exposure and meet local or external policy Activate the new version, move new protection, observe old-version use, then retire dependencies.
Personnel, ownership, or environment change Remove access paths or change custody Review principals and copies; rotation alone does not revoke an unauthorized copy.
Algorithm or parameter transition Move to a different cryptographic construction Test formats, APIs, hardware, certificates, protocols, and interoperability.
Suspected or confirmed compromise Stop trusting the old material Disable or revoke new protective use immediately, determine compromise timing, replace independent material, and remediate affected data or signatures.

Automatic rotation is useful for predictable version creation. It is not a complete incident-response mechanism because the old material may remain enabled and provider rotation may preserve the same logical policy boundary.

Distinguish rewrapping from re-encryption

Operation What changes Plaintext bulk data exposed? Typical use
Rotate KEK version New DEKs are wrapped by the new KEK version No Change the write path while retaining old KEK versions for existing encrypted DEKs.
Rewrap encrypted DEK Existing DEK is unwrapped and wrapped under a new KEK; payload ciphertext stays unchanged Not necessarily; the DEK is exposed inside an authorized cryptographic boundary or process Remove dependency on an old KEK without processing the entire payload.
Rotate DEK New payloads use a new DEK No change to existing payloads Limit per-key data volume or scope.
Re-encrypt bulk data Plaintext is recovered and encrypted under a new DEK Yes, within the re-encryption path Remove dependency on a compromised DEK, change content algorithm or AAD, or meet a data-migration requirement.

Rewrapping is sufficient only when the DEK and payload construction remain trusted. If the DEK may be compromised, wrapping the same DEK under a new KEK does not restore confidentiality.

Version every dependency explicitly

An encrypted envelope should carry or resolve all information needed to select the right primitive and key:

Aliases are useful for the write path but dangerous as the only stored reference. If an alias is repointed, old ciphertext still needs to resolve the exact version that protected it. The same rule applies to public keys and certificates: consumers need the correct historical verification key, not merely today’s alias.

Use a staged retirement workflow

The following workflow applies when the old version or logical key is independently addressable. Opaque in-place rotation does not expose every step; in that model, document the provider’s historical resolution, telemetry, and retirement controls instead of implying that an internal material version was measured or disabled.

  1. Create or generate independent replacement material.
  2. Validate permissions, replication, quotas, latency, and disaster recovery before activation.
  3. Make the replacement version or logical key primary for new protective operations.
  4. Measure old-version decrypt, unwrap, verify, and direct-use requests by workload.
  5. Rewrap or re-encrypt dependencies according to the threat and retirement objective.
  6. Disable the old version and observe failures for a defined test window.
  7. Restore if an unknown dependency appears; otherwise complete the approved destruction workflow.

The disable test is intentionally reversible and applies only where the old version or logical key can be disabled independently. A zero-error observation window reduces risk but does not prove that dormant archives, offline clients, or disaster-recovery copies have no dependency. With opaque in-place rotation, the provider may retain internal historical material without offering customer-controlled retirement of an individual material version; do not claim that the generic staged workflow removed that dependency.

What I need to remember

Rotation changes which material protects new data; old ciphertext still needs provider-retained historical material or an explicit old version until dependencies are migrated. Rewrap when the DEK remains trusted, re-encrypt when the DEK or content construction has to change, and apply version-level disablement only when the provider exposes that control.

Primary references