12.2 Key Vault Backup, Recovery & Automated Key Rotation
Key Takeaways
- A Key Vault object backup can only be restored into a vault in the same Azure subscription and the same Azure geography.
- Backing up a key, secret, or certificate captures every version of that object as a single encrypted, opaque blob.
- Soft delete is mandatory on Key Vault with a retention window of 7 to 90 days; purge protection makes purging impossible until that window elapses and cannot be turned off.
- Key rotation policies rotate keys automatically based on time after creation or time before expiry, and emit Event Grid notifications.
- Managed HSM protects its own restore path with a security domain that requires a quorum of key holders.
Why Key Recoverability Is a Security Control
If a customer-managed key protecting a storage account, a disk encryption set, or a SQL database with transparent data encryption is deleted, the data becomes permanently unreadable. Deleting a key is therefore a destructive action equivalent to destroying the data, which is why Azure makes deletion recoverable by design and why the AZ-500 objective explicitly names "perform backup and recovery of certificates, secrets, and keys".
Object Backup and the Geography Restriction
Azure Key Vault (standard and premium) provides per-object backup:
az keyvault key backup --vault-name kv-prod --name cmk-storage --file cmk-storage.backup
az keyvault secret backup --vault-name kv-prod --name sql-conn --file sql-conn.backup
az keyvault certificate backup --vault-name kv-prod --name tls-cert --file tls-cert.backup
Properties that get tested:
- The backup blob is encrypted and opaque. You cannot read it, parse it, or extract the key material — it is only meaningful to the Key Vault service.
- A backup captures all versions of the object, not just the current one.
- Restore is limited to a vault in the same Azure subscription and the same Azure geography (for example, a backup from a vault in North Europe can be restored into West Europe, but not into a US or Asian geography). This is a deliberate data-residency and security boundary, and it means a Key Vault backup is not a cross-region disaster recovery mechanism on its own.
- There is no supported "back up the whole vault in one call" for standard Key Vault — you enumerate objects and back each one up. Managed HSM, by contrast, supports full backup and restore of the entire HSM.
- Performing a backup requires the
backupdata-plane permission (access policy model) or a role that includes it, such as Key Vault Contributor combined with the relevant data role, in the RBAC model.
Because of the geography limit, treat object backup as protection against accidental deletion and vault corruption, and treat multi-region key management (separate vaults per region, with keys created independently and referenced by regional resources) as the real availability design.
Soft Delete and Purge Protection
| Feature | Status | Behaviour |
|---|---|---|
| Soft delete | Always on; cannot be disabled | Deleted vaults and objects are retained for the configured retention period of 7–90 days (90 is the default) and can be recovered |
| Purge protection | Optional, irreversible once enabled | Blocks permanent purge of a deleted vault or object until the retention period expires — even for a Global Administrator |
Recovery commands:
az keyvault recover --name kv-prod # recover a deleted vault
az keyvault key recover --vault-name kv-prod --name cmk-storage
Purge protection is a prerequisite for several services that rely on customer-managed keys, including Azure Storage CMK configurations and disk encryption sets, precisely because those services cannot tolerate an unrecoverable key deletion. Recovering a deleted object requires the recover permission; purging requires purge, which should be granted to almost nobody.
Note the interaction with role separation: the ability to purge is the ability to destroy data irrecoverably, so it belongs in a PIM-eligible role, not in a standing assignment.
Automated Key Rotation
Keys support a rotation policy so the vault generates a new key version on schedule with no orchestration code:
| Policy element | Meaning |
|---|---|
| Expiry time | The lifetime assigned to each newly created key version |
| Rotate: time after create | Rotate N days after the current version was created |
| Rotate: time before expiry | Rotate N days before the current version expires |
| Notify: time before expiry | Emit an Event Grid KeyNearExpiry event N days before expiry |
Configuring the policy requires Key Vault Crypto Officer (or the rotate and setrotationpolicy permissions). Azure services that reference a key without pinning a version — such as storage account CMK configured for automatic key version rotation, or a disk encryption set with auto-rotation — pick up the new version automatically. Services pinned to a specific key version keep using the old one, which is the usual reason "rotation happened but nothing changed".
Secrets do not rotate themselves. The pattern is Event Grid SecretNearExpiry → Azure Function or Automation runbook that changes the credential at the source system and writes the new value as a new secret version.
Certificates managed by Key Vault with an integrated certificate authority (DigiCert or GlobalSign) auto-renew via a lifetime action configured either as a percentage of lifetime elapsed or a number of days before expiry. Non-integrated certificates emit the same notification events for a manual or automated process to act on.
Managed HSM Considerations
Managed HSM raises both the assurance level and the recovery complexity:
- FIPS 140-2 Level 3 validated, single-tenant HSM pools.
- Security domain: during activation you upload 3–10 RSA public keys and set a quorum. The security domain blob returned is encrypted to those keys, and without a quorum of the corresponding private keys the HSM cannot be recovered or restored — Microsoft cannot recover it for you. Losing the security domain means losing every key in the pool.
- Supports full backup and restore of the entire HSM, plus selective key restore.
- Uses a local RBAC model (Managed HSM Administrator, Crypto Officer, Crypto User) that is separate from Azure RBAC, so subscription Owner does not imply HSM data access — a deliberate separation of duties that appears in exam scenarios about limiting cloud administrators.
A disaster recovery plan calls for backing up keys from a Key Vault in the North Europe region and restoring them into a vault in the East US region. Why will this fail?
An organization must guarantee that no administrator — including a Global Administrator — can permanently destroy a deleted customer-managed key before the retention period elapses. Which configuration achieves this?
A storage account uses a customer-managed key from Key Vault, and a rotation policy generates a new key version every 90 days. After rotation, the storage account continues to use the old key version. What is the cause?