Rotate, version, and revoke keys

Keys and algorithms have lifecycles. Keys leak, employees leave, algorithms age out of guidance. Design the data format so old records can be read while new writes use the current key — because one day you will rotate under pressure, and that is the wrong day to invent a migration.

Version everything you protect

Store a non-secret key identifier and format version with ciphertext or signatures:

{
  "v": 2,
  "kid": "field-key-2026-08",
  "nonce": "9mPqL2Xb8kQz",
  "tag": "4sR7...",
  "ciphertext": "..."
}

Reads become a lookup instead of a guessing game:

const keyring = {
  'field-key-2026-02': oldKey,   // decrypt only
  'field-key-2026-08': currentKey,
}

const key = keyring[record.kid]
if (!key) throw new Error(`unknown key id: ${record.kid}`)

Compare that with the failure mode: ciphertext records store no key identifier. After rotation, the application must try every historical key, creating slow failures and making retirement unsafe — you can never prove a key is unused, so you can never delete it.

Rotate in phases

A versioned format supports new writes with the current key and controlled reads with older keys. Rotation becomes routine:

phase 1: add key v2 to the keyring        (reads: v1+v2, writes: v1)
phase 2: switch writes to v2              (reads: v1+v2, writes: v2)
phase 3: re-encrypt or expire v1 records
phase 4: retire v1 to decrypt-only, then delete per retention policy

Keep old decrypt-only keys during migration, then retire them according to retention needs. Watch a metric of reads per key version; phase 4 starts when v1 reads hit zero.

Revocation is not rotation

Rotation is planned. Revocation is what you do when a key may be compromised, and it must be fast: stop trusting the key now, not after a migration.

For signing keys that can mean revoking trust and issuing a clean replacement, plus deciding whether things signed earlier remain acceptable. For encryption keys, immediate revocation can make old data unavailable — records encrypted under the revoked key stop being readable. So compromise response and data recovery need an explicit tradeoff, written down before the incident: which data you would sacrifice, and who makes that call at 3am.

Practice

Write and save a migration plan from key version 1 to version 2 using new-write and old-read phases. Encrypt records under both versions and prove the key identifier selects the correct key without trial decryption. Then revoke version 1 in a test environment and record which reads fail and how the recovery decision is made.