Encryption key management becomes an application problem the moment an old record still needs a key that a deployment no longer uses. A successful rotation today says little about whether an archive can be restored next year. Teams need to know which key protects each dataset, who can use it and what must survive a migration.
AWS KMS provides a useful concrete example of these boundaries. Its documentation distinguishes the managed key resource, the cryptographic material behind it and the data keys an application uses. The operational checklist below draws on those distinctions; it is not a claim that every key service behaves identically.
Separate the key resource from the data key
In AWS KMS, a key ID or ARN identifies a logical resource. That identifier is not the secret cryptographic material. An alias can point to different key resources over time, which makes it convenient for selecting a current key but insufficient as the only historical reference.
A data key has a different job. AWS’s data-key documentation describes returning a plaintext key for immediate use and an encrypted copy for storage alongside the encrypted data. The application performs encryption outside KMS and should remove the plaintext key from memory promptly. KMS does not keep an inventory of those application data keys.
For a hypothetical invoice archive, that suggests a concrete record: encrypted invoice, encrypted data key, encryption format and the key reference needed to recover it. Store enough information to interpret the ciphertext after the original application has changed.
Make ownership visible before changing policy
A practical inventory should name the dataset, environment, key reference, responsible team and recovery dependency. Include backups, exported files and delayed jobs. These are design recommendations rather than fields a provider automatically maintains for you.
Ask two questions separately: who may use the key to process application data, and who may change its lifecycle or permissions? Review the actual service policies for both. A process that can deploy software should not acquire deletion authority merely because nobody assigned a separate owner.
Also identify the management model. AWS distinguishes customer-managed, AWS-managed and AWS-owned keys, with different control and audit options. Verify the encryption documentation for each integrated service rather than assuming that every encrypted resource exposes the same controls.
Rotation does not rewrite the archive
AWS states that KMS key rotation changes the material used for new encryption while retaining the material needed to decrypt older ciphertext. The logical key remains the same.
That mechanism does not rotate application data keys, re-encrypt stored data or repair exposure of a compromised data key. Those require a separate response. Record whether a proposed change means rotating material behind an existing key, selecting a different key resource, rewrapping data keys or re-encrypting the underlying records.
This differs from rotating service credentials. An API credential grants access to a service; an encryption key may remain necessary for data created long before that credential existed.
Treat deletion as a data migration decision
AWS’s deletion guide warns that deleting a key can make protected data unrecoverable. Customer-managed key deletion has a mandatory waiting period of 7–30 days, with 30 days as the default. A key pending deletion cannot perform cryptographic operations.
A quiet monitoring dashboard is therefore weak evidence that deletion is safe. An annual restore or an infrequently accessed archive may not appear during a short observation period. Before retiring a key, list the retained datasets and demonstrate recovery from representative older material in an authorised test environment.
Our data retention guide follows copies across connected systems. Apply the same discipline here: a key’s retirement plan must account for every retained copy that depends on it.
A review record a small team can maintain
| Decision | Evidence to retain |
|---|---|
| Select a current key | Resource identifier, environment and owner |
| Rotate material | Provider operation and confirmed result |
| Move to a new key | Migration coverage and an old-data recovery test |
| Restrict access | Reviewed application and administrative permissions |
| Retire a key | Retention inventory, recovery evidence and approval |
Use the table as a change record. A test should establish that old data remains readable where required, new data uses the intended key and an unauthorised identity cannot decrypt it. Avoid copying plaintext keys, customer data or credentials into that evidence.
Reporting & Sources
Documentation reviewed October 21, 2026: AWS KMS concepts, data keys, rotation and deletion. The archive example and review checklist are editorial synthesis. No deployment, recovery exercise or hands-on test is claimed.
