Deduplicate key compromise steps: summarize and link to backup.md

secure-keys.md duplicated the 5-step incident response sequence from
backup.md. Replace with a summary paragraph that links to the canonical
procedure in backup.md#security-considerations.

Co-authored-by: Copilot <[email protected]>

Author: msmbaldwin

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/20/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.
@@ -65,15 +65,9 @@ Protect against data loss by implementing proper backup and recovery procedures:
 
 ## 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).
+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).
 
-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.
+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).