AWS Security Hub · KMS
KMS.3: A KMS key is scheduled for deletion and will take data with it
Written and reviewed by Emnode · Last reviewed
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?
- List keys in PendingDeletion and check each one's scheduled deletion date.
- Confirm whether the key still protects active data (RDS, EBS, S3, secrets) before letting any deletion proceed.
- Cancel an unintended deletion with cancel-key-deletion and re-enable the key.
- Put guardrails in place: disable-before-delete as policy, key-policy restrictions on ScheduleKeyDeletion, and an alarm on the API call.
Remediation script · bash
# 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
doneFull walkthrough (console steps, edge cases and verification) in the lesson Manage KMS encryption keys.
Is KMS.3 a false positive?
Sometimes scheduling a key for deletion is exactly the point: a deliberate cryptographic erasure, where destroying the key is how you make the data it encrypted permanently unrecoverable: the documented way to retire a tenant's data or meet a right-to-be-forgotten obligation. AWS itself flags this as the legitimate exception to KMS.3. When the deletion is intentional, leave it scheduled and suppress the finding with a note recording the erasure decision and the scheduled deletion date, rather than cancelling it to clear the control; cancelling would undo the erasure you meant to perform. Reserve the cancel-key-deletion remediation for keys whose deletion was a mistake.