Key Rotation Strategies

Key rotation is the process of replacing an active cryptographic key with a new one, either on a predetermined schedule (crypto-period expiry) or in response to an event (suspected compromise, personnel change, algorithm deprecation). The goal: limit the amount of data protected by any single key, so that if a key is eventually compromised, the exposure is bounded to a specific time window rather than the entire history of encrypted data.

Why it matters

• Bounds compromise exposure — a key active for 1 year protects 1 year of data. If compromised, only that year is exposed. A key active for 10 years exposes a decade.
• Compliance mandate — PCI DSS requires rotation per defined crypto-period. NIST SP 800-57 recommends 1-2 years for symmetric keys. Auditors verify rotation evidence.
• Algorithm migration — rotating from RSA-2048 to ECDSA P-256, or from classical to post-quantum, happens through the rotation mechanism. It’s how you upgrade crypto in production.
• Personnel changes — when key custodians leave, rotation ensures they can’t use knowledge of old keys. The new key was generated after their departure.
• Operational hygiene — regular rotation exercises prove your rotation process works. Discovering it’s broken during an emergency (compromise response) is the worst time.

How it works

Strategy 1: Versioned keys (most common for encryption)

1. Generate new key version (v2)
2. All new encryption uses v2
3. Old key (v1) retained in deactivated state for decrypting existing data
4. Gradually re-encrypt old data with v2 (optional, for full migration)
5. Once no data remains encrypted with v1, destroy v1

Strategy 2: Re-keying (required for signing keys)

1. Generate new key
2. Deploy new key to all systems
3. Verify new key is operational
4. Revoke/deactivate old key
5. Old signatures remain verifiable (public key retained), but no new signatures possible

Strategy 3: Dual-active period (zero-downtime rotation)

1. Generate new key, deploy alongside old key
2. Both keys active simultaneously (overlap period)
3. Systems gradually switch to new key
4. Once all systems use new key, deactivate old key
5. After retention period, destroy old key

In real systems

AWS KMS automatic rotation:

# Enable annual auto-rotation
aws kms enable-key-rotation --key-id alias/data-key

# How it works:
# - AWS generates new backing key material annually
# - New encryptions use new key version
# - Old versions retained automatically for decryption
# - Key ARN/alias stays the same — no application changes needed
# - Completely transparent to applications

# Check rotation status
aws kms get-key-rotation-status --key-id alias/data-key

TLS certificate key rotation (ACME):

# Certbot generates new key pair at each renewal by default
certbot renew
# New private key + new certificate every 60 days
# Old key overwritten — no retention needed (TLS keys are ephemeral)
# Zero-downtime: new cert deployed, nginx reloaded

Database encryption key rotation (envelope encryption):

# Pattern: rotate the Key Encryption Key (KEK), not every Data Encryption Key (DEK)

Before rotation:
  KEK-v1 encrypts → DEK-1, DEK-2, DEK-3 (each DEK encrypts data)

After rotation:
  KEK-v2 generated
  Re-wrap all DEKs: decrypt with KEK-v1, re-encrypt with KEK-v2
  DEK-1, DEK-2, DEK-3 now wrapped by KEK-v2
  Destroy KEK-v1

# Data itself is NOT re-encrypted — only the DEK wrappers change
# Much faster than re-encrypting terabytes of data

Kubernetes Secret rotation (cert-manager):

apiVersion: cert-manager.io/v1
kind: Certificate
spec:
  secretName: api-tls
  duration: 2160h      # 90 days
  renewBefore: 720h    # Rotate 30 days before expiry
  privateKey:
    rotationPolicy: Always  # New key pair at every renewal
  # cert-manager handles: generate new key → request cert → update Secret → ingress reloads

Where it breaks

Rotation without re-wrapping — the encryption key is rotated (new key generated), but existing encrypted data still references the old key. The old key must be retained indefinitely because data encrypted with it still exists. Over years, you accumulate dozens of “deactivated but retained” key versions. Solution: after rotation, schedule a re-encryption job that re-wraps existing data with the new key, then destroy the old key.

Application caches old key — the key is rotated in KMS, but the application cached the old key material in memory (for performance). The application continues encrypting with the old key. New data is encrypted with a deactivated key. Applications must either: not cache key material (call KMS for every operation), or have a cache invalidation mechanism triggered by rotation events.

Rotation breaks consumers — a signing key is rotated, but downstream systems that verify signatures still have only the old public key. New signatures fail verification. Before rotating signing keys: distribute the new public key to all verifiers, wait for propagation, then activate the new signing key. Rotation of signing keys requires coordination with all relying parties.

Operational insight

The most practical rotation strategy for most organizations: automate everything possible (KMS auto-rotation for encryption keys, ACME/cert-manager for TLS keys, Vault for short-lived credentials) and manually rotate only what can’t be automated (Root CA keys, HSM master keys, legacy system credentials). For the manual cases, schedule rotation exercises annually — even if the crypto-period hasn’t expired — to verify the process works and the team knows how to execute it. A rotation procedure that hasn’t been tested in 3 years is a rotation procedure that will fail when you need it most.

Related topics

• Key Lifecycle Management
• Key Generation Best Practices
• NIST SP 800-57 Key Management
• Certificate Validity and 90-Day Proposals
• SSH Key Rotation