Before you can reliably back up and restore Azure Key Vault objects, you must first protect the vault itself against accidental or malicious deletion. Soft-delete places deleted certificates, secrets, and keys into a soft-deleted state where they are retained for a configurable retention period, typically 90 days, and can be recovered. Purge protection prevents anyone from permanently deleting the vault or its objects until that retention period expires, even if they have delete permissions. You enable both settings using the Azure CLI command az keyvault update with the --enable-soft-delete true and --enable-purge-protection true flags, or the PowerShell cmdlets Enable-AzKeyVaultSoftDelete and Enable-AzKeyVaultPurgeProtection. These settings create a safety net: an administrator cannot accidentally or maliciously remove the vault and its contents permanently, giving the recovery process a guaranteed window to act.
Manual backup operations create point-in-time snapshots of individual certificates, secrets, or keys that you can store in a secure location. Use the az keyvault backup command in the Azure CLI or the Backup-AzKeyVaultKey and Backup-AzKeyVaultSecret PowerShell cmdlets to export each object. Before running these commands, the vault's managed identity or the user account must have Get, Backup, and Restore permissions assigned through either Azure RBAC or the vault's access policies. The backup command produces an encrypted file or folder that contains the object's value, metadata, and version history. To restore, use az keyvault restore or the Restore-AzKeyVaultKey and Restore-AzKeyVaultSecret cmdlets, pointing to the backup file's path. The restore operation creates the object in the target vault with its original attributes, but it does not overwrite an existing object of the same name; you must delete or rename the existing object first.
Manual backups are useful for ad-hoc needs, but a consistent backup schedule is essential for meeting compliance and governance requirements. You can automate backups by deploying an ARM template that defines a recurring schedule and the resources needed to execute it. The template typically includes a backup policy with frequency and retention settings, a system-assigned managed identity that the backup runner uses to authenticate to the vault, and an encrypted storage location that uses a customer-managed key (CMK) for at-rest protection. Alternatively, you can author an Azure Automation runbook that runs Azure CLI or PowerShell backup commands at defined intervals, such as daily or weekly. The runbook can include error handling and logging so that you are alerted if a backup fails. This automation ensures that backups occur consistently without relying on manual intervention, and it aligns the backup cadence with organizational compliance requirements.
A cross-region restore verifies that your backup strategy can survive a regional outage and that your data remains intact across geographies. The process begins by deploying a new Key Vault in the target region using an ARM template. After the vault is created, you run the restore operation against the backup files that were stored in a secure, accessible location. Once the restore completes, you must reapply all of the vault's configuration settings in the new region, including access policies, private endpoints, encryption settings, and the soft-delete and purge protection flags. This step is critical because the backup file contains only the vault objects, not the vault's configuration. After reconfiguring the vault, you perform a test retrieval of secrets and certificates to confirm that the restored objects are functional and that the new vault is properly secured. A successful cross-region restore demonstrates that your backup artifacts can be recovered in a different geography under a separate resource group, satisfying disaster recovery and data residency requirements.
A process flow showing the steps to recover Azure Key Vault objects in a secondary region, from deploying a new vault and restoring backups to reconfiguring settings and validating functionality.
Validation confirms that the restore operation produced the correct results and that the restored objects are usable. After the restore completes, run Get-AzKeyVaultSecret or Get-AzKeyVaultKey against the new vault to inspect the object's version, tags, and attributes, ensuring they match the original. Monitor the restore process through Azure Monitor and review the audit logs for any errors or warnings. Perform a test retrieval of a secret or certificate by reading its value and verifying that it decrypts or authenticates correctly in a test application. These checks guarantee that the backup and restore process supports operational continuity and meets governance policy objectives, and they provide documented evidence that your recovery plan works as intended.
Are you a guardian of your domain? Lean how to leverage your aptitude in security to protect Microsoft Azure technologies, with a goal of earning the Microsoft Certified: Azure Security Engineer Associate certification!
Prepare and test your skills

Prepare and test your skills

Soft-delete places deleted certificates, secrets, and keys into a soft-deleted state where they are retained for a configurable retention period, typically 90 days, and can be recovered. When combined with purge protection, it prevents anyone from permanently deleting the vault or its objects until the retention period expires, even if they have delete permissions.
The vault's managed identity or the user account must have Get, Backup, and Restore permissions assigned through either Azure RBAC or the vault's access policies before running backup commands.
The restore operation creates the object in the target vault with its original attributes, but it does not overwrite an existing object of the same name; you must delete or rename the existing object first.
The backup file contains only the vault objects, not the vault's configuration, so you must manually reapply all settings in the new region including access policies, private endpoints, encryption settings, and the soft-delete and purge protection flags.