Rotation and retirement solve different problems
A cryptographic key can have multiple versions. Rotation changes which version is used for subsequent encryption in the applicable design; it is not the same as re-encrypting every existing record or retiring every older version. A business must still be able to read retained data and recover backups created before the change.
Google explicitly documents that rotating a key does not automatically re-encrypt existing data or disable older versions. Build the operating plan around the data's lifecycle. A successful encryption test with the new version says nothing about whether an old archive remains recoverable.
Prepare an inventory before the change
- Identify applications, storage systems and backups that depend on the key. Record ownership and the distinction between key administration and cryptographic use.
- Collect non-sensitive ciphertext fixtures representing both current and older retained data. Keep their expected plaintext in a protected test fixture, not in an incident ticket.
- Define how applications choose a key version, how encryption metadata is stored and how recovery obtains the required permissions. Rehearse a restore outside production.
Managed services using customer-managed encryption can have additional lifecycle behavior. Review their own service guidance as well as KMS documentation before deciding what a rotation changes for that resource.
Illustrative incident: new writes work, an archive fails
A team rotates its application key and immediately disables an older version because a new encryption test passes. The application later tries to decrypt a retained archive created with that version and fails. This is an illustrative scenario. Repeatedly encrypting new test values cannot demonstrate that the archive's dependency has disappeared.
Diagnose with key and data identifiers
Inspect the failing operation, relevant key version and authorization context. Distinguish a disabled version from a permission denial and from corrupted or mismatched ciphertext. Avoid exposing decrypted customer content merely to prove that a cryptographic operation ran.
| Observation | Evidence | Decision boundary |
|---|---|---|
| Old fixture fails, new fixture succeeds | Version and state used by each | Historical dependency |
| Every cryptographic call is denied | Calling principal and key permissions | Access policy |
| Only one record fails | Ciphertext provenance and stored metadata | Data integrity or reference |
| Restore fails in a separate project | Recovery identity and key reachability | Disaster recovery design |
Retain the exact error and a fixture identifier. Do not alter ciphertext while investigating; otherwise the original failure evidence can be lost. Coordinate application and security teams before selecting a corrective action.
Validate rotation before considering retirement
For the illustrative incident, the responsible key owner should review whether the older version remains required and use the supported recovery process where available. Restoring access and choosing a later retirement date are separate decisions. Permanent key destruction must never be a routine side effect of a rotation script.
Verify new encryption, old-fixture decryption and an isolated backup restore through their real identities. If re-encryption is part of the plan, inventory completion and unresolved records explicitly. Account for retained backups and infrequently read archives before concluding that an older version has no consumers.
Acceptance, monitoring and SOP
Track cryptographic failures by application and version, without logging secret material. An illustrative internal objective could require all retained-data classes to pass a recovery fixture before a key retirement is approved. It is not a provider SLA or a guarantee that a destroyed key can be recovered.
The SOP should name the data owner, key owner, retention obligations, tested fixtures, change record and reversal boundary. Escalate uncertain historical dependencies rather than using the age of a version as the sole retirement criterion. Include the recovery team in reviews so a normal application success does not conceal a broken disaster-recovery path.
Clouvenix can scope related engineering support around documented ownership, change approval and acceptance evidence.
Technical reference
Google Cloud: key rotation and rotate a key. References reviewed 19 October 2026; confirm the configuration and supported behavior for your deployed environment.