KMS.3: A KMS key is scheduled for deletion and will take data with it

What does AWS Security Hub KMS.3 check?

KMS.3 fails when a customer-managed KMS key is in the PendingDeletion state. A scheduled deletion runs after a mandatory 7-to-30-day waiting period, after which the key — and access to everything it encrypted — is gone permanently.

Why does KMS.3 matter?

Deleting a KMS key is effectively deleting all the data it protects: ciphertext encrypted under that key becomes unrecoverable. A decommissioning script once scheduled deletion of 14 "orphaned" keys, three of which were still encrypting live RDS clusters. The waiting period is the only safety net, and KMS.3 is the alarm that buys you time to cancel before the clock runs out.

How do I fix KMS.3?

1. List keys in PendingDeletion and check each one's scheduled deletion date.
2. Confirm whether the key still protects active data (RDS, EBS, S3, secrets) before letting any deletion proceed.
3. Cancel an unintended deletion with cancel-key-deletion and re-enable the key.
4. Put guardrails in place: disable-before-delete as policy, key-policy restrictions on ScheduleKeyDeletion, and an alarm on the API call.

# Stop the irreversible clock first: cancel any scheduled deletion, then re-enable.
for k in $(aws kms list-keys --query 'Keys[].KeyId' --output text); do
  state=$(aws kms describe-key --key-id "$k" \
    --query 'KeyMetadata.KeyState' --output text)
  if [ "$state" = "PendingDeletion" ]; then
    aws kms cancel-key-deletion --key-id "$k"
    aws kms enable-key --key-id "$k"   # cancel leaves it Disabled
    echo "$k: deletion cancelled and re-enabled"
  fi
done

# Turn rotation on for eligible customer-managed symmetric keys.
for k in $(aws kms list-keys --query 'Keys[].KeyId' --output text); do
  read -r mgr spec <<<"$(aws kms describe-key --key-id "$k" \
    --query 'KeyMetadata.[KeyManager,KeySpec]' --output text)"
  if [ "$mgr" = "CUSTOMER" ] && [ "$spec" = "SYMMETRIC_DEFAULT" ]; then
    aws kms enable-key-rotation --key-id "$k"
  fi
done