CIS AWS Foundations v1.2 2.8: AWS KMS key rotation should be enabled

CIS AWS Foundations v1.2 control 2.8 focuses on a simple operational outcome: your AWS KMS keys should rotate on a defined schedule supported by AWS. In practice, auditors and internal risk teams look for two things: (1) rotation is enabled where AWS supports it, and (2) you can demonstrate ongoing enforcement across accounts and regions, not a one-time console screenshot.

This requirement usually lands with Cloud Security, Platform Engineering, or whoever owns centralized encryption standards, but compliance owns the “prove it” work: scoping, exception handling, evidence retention, and demonstrating continuous operation. The fastest path is to align the control to AWS Security Hub’s CIS benchmark mapping and then operationalize around the mapped check (KMS.4) with a tight remediation workflow ¹. The CIS benchmark itself is the governing benchmark reference for what “good” looks like at the baseline level ².

What follows is requirement-level implementation guidance: what the requirement means in plain English, exactly who it applies to, how to enable and enforce it at scale, what evidence to retain, and where teams typically fail during audits.

Regulatory text

Excerpt (provided): “Implement CIS AWS Foundations Benchmark v1.2 requirement 2.8 as mapped in AWS Security Hub.” ³

Operator interpretation: You are expected to implement the CIS AWS Foundations Benchmark requirement for KMS key rotation, using AWS Security Hub’s mapping as the operational test of compliance (commonly surfaced as Security Hub control KMS.4) ¹. Concretely: you must identify the KMS keys in scope, enable rotation where supported, prevent drift, and retain evidence that the setting is enabled over time.

Plain-English interpretation (what the requirement means)

• Goal: Reduce the risk that a long-lived key is abused indefinitely by ensuring cryptographic material is periodically rotated for supported KMS keys.
• Pass condition: Rotation is enabled on customer managed KMS keys where AWS supports automatic rotation, and you can show the control is continuously monitored and remediated ¹.
• Fail condition: Customer managed keys exist with rotation disabled (or you cannot prove status across all accounts/regions), and there is no approved exception path aligned to your policy.

Who it applies to

Entity scope

• Any organization operating workloads in AWS that adopts CIS AWS Foundations as a baseline standard ².
• Teams responsible for centralized encryption controls, account governance, and cloud security monitoring.

Operational scope (what systems and keys)

• AWS accounts and regions where you create or manage customer managed KMS keys used by AWS services (S3, EBS, RDS, etc.) or application-level encryption.
• Control validation commonly runs through AWS Security Hub CIS mapping ¹.

Common scoping decision you must make

• Which keys are “must-rotate” (typically: all eligible customer managed symmetric encryption keys used to protect production data).
• Which keys are excluded and why (for example, keys that are not eligible for automatic rotation, or keys managed outside AWS KMS with a different rotation mechanism). Document this explicitly so your audit story stays consistent.

What you actually need to do (step-by-step)

Step 1: Define the control statement and scope

Write a control narrative that maps directly to the benchmark language:

• “All eligible customer managed symmetric AWS KMS keys have automatic rotation enabled. Rotation status is monitored centrally and noncompliance triggers remediation or an approved exception.” ³

Then define:

• In-scope AWS accounts (production, shared services, logging).
• In-scope regions (all enabled regions, or the regions you allow by policy).
• In-scope key types (customer managed symmetric keys eligible for rotation).

Step 2: Build a KMS key inventory ²

You need an inventory you can reconcile against monitoring outputs:

• Enumerate keys.
• Capture metadata: key ID/ARN, alias, account, region, key manager (AWS vs customer), key state, and rotation status.

Operational tip: do this centrally (multi-account) so you don’t rely on ad hoc spreadsheets. If you use Daydream for control operations, store the inventory export and the query method as part of your evidence package so you can rerun it during an audit without re-engineering.

Step 3: Enable automatic rotation on eligible keys

For each eligible customer managed symmetric key:

• Enable key rotation in AWS KMS (console/CLI/IaC).
• Ensure your infrastructure-as-code defaults set rotation to “on” so you don’t reintroduce noncompliant keys.

Exception handling:

• If a key cannot have AWS-managed automatic rotation enabled, record the reason, the compensating control (manual rotation runbook or alternative key management), and an approver. Keep exceptions time-bound and reviewable.

Step 4: Implement continuous detection using Security Hub (CIS mapping)

Turn the benchmark requirement into a measurable control:

• Enable AWS Security Hub.
• Enable the CIS AWS Foundations standard and confirm the control that maps to this requirement is active (commonly KMS.4) ¹.
• Route findings to your ticketing/alerting pipeline so failures become work items, not dashboard debt.

What auditors want: evidence that you detect noncompliance reliably and that exceptions are intentional, reviewed, and documented.

Step 5: Add drift prevention and automated remediation

Detection without response fails in real environments. Add at least one of:

• AWS Config rule(s) and auto-remediation to enable rotation on newly created eligible keys.
• IaC guardrails (policy-as-code checks in CI) to block key creation without rotation.
• An event-driven function that flags or remediates keys created without rotation.

Control design note: choose a mechanism that fits your operating model. If engineering owns IaC end-to-end, CI guardrails prevent the issue. If teams create keys in-console, Config plus remediation is usually more effective.

Step 6: Prove operation (evidence cadence and review)

Create an operating rhythm:

• Review Security Hub findings for this control in your normal security operations cadence.
• Track: finding opened, owner assigned, remediation completed, exception approved (if any).
• Periodically export the current “rotation enabled” state for your key inventory.

Daydream can help here by linking requirement text, the Security Hub control mapping, and your evidence artifacts into a single audit-ready control record, reducing the scramble to reconstruct history later.

Required evidence and artifacts to retain

Keep evidence that shows design, implementation, and ongoing operation:

Design artifacts

• Cloud encryption/key management standard that states rotation expectations and exception criteria.
• Control mapping showing CIS 2.8 aligned to AWS Security Hub CIS control mapping ¹.

Implementation artifacts

• Key inventory export (account/region coverage).
• Configuration evidence that rotation is enabled (API outputs, IaC config, or console exports).
• Change records for keys modified to enable rotation.

Operational artifacts

• Security Hub findings history for the mapped control (KMS.4) and your triage/remediation tickets ¹.
• Exception register: key ARN, justification, compensating control, approver, review date.
• Periodic attestation or control owner review notes.

Common exam/audit questions and hangups

1. “Show me all KMS keys and which ones have rotation enabled.”
   Hangup: teams show a partial list (one region, one account) or can’t prove completeness.

2. “Which keys are out of scope, and who approved that?”
   Hangup: exceptions exist in practice but not on paper.

3. “How do you ensure new keys are compliant?”
   Hangup: rotation is enabled on today’s keys but there is no prevention for tomorrow’s keys.

4. “Do you monitor this continuously or just annually?”
   Hangup: a screenshot from months ago does not demonstrate control operation.

Frequent implementation mistakes (and how to avoid them)

• Mistake: treating this as a policy-only requirement.
  Fix: make the pass/fail measurable via Security Hub CIS mapping and store evidence of monitoring output ¹.

• Mistake: incomplete scope (missing regions/accounts).
  Fix: maintain an authoritative AWS account list and a defined region policy; reconcile inventory coverage to those lists.

• Mistake: no exception process.
  Fix: create a lightweight exception workflow with required fields (reason, compensating control, expiry/review) and enforce it.

• Mistake: enabling rotation manually but not updating IaC defaults.
  Fix: bake rotation into modules/templates so the compliant configuration is the default path.

• Mistake: no drift response.
  Fix: assign an owner and SLA for Security Hub findings for this control; document the workflow and keep ticket evidence.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific CIS AWS Foundations requirement. Treat this as a baseline security control that reduces the blast radius of key compromise and supports auditability of encryption governance ². The practical risk is twofold: (1) prolonged exposure if key material is compromised, and (2) audit/control failures when you cannot demonstrate continuous operation across cloud sprawl.

Practical execution plan (30/60/90)

Day 0–30 (Immediate stabilization)

• Confirm Security Hub is enabled and CIS AWS Foundations standard checks are active for all in-scope accounts ¹.
• Produce the first complete KMS key inventory and tag in-scope keys.
• Enable rotation on the highest-risk production keys first; document any keys that cannot be rotated automatically and open exceptions.

Day 31–60 (Operationalize and prevent drift)

• Implement drift detection and route findings into ticketing with clear ownership.
• Update IaC templates/modules to default to rotation enabled for eligible keys.
• Stand up an exception register with approvers and review triggers.

Day 61–90 (Prove control operation)

• Run a formal control review using evidence: inventory, current rotation state, and Security Hub finding history ¹.
• Test the workflow by creating a noncompliant key in a sandbox and verifying detection, ticketing, and remediation.
• Package artifacts into an audit-ready folder (or a Daydream control record) with a single “how to reproduce evidence” runbook.

Frequently Asked Questions

Does this requirement apply to AWS-managed KMS keys (AWS owned keys)?

The operational focus is on customer managed KMS keys where you control configuration. AWS Security Hub’s CIS mapping is the practical way auditors validate the setting ¹.

What if a key is not eligible for automatic rotation?

Record an exception with the key ARN, the reason it is not eligible, and the compensating control (for example, a manual rotation runbook). Auditors usually accept exclusions that are explicit, approved, and periodically reviewed.

Is enabling Security Hub enough to claim compliance?

No. Security Hub provides detection and reporting against the CIS mapping, but you still need remediation, exception handling, and retained evidence of operation over time ¹.

How do we prove coverage across multiple AWS accounts?

Maintain an authoritative list of in-scope accounts and show Security Hub/CIS is enabled across them, then reconcile your key inventory against that scope. Store exports and the method used to generate them so you can reproduce results consistently.

What evidence is strongest for auditors: screenshots or exports?

Prefer exports or API-derived reports that show complete scope (accounts/regions/keys) plus the Security Hub findings history tied to tickets. Screenshots can support, but they rarely prove completeness at scale.

How should we handle third parties that manage encryption inside our AWS accounts?

Treat third-party operators as part of your control boundary: require contractual obligations to follow your KMS key standards, and verify via your own Security Hub findings and inventory rather than relying on their attestations ¹.

Footnotes

1. AWS Security Hub CIS AWS Foundations mapping table

2. CIS AWS Foundations Benchmark

3. CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table