Align Key Vault/MHSM articles with authoritative CMK Q&A guidance

- Add rotation != re-encryption clarification to key rotation article
- Fix FIPS version ambiguity in about-keys-details (140 -> 140-3/140-2)
- Fix misleading 'fully managed by Microsoft' in mhsm-control-data
- Reframe CMK as control model in mhsm-control-data
- Strengthen security domain irrecoverability warning
- Add FIPS 140-3 Level 3 to security-domain.md
- Make single-region-only limitation explicit in multi-region-replication

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

Author: msmbaldwin

articles/key-vault/keys/about-keys-details.md

@@ -7,7 +7,7 @@ author: msmbaldwin
 ms.service: azure-key-vault
 ms.subservice: keys
 ms.topic: concept-article
-ms.date: 03/06/2026
+ms.date: 04/02/2026
 ms.author: mbaldwin
 ---
 
@@ -139,10 +139,10 @@ The following read-only attributes are included in any response that includes ke
 - *created*: IntDate, optional. The *created* attribute indicates when this version of the key was created. The value is null for keys created before the addition of this attribute. Its value MUST be a number containing an IntDate value.  
 - *updated*: IntDate, optional. The *updated* attribute indicates when this version of the key was updated. The value is null for keys that were last updated before the addition of this attribute. Its value MUST be a number containing an IntDate value.
 - *hsmPlatform*: string, optional. The underlying HSM platform that protects a key.
-    - A `hsmPlatform` value of `2` means the key is protected by the latest FIPS 140 Level 3 validated HSM platform.
-    - A `hsmPlatform` value of `1` means the key is protected by the previous FIPS 140 Level 2 validated HSM platform.
-    - A `hsmPlatform` value of `0` means the key is protected by a FIPS 140 Level 1 software cryptographic module.
-    - If you don't set this value by using a Managed HSM pool, the key is protected by the latest FIPS 140 Level 3 validated HSM platform.
+    - A `hsmPlatform` value of `2` means the key is protected by the latest FIPS 140-3 Level 3 validated HSM platform.
+    - A `hsmPlatform` value of `1` means the key is protected by the previous FIPS 140-2 Level 2 validated HSM platform.
+    - A `hsmPlatform` value of `0` means the key is protected by a FIPS 140-2 Level 1 software cryptographic module.
+    - If you don't set this value by using a Managed HSM pool, the key is protected by the latest FIPS 140-3 Level 3 validated HSM platform.
 
 Keys are bound to the HSM in which you created them. You create and store new keys seamlessly in the new HSMs. While you can't migrate or transfer keys, new key versions are automatically in the new HSMs. For more information about how to migrate to a new key, see [How to migrate key workloads](../general/migrate-key-workloads.md).
 

articles/key-vault/keys/how-to-configure-key-rotation.md

@@ -8,7 +8,7 @@ ms.custom: devx-track-arm-template, sfi-image-nochange, copilot-scenario-highlig
 ms.service: azure-key-vault
 ms.subservice: keys
 ms.topic: how-to
-ms.date: 01/30/2026
+ms.date: 04/02/2026
 ms.author: mbaldwin
 ---
 
@@ -59,7 +59,9 @@ Key rotation policy settings:
 -   Notification time: key near expiry event interval for Event Grid notification. It requires 'Expiry Time' set on rotation policy and 'Expiration Date' set on the key. 
 
 > [!IMPORTANT]
-> Key rotation generates a new key version of an existing key with new key material. Target services should use versionless key URI to automatically refresh to the latest version of the key. Ensure that your data encryption solution stores versioned key URI with data to point to the same key material for decrypt/unwrap as was used for encrypt/wrap operations to avoid disruption to your services. All Azure services currently follow that pattern for data encryption.
+> Key rotation generates a new key version of an existing key with new key material. Target services should use versionless key URI to automatically refresh to the latest version of the key. Ensure that your data encryption solution stores versioned key URI with data to point to the same key material for decrypt/unwrap operations to avoid disruption to your services. All Azure services currently follow that pattern for data encryption.
+>
+> Key rotation re-wraps data encryption keys (DEKs) with the new key version — it does not re-encrypt the underlying data. Both old and new key versions must remain enabled until re-wrapping is complete, because existing data remains encrypted under DEKs wrapped by the old key version.
 
 :::image type="content" source="../media/keys/key-rotation/key-rotation-1.png" alt-text="Rotation policy configuration":::
 

articles/key-vault/managed-hsm/mhsm-control-data.md

@@ -6,7 +6,7 @@ ms.subservice: managed-hsm
 ms.topic: concept-article
 author: nkondamudi
 ms.author: nkondamudi
-ms.date: 01/08/2026
+ms.date: 04/02/2026
 ---
 
 # Control your data in the cloud by using Managed HSM
@@ -28,10 +28,10 @@ Azure Key Vault services provide encryption and key management solutions that sa
 Secure key management is essential to protect and control data in the cloud. Azure offers various solutions that you can use to manage and control access to encryption keys so that you have choice and flexibility to meet stringent data protection and compliance needs.
 
 - **Azure platform encryption** is a *platform-managed* encryption solution that encrypts by using host-level encryption. Platform-managed keys are encryption keys that are generated, stored, and managed entirely by Azure.
-- **Customer-managed keys** are keys that are created, read, deleted, updated, and administered entirely by the customer. Customer-managed keys can be stored in a cloud key management service like Azure Key Vault.
+- **Customer-managed keys (CMK)** is a key management control model in which the customer creates, rotates, and manages the key encryption key (KEK) lifecycle. Azure services use these customer-owned keys to wrap and unwrap their data encryption keys. Customer-managed keys can be stored in Azure Key Vault or Azure Managed HSM.
 - **Azure Key Vault Standard** encrypts by using a software key and is FIPS 140-2 Level 1 compliant.
 - **Azure Key Vault Premium** encrypts by using keys protected by [FIPS 140 validated HSMs](/azure/key-vault/keys/about-keys#compliance).
-- **Azure Key Vault Managed HSM** encrypts by using single-tenant FIPS 140-3 Level 3 HSM protected keys and is fully managed by Microsoft.
+- **Azure Key Vault Managed HSM** is a fully managed service that encrypts by using single-tenant, customer-controlled, FIPS 140-3 Level 3 HSM-protected keys.
 
 For added assurance, in Azure Key Vault Premium and Azure Key Vault Managed HSM, you can [bring your own key (BYOK)](../keys/hsm-protected-keys-byok.md) and import HSM-protected keys from an on-premises HSM.
 

articles/key-vault/managed-hsm/multi-region-replication.md

@@ -6,14 +6,14 @@ author: msmbaldwin
 ms.service: azure-key-vault
 ms.subservice: managed-hsm
 ms.topic: tutorial
-ms.date: 03/10/2026
+ms.date: 04/02/2026
 
 ms.author: nkondamudi
 ms.custom: references_regions
 ---
 # Enable multi-region replication on Azure Managed HSM
 
-Multi-region replication allows you to extend a managed HSM pool from one Azure region (called the primary region) to another Azure region (called an extended region). Once configured, both regions are active, able to serve requests and, with automated replication, share the same key material, roles, and permissions. The closest available region to the application receives and fulfills the request, maximizing read throughput and latency. While regional outages are rare, multi-region replication enhances the availability of mission critical cryptographic keys should one region become unavailable. When multi-region replication is enabled, the SLA for the primary and extension pools combined increases to 99.99. For more information on SLA, visit [SLA for Azure Key Vault Managed HSM](https://azure.microsoft.com/support/legal/sla/key-vault-managed-hsm/v1_0/).
+Multi-region replication allows you to extend a managed HSM pool from one Azure region (called the primary region) to one additional Azure region (called an extended region). Extension is supported to a single additional region only. Once configured, both regions are active, able to serve requests and, with automated replication, share the same key material, roles, and permissions. The closest available region to the application receives and fulfills the request, maximizing read throughput and latency. While regional outages are rare, multi-region replication enhances the availability of mission critical cryptographic keys should one region become unavailable. When multi-region replication is enabled, the SLA for the primary and extension pools combined increases to 99.99. For more information on SLA, visit [SLA for Azure Key Vault Managed HSM](https://azure.microsoft.com/support/legal/sla/key-vault-managed-hsm/v1_0/).
 
 ## Architecture
 

articles/key-vault/managed-hsm/security-domain.md

@@ -6,13 +6,13 @@ ms.subservice: managed-hsm
 ms.topic: concept-article
 author: msmbaldwin
 ms.author: mbaldwin
-ms.date: 04/14/2025
+ms.date: 04/02/2026
 
 ---
 
 # Security domain in Managed HSM overview
 
-A managed HSM is a single-tenant, [Federal Information Processing Standards (FIPS) 140-3 validated](https://csrc.nist.gov/publications/detail/fips/140/3/final), highly available, hardware security module (HSM) that has a customer-controlled security domain.  
+A managed HSM is a single-tenant, [Federal Information Processing Standards (FIPS) 140-3 Level 3 validated](https://csrc.nist.gov/publications/detail/fips/140/3/final), highly available, hardware security module (HSM) that has a customer-controlled security domain.  
 
 To operate, a managed HSM must have a security domain. The security domain is an encrypted blob file that contains artifacts like the HSM backup, user credentials, the signing key, and the data encryption key that's unique to the managed HSM.
 
@@ -26,7 +26,7 @@ A managed HSM security domain serves the following purposes:
   - The managed HSM instance was soft-deleted by a customer and the resource was purged after the mandatory retention period expired.
   - The customer archived a project by performing a backup that included the managed HSM instance and all data, and then deleted all Azure resources that were associated with the project.
 
-Without the security domain, disaster recovery isn't possible. Microsoft has no way to recover the security domain, and Microsoft can't access your keys without the security domain. Protecting the security domain is therefore of the utmost importance for your business continuity, and to ensure that you aren't cryptographically locked out.
+Without the security domain, disaster recovery isn't possible — all keys are permanently and irrecoverably lost. Microsoft has no way to recover the security domain, and Microsoft can't access your keys without the security domain. This is architecturally enforced by the HSM firmware, not merely by policy. Protecting the security domain is therefore of the utmost importance for your business continuity.
 
 ## Security domain protection best practices