KMS key rotation does not re-encrypt stored data
AWS KMS key rotation changes the key material associated with a customer managed key. It does not rotate the data keys that the KMS key generated or re-encrypt the data those data keys protect. That distinction matters when a team treats an automatic rotation schedule as proof that old ciphertext has moved to new cryptographic material.
The AWS documentation states this explicitly. Existing ciphertexts encrypted under older key material still require the old material to decrypt. A service such as Amazon EBS also documents that key rotation does not re-encrypt existing volumes or snapshots. New objects and new data keys may use new material, while older objects follow a different path.
Build a data inventory
Start with the systems that store ciphertext under a KMS key. For each system, record who owns the data, how it is encrypted, which KMS key and encryption context protect it, and how long the provider preserves old key material. Distinguish envelope encryption from direct KMS operations and distinguish a customer managed key from an AWS managed key.
Use encryption context to make the intended purpose visible. Grants can include a constraint that permits a cryptographic operation only when the request includes specified key-value pairs. That can reduce accidental reuse of a key for a different workload or account path. The constraint is not a content-based policy. It proves that the caller supplied the expected context, which should be chosen and logged deliberately.
Decide whether rotation is being used for routine key hygiene, regulatory policy, or response to a suspected compromise. The actions differ. Routine rotation may be acceptable without re-encrypting every object. A compromised key or an authorization incident may require a re-encryption campaign, credential rotation, disabling old access, and verification that all copies moved.
Keep old keys available while migration is in progress
When using a new KMS key for manual rotation, keep the original key enabled while older data still depends on it. Test decryption for historical objects, backups, logs, and replicas. A backup you cannot restore is not protected data; it is only a failure waiting for an incident.
Use provider-supported re-encryption operations to move ciphertext instead of decrypting it into an application just to write it again. Track migration by object or system counts and verify read-back. Exclude what cannot be migrated and assign an owner. After all dependent data is moved, retire access according to the service's recovery requirements rather than assuming a rotation event completed the work.
Monitor KMS authorization and key-use events alongside the data migration. Unexpected decrypt operations, grants, or changes to key policy can invalidate the assumption that only approved workloads use the key. Rotation is a lifecycle control. Re-encryption is a migration control. Treat them as separate steps with separate evidence.
Top comments (0)