KMS Key Rotation and SOC 2 CC6.1

SOC 2 CC6.1 requires that "logical access security measures are implemented to protect against threats from sources outside the entity's system boundaries" and specifically addresses the management of cryptographic keys. Key rotation is a key (no pun intended) operational security practice that auditors evaluate.

AWS Key Management Service (KMS) manages cryptographic keys for your AWS services. KMS keys are used for S3 encryption, RDS storage encryption, Secrets Manager encryption, and direct application encryption. The requirement that matters for SOC 2: automatic key rotation should be enabled for Customer Managed Keys (CMKs).

What Key Rotation Does (and Doesn't Do)

When KMS key rotation is enabled, AWS automatically creates a new backing key material for the CMK every year. The CMK's key ID, ARN, and alias stay the same — so no application changes are needed. Data encrypted with the old key material can still be decrypted; AWS keeps the old backing material to decrypt data that was encrypted with it.

What rotation doesn't do: it doesn't re-encrypt existing data with the new key. It just ensures that new encryption operations use new key material. This limits the blast radius if older key material is somehow exposed.

SecureSpect's KMS Check

aws.kms.key_rotation — CC6.1
For each Customer Managed Key (CMK) that is ENABLED and not pending deletion:
verifies that key rotation is enabled.
AWS managed keys (aws/...) are excluded — they rotate automatically.

The most common finding: developers create CMKs for specific use cases (a Secrets Manager CMK, an RDS CMK) and forget to enable rotation before moving on.

Checking and Enabling Key Rotation

# List all CMKs in the account
aws kms list-keys --query 'Keys[*].KeyId' --output text
# Check rotation status for a specific key
aws kms get-key-rotation-status --key-id 
# Enable rotation for a key (does not rotate immediately — schedules annual rotation)
aws kms enable-key-rotation --key-id 
# Bulk check: list all CMKs without rotation enabled
for key_id in $(aws kms list-keys --query 'Keys[*].KeyId' --output text); do
  metadata=$(aws kms describe-key --key-id $key_id --query 'KeyMetadata.{Manager:KeyManager,State:KeyState}' --output json)
  manager=$(echo $metadata | jq -r '.Manager')
  state=$(echo $metadata | jq -r '.State')
  if [ "$manager" = "CUSTOMER" ] && [ "$state" = "Enabled" ]; then
    rotation=$(aws kms get-key-rotation-status --key-id $key_id --query 'KeyRotationEnabled' --output text)
    echo "$key_id: rotation=$rotation"
  fi
done

KMS Key Policies for SOC 2

Beyond rotation, auditors review KMS key policies for CC6.1 (access control). Key policy red flags:

• Key policy allows kms:* for a broad principal
• Key policy allows cross-account access without documented justification
• Key policy has no condition keys limiting usage

A secure baseline key policy restricts key usage to the specific services and IAM roles that need it.

FAQ

Do AWS managed keys (aws/s3, aws/rds) need rotation enabled? No. AWS managed keys rotate automatically every year. You can't control this, and you don't need to. Only check Customer Managed Keys.

Does key rotation change anything for running applications? No. KMS handles the rotation transparently. Applications continue using the same key ID, ARN, and alias — AWS handles which backing key material to use for decryption.

What if I have keys pending deletion? Keys in PendingDeletion state are excluded from the rotation check. However, verify that these keys truly have no resources depending on them before deletion completes.