Merge pull request #2765 from msmbaldwin/msrc-113198-backup-restore-warning

Add key backup/restore security warnings for incident response [MSRC 113198]

Author: prmerger-automator[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/20/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,23 @@ 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 of a key is fully independent of the source vault: disabling, deleting, or purging the original key does not invalidate any restored copies. Meanwhile, disabling or deleting the key immediately takes all dependent services offline (Azure SQL TDE, Azure Storage SSE, Azure Disk Encryption, and others). For full details on backup copy independence, see [Backup security considerations](../general/backup.md#security-considerations).
+
+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.
+1. **Create a replacement key**: Create a new key (not a new version of the compromised key) in a separate vault with tightly restricted access.
+1. **Re-wrap data encryption keys**: Reconfigure all dependent services to use the replacement key. Each service re-wraps its data encryption keys with the new key. See [Configure cryptographic key autorotation in Azure Key Vault](how-to-configure-key-rotation.md) for rotation procedures.
+1. **Verify service health**: Confirm that all dependent services are operating normally with the replacement key.
+1. **Disable the compromised key**: Only after all services have migrated, disable the old key. If purge protection is enabled, the key can't be permanently purged until the retention period expires, so leave it disabled until then.
+
+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: