Merge pull request #2767 from MicrosoftDocs/main

Auto Publish – main to live - 2026-04-21 22:10 UTC

Author: learn-build-service-prod[bot]

articles/key-vault/general/backup.md

@@ -7,7 +7,7 @@ ms.custom: devx-track-azurecli, devx-track-azurepowershell, sfi-image-nochange
 ms.service: azure-key-vault
 ms.subservice: general
 ms.topic: how-to
-ms.date: 04/10/2026
+ms.date: 04/20/2026
 ms.author: mbaldwin
 #Customer intent: As an Azure Key Vault administrator, I want to back up a secret, key, or certificate in my key vault.
 ---
@@ -54,6 +54,24 @@ Also consider the following issues:
 
 When you back up a key vault object, such as a secret, key, or certificate, the backup operation will download the object as an encrypted blob. This blob can't be decrypted outside of Azure. To get usable data from this blob, you must restore the blob into a key vault within the same Azure subscription and [Azure geography](https://azure.microsoft.com/global-infrastructure/geographies/).
 
+## Security considerations
+
+When you restore a key to a different vault, the restored copy is fully independent of the original. Disabling, deleting, or purging the original key has no effect on any restored copies. They remain fully functional in their respective vaults. There is no mechanism in Azure Key Vault to revoke or invalidate a previously created backup blob or a key that has already been restored to another vault.
+
+This independence has important implications for incident response. If you suspect a key has been compromised through unauthorized backup and restore, do not immediately disable or delete the key. Doing so takes all dependent services offline (for example, Azure SQL TDE databases become inaccessible, Azure Storage with customer-managed keys returns errors, and Azure Disk Encryption–protected VMs can't start) but does not affect any copies an attacker may have restored to another vault.
+
+Instead, follow this incident response sequence:
+
+1. **Contain the breach**: Immediately review and revoke any principals with backup or restore permissions on the compromised vault. Investigate Key Vault audit logs for unauthorized backup and restore activity to understand the scope of the compromise.
+1. **Create a replacement key** in a separate vault with tightly restricted access. Use a new key (not a new version of the compromised key) to ensure the replacement can't be obtained from existing backup blobs.
+1. **Reconfigure dependent services** to use the replacement key (each service re-wraps its data encryption keys with the new key).
+1. **Verify** that all dependent services are operating normally with the replacement key.
+1. **Disable the compromised key** only after dependent services are fully migrated. If purge protection is enabled on the vault, the key can't be permanently purged until the retention period expires, so leave it disabled until then.
+
+To reduce the risk of unauthorized backup exfiltration, restrict backup and restore permissions to only the identities that genuinely require them. Monitor your Key Vault audit logs for `KeyBackup`, `KeyRestore`, `SecretBackup`, `SecretRestore`, `CertificateBackup`, and `CertificateRestore` operations and alert on unexpected activity. For more information, see [Azure Key Vault logging](logging.md).
+
+For key-specific security best practices and key compromise response procedures, see [Secure your Azure Key Vault keys](../keys/secure-keys.md#key-compromise-response).
+
 ## Prerequisites
 
 To back up a key vault object, you must have: 

articles/key-vault/general/secure-key-vault.md

@@ -7,7 +7,7 @@ ms.service: azure-key-vault
 ms.subservice: general
 ms.custom: horz-security
 ms.topic: best-practice
-ms.date: 01/30/2026
+ms.date: 04/20/2026
 ms.author: mbaldwin
 ai-usage: ai-assisted
 #CustomerIntent: As a key vault administrator, I want to learn how to secure my key vaults
@@ -125,6 +125,8 @@ Regular backups ensure business continuity and protect against data loss from ac
 
 - **Test backup and recovery procedures**: To verify the effectiveness of backup processes, regularly test the restoration of Key Vault secrets, keys, and certificates. See [Azure Key Vault backup](backup.md).
 
+- **Understand backup copy independence**: A key restored from a backup to another vault is fully independent of the original. Disabling, deleting, or purging the original key does not affect any restored copies. Disabling or deleting the key also takes all dependent data services offline (for example, SQL TDE databases become inaccessible and Storage accounts with customer-managed keys return errors). If a key is suspected compromised, rotate to a new key and migrate dependent services before disabling the old one. For full details, see [Backup security considerations](backup.md#security-considerations) and [Key compromise response](../keys/secure-keys.md#key-compromise-response).
+
 ## Related security articles
 
 For security best practices specific to keys, secrets, and certificates, see:

articles/key-vault/keys/secure-keys.md

@@ -6,7 +6,7 @@ ms.service: azure-key-vault
 ms.subservice: keys
 ms.topic: best-practice
 ms.custom: horz-security
-ms.date: 04/10/2026
+ms.date: 04/21/2026
 ms.author: mbaldwin
 ai-usage: ai-assisted
 # Customer intent: As a developer using Key Vault keys, I want to implement key-specific security best practices.
@@ -60,8 +60,17 @@ Protect against data loss by implementing proper backup and recovery procedures:
 - **Enable soft delete**: Soft delete allows recovery of deleted keys within a retention period (7-90 days). See [Azure Key Vault soft-delete overview](../general/soft-delete-overview.md)
 - **Enable purge protection**: Prevent permanent deletion of keys during the retention period. See [Purge protection](../general/soft-delete-overview.md#purge-protection)
 - **Back up critical keys**: Export and securely store backups of keys that protect irreplaceable data. See [Azure Key Vault backup](../general/backup.md)
+- **Restrict backup permissions**: Grant the `backup` key operation only to identities that genuinely need it. A backed-up key that is restored to another vault becomes fully independent of the original. See [Backup security considerations](../general/backup.md#security-considerations) for details.
 - **Document recovery procedures**: Maintain runbooks for key recovery scenarios
 
+## Key compromise response
+
+If you suspect a key has been compromised (for example, through unauthorized backup and restore to another vault), do not immediately disable or delete the key. A restored copy is fully independent of the source vault, so disabling, deleting, or purging the original does not invalidate any restored copies. At the same time, disabling or deleting the key takes all dependent services offline (Azure SQL TDE, Azure Storage SSE, Azure Disk Encryption, and others).
+
+Instead, contain the breach, rotate to a new key in a clean vault, migrate all dependent services, and only then disable the compromised key. For the full step-by-step incident response procedure, see [Backup security considerations](../general/backup.md#security-considerations). For key rotation procedures, see [Configure cryptographic key autorotation in Azure Key Vault](how-to-configure-key-rotation.md).
+
+To detect unauthorized key exfiltration early, monitor Key Vault audit logs for `KeyBackup` and `KeyRestore` operations and alert on unexpected activity. For more information, see [Azure Key Vault logging](../general/logging.md).
+
 ## Bring Your Own Key (BYOK)
 
 When importing your own keys into Key Vault, follow security best practices: