Key Rotation

Key rotation replaces the cryptographic material used for new operations according to a defined schedule or security event. The interval during which a key is authorized for a particular use is its cryptoperiod. Engineers choose cryptoperiods based on data sensitivity, usage volume, algorithm requirements, regulatory obligations, and the consequences of compromise. Rotation is one lifecycle control; it does not replace access restrictions, secure key generation, monitoring, or incident response.

Cloud key management systems commonly separate a logical key resource from its underlying key material. Rotation can create a new material version while preserving the resource identifier, permissions, and application configuration. New encryption operations use the current version, while the service retains earlier versions for decrypting existing ciphertext. Alternatively, engineers can create a separate key resource and update application references. This approach requires explicit handling of permissions, dependencies, and rollback.

The distinction between provider-generated and imported material affects who performs the rotation and who is responsible for recovery. With provider-generated material, the key management service generates and protects the material within its managed security boundary. Eligible keys can use service-managed scheduled rotation. With imported material, an organization generates the material externally and imports it through a protected import process. The organization must manage external copies, provenance, backup, and any configured expiration. Importing material does not automatically give it the same rotation capabilities as a provider-generated key.

For AWS KMS, eligible symmetric encryption keys with AWS-generated material support automatic and on-demand rotation. Eligible symmetric encryption keys with imported material support on-demand rotation after new material has been imported; imported material does not support automatic rotation. Therefore, the blanket statement that imported KMS keys can never rotate is incorrect. Rotation support depends on the key's origin, type, and configuration. Where native rotation is unavailable, create a new KMS key and migrate consumers deliberately.

Rotation is different from reimporting an existing key. If imported material expires or is deleted, restoring access to ciphertext requires the matching original material, subject to the service's reimport requirements. Unrelated replacement material cannot decrypt ciphertext produced with the missing material. An expiration date is therefore an availability control with potentially destructive consequences, not a rotation schedule.

Envelope encryption makes another distinction important. An application encrypts data with a data key and protects that data key with a key-encryption key. Rotating the key-encryption key does not automatically rewrite existing ciphertext or replace every data key. For example, rotating a KMS key used by object storage changes the material used for subsequent applicable operations, but does not by itself re-encrypt every existing object. Rewrapping encrypted data keys or rewriting stored data is a separate migration, with service-specific support and costs.

A practical rollout identifies every consumer, verifies that new writes use the intended key version, and tests reads of older data and backups. Old material must remain available until retention and recovery requirements permit retirement. Moving an alias to a new key changes future lookups through that alias; it does not redirect ciphertext dependencies or clients using a fixed key identifier.

Rotation adds operational complexity, retained-version costs, and possible service disruption. After suspected compromise, simply rotating is insufficient: revoke unauthorized access, assess exposed data, and determine whether re-encryption or credential replacement is necessary. Previously copied ciphertext remains vulnerable if an attacker also obtained its corresponding key material.