A key-dependency guide for encrypted backups. AWS Backup, KMS, and Azure Key Vault documentation explain distinct encryption paths, deletion states, recovery windows, and the evidence needed to keep retained ciphertext usable.
At a glance
Key findings
- A retained encrypted copy remains dependent on the keys and permissions required by its actual backup and restore path.
- Canceling scheduled AWS KMS key deletion leaves the key disabled; re-enabling it is a separate operation.
- AWS KMS deletion waiting periods and Azure Key Vault soft-delete retention protect different lifecycle stages and should not be compared as equivalent recovery guarantees.
Follow the ciphertext to its required key
A backup can survive deletion attempts and still be impossible to restore if its encryption key is unavailable. That dependency is easy to overlook when the backup service displays a healthy recovery point. The storage record answers whether a copy exists. A recovery design must also answer which key can decrypt that copy and which identity may use it.
AWS Backup documents different encryption behavior for resources fully managed by the service and resources whose backups depend on the source service's encryption. Copy behavior also depends on the resource and destination. A vault's configured key should therefore not be assumed to describe every recovery point's complete key dependency. [1]
Build the inventory from an actual recovery point. Record the source resource, backup type, copy destination, relevant key identifiers, and restore role. Then trace the documented path for that combination. If a key alias appears in the record, preserve the underlying identifier used by the protected data as well. A familiar display name is not enough evidence that a replacement key can recover older ciphertext.
Preserved ciphertext still needs usable authority
Trace the copy, key state, restore permissions, and application result as one recovery chain.
Source. AWS Backup encryption, AWS KMS lifecycle, and Azure Key Vault documentation [1]-[4].
Method. Original dependency flow. The separate lifecycle table preserves provider-specific meanings; neither the flow nor the documented windows are measured recovery performance.
Accessible table and figure data
| Recovery condition | Evidence to inspect | Failure that remains possible |
|---|---|---|
| Copy retained | Recovery-point identity and protection | Required key no longer exists |
| Correct key identified | Resource-specific encryption path | Alias or destination setting describes a different key |
| Key usable | Actual lifecycle state | Canceled deletion leaves a disabled key |
| Role authorized | Restore and key permissions | A surviving key rejects the recovery identity |
| Resource restored | Backup-service result | Application dependencies remain unavailable |
| Application accepted | Scoped business checks | An untested resource type has a different key path |
| Recovery condition | Evidence to inspect | Failure that remains possible |
|---|---|---|
| Copy retained | Recovery-point identity and protection | Required key no longer exists |
| Correct key identified | Resource-specific encryption path | Alias or destination setting describes a different key |
| Key usable | Actual lifecycle state | Canceled deletion leaves a disabled key |
| Role authorized | Restore and key permissions | A surviving key rejects the recovery identity |
| Resource restored | Backup-service result | Application dependencies remain unavailable |
| Application accepted | Scoped business checks | An untested resource type has a different key path |
Separate unavailable from permanently destroyed
For AWS KMS, scheduled key deletion introduces a waiting period of 7 to 30 days. A key pending deletion cannot perform cryptographic operations. Canceling that deletion does not return it directly to service: the cancellation API leaves it disabled, and enabling it is a separate action. The states matter when diagnosing a failed restore. [2][3]
Keep those distinctions in the recovery runbook. An authorization denial, a disabled key, a key pending deletion, and a permanently deleted key require different decisions. Repeatedly retrying the restore job will not resolve a missing prerequisite. The operator needs permission to inspect the state and a clear escalation path to the people authorized to change it.
The AWS deletion guidance explains that deleting a symmetric KMS key makes its protected ciphertext unrecoverable through that key, including cases where the same imported key material is later placed in a new KMS key. [2] Do not use a key name or a saved material file as a substitute for understanding the service's key metadata and lifecycle. Plan retention and retirement around the actual encrypted copies that must remain usable.
Compare lifecycle controls without equating them
Azure Key Vault soft delete uses a configured retention period from 7 to 90 days, with 90 days as the default. Purge protection is a separate, optional control that prevents early permanent purging during that period. Its documentation describes a different lifecycle from AWS KMS scheduled deletion, so the two ranges are not a direct ranking of recoverability. [4]
The useful comparison is which event starts the window, what remains recoverable, who can reverse the operation, and which action is blocked. A chart containing only the maximum number of days would hide those differences. It could encourage a reader to choose the larger number without checking whether the feature was enabled or whether the protected object is the one their application needs.
Review the configured behavior for each deployed service. Distinguish defaults for new resources from settings observed on an existing resource. Record irreversible choices and the operational procedure for recovery before an incident. Product documentation can establish the available mechanism, but only the deployment's configuration and a suitable exercise can establish how that mechanism applies to the organization's encrypted data.
| Mechanism | Documented window | What must happen for recovery |
|---|---|---|
| AWS KMS scheduled key deletion | 7 to 30 days | Cancel before deletion; the key then remains disabled until separately enabled |
| Azure Key Vault soft-delete retention | 7 to 90 days; default 90 | Recover the soft-deleted object within retention; purge protection is a separate setting |
Separate key administration from routine restore access
The people who restore a workload should have the permissions required for that approved operation, but that does not imply they need unrestricted authority to retire keys or alter every key policy. Map the operational roles separately: backup creation, restoration, key administration, account administration, and approval of irreversible lifecycle changes.
Examine indirect dependencies in that map. A recovery role may rely on a policy or grant maintained in a different account, or on an identity path that is unavailable in the selected incident scenario. Record who owns each permission and how it is verified. The point is to discover shared authority and inaccessible prerequisites before they become emergency troubleshooting problems.
Treat a proposed key retirement as a data-impact review. Identify every retained recovery point and application path that still needs the key, including older copies that are no longer part of the ordinary daily restore test. Document the disposition of those copies before approving destruction. A rotation or a newly configured destination key does not by itself prove that all historical encrypted artifacts have moved to the new dependency.
Exercise the dependency with disposable data
Use an authorized test environment and disposable encrypted data to validate the runbook. First demonstrate a normal restore under the intended recovery role. Then exercise a reversible failure appropriate to the service and confirm that the diagnostic evidence identifies the key dependency. Avoid scheduling deletion of production keys merely to make a test look realistic.
If an approved exercise covers a recoverable lifecycle state, record each transition and the separate permissions required to return to a usable state. For the AWS cancellation path, the acceptance check should not stop at a successful cancellation response; it must also establish that the key is enabled and the selected test ciphertext can be used through the intended workflow. [3]
Keep the fixture small enough to repeat and realistic enough to cover the actual backup type. A direct encryption test can verify a key operation while leaving the backup service's restore permissions untested. Conversely, a successful restore of one resource type may not cover another resource's encryption model. Label the scope of each result so the evidence remains useful without becoming broader than the exercise.
Make keys part of the recovery record
Add a key-dependency section to the backup inventory. It should connect the recovery point to its required key state, owning account, authorized restore role, lifecycle controls, and most recent relevant exercise. Protect the record as operationally sensitive information, but keep it reachable by the recovery team when the primary application is unavailable.
Use change review to keep that record current. A new backup destination, a resource migration, a key-policy edit, or a different restore role can alter the dependency without changing the apparent success of the scheduled backup job. Ask whether the latest evidence still covers the new combination and assign any missing test to an owner.
The resulting recovery claim should include both retained data and usable cryptographic authority. A lock can preserve ciphertext, and a lifecycle control can create an opportunity to recover a key, but neither alone establishes a working service. Keeping those conditions separate gives an incident operator a clear diagnostic path and gives reviewers a concrete reason to reject premature key retirement.
Method and provenance
Primary documentation review completed August 28, 2026, with an original key-dependency map and provider-specific lifecycle comparison.
No keys were disabled, scheduled for deletion, canceled, enabled, or used in a restore test. The review does not establish the key dependencies or permissions of a customer deployment.
AI assistance. AI assistance was used to research sources, draft and structure the article, and prepare the visual specification. No human technical review is claimed.
Published under the Cloud Security Desk organizational byline. Read the series policy.
References
- Encryption for backups in AWS Backup AWS. Accessed .
- Deleting AWS KMS keys AWS. Accessed .
- AWS KMS CancelKeyDeletion API AWS. Accessed .
- Azure Key Vault soft-delete overview, updated April 10, 2026 Microsoft. Accessed .