Key rotation enforced annually
Why it matters
CWE-324 (use of a key past its expiration date) describes the accumulating risk of long-lived keys: the longer a key is in use, the more ciphertext an attacker accumulates to attempt cryptanalysis against, and the longer a previously undetected key compromise remains exploitable. NIST SP 800-57 Part 1 sets maximum key usage periods; for symmetric keys protecting sensitive data, annual rotation is the established upper bound. PCI-DSS 4.0 Req-3.7.4 explicitly requires cryptoperiod management for encryption keys. An unrotated key that was compromised six months ago continues to expose all data encrypted since the compromise — rotation limits the blast radius of any past key exposure.
Severity rationale
High because a stale encryption key that was silently compromised continues to expose all protected data indefinitely until rotation occurs, with no observable signal of the ongoing breach.
Remediation
Enable automatic annual rotation in your KMS — this is one console toggle, not a code change. For AWS KMS:
AWS Console → KMS → Customer managed keys → [your key] → Key rotation → Enable automatic key rotation
For Google Cloud KMS:
gcloud kms keys update [KEY_NAME] \
--location=[LOCATION] \
--keyring=[KEYRING] \
--rotation-period=365d \
--next-rotation-time=$(date -u -d '+365 days' +%Y-%m-%dT%H:%M:%SZ)
If you manage keys manually, create a rotation log at docs/key-rotation.md with signed entries and a calendar reminder. Manual rotation without a dated audit trail fails this check even if rotation occurred — the evidence requirement is a log entry, not just a newer key version.
Detection
- ID:
key-rotation-annual - Severity:
high - What to look for: Count all key rotation policies and quote the actual rotation schedule found. Check KMS rotation settings for automatic rotation. Count all dated rotation records and verify the most recent is within 365 days. A rotation interval exceeding 365 days does not count as pass.
- Pass criteria: Either automated key rotation is enabled in KMS, OR a documented manual rotation procedure exists with at least 1 execution record within the past 365 days. Report the count even on pass (e.g., "AWS KMS automatic rotation enabled, last rotation 2025-09-20, rotation interval: 365 days").
- Fail criteria: No key rotation policy documented (0 policies), or no rotation evidence within the past 365 days, or rotation interval exceeds 365 days.
- Skip (N/A) when: Encryption is provided entirely by a managed service with automatic rotation handled by the provider — cite the actual service found.
- Detail on fail:
"0 key rotation policies documented. Last rotation record: none found"or"Manual rotation exists but last executed 730 days ago — exceeds 365-day maximum" - Remediation:
- Enable automatic key rotation in your KMS:
AWS KMS: Enable automatic key rotation in Key Properties > Key Rotation Google Cloud KMS: Enable Automatic Rotation in Key Management > Rotation Schedule Azure Key Vault: Enable Automatic Rotation in Key > Rotation Policy - Document manual rotation procedure if not using automatic rotation:
# Key Rotation Policy - Frequency: Annual (12 months) - Process: [specific steps to rotate keys] - Last rotated: 2024-06-15 - Next rotation due: 2025-06-15 - Sign-off: [authorized person] - Track rotations in a log or audit trail.
- Enable automatic key rotation in your KMS:
External references
- cwe · CWE-324 — Use of a Key Past its Expiration Date
- nist:rev5 · SC-12 — Cryptographic Key Establishment and Management
- pci-dss:4.0 · Req-3.7.4 — Cryptographic key changes at least annually
- nist:rev5 · SP-800-57 Part 1 — Recommendation for Key Management, Part 1: General — Cryptoperiods
Taxons
History
- 2026-04-18·v1.0.0·Initial import from finserv-encryption·automated