Merge pull request #2704 from msmbaldwin/cmk-qanda

Align Key Vault/MHSM articles with authoritative CMK guidance

Author: JillGrant615

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/07/2026
 ---
 
 # Control your data in the cloud by using Managed HSM
@@ -17,7 +17,7 @@ In this article, we take a deep dive on [Azure Key Vault Managed HSM](./overview
 
 Encryption is one of the key technical measures you can take to get sole control of your data. Azure fortifies your data through state-of-the-art encryption technologies, both for data at rest and for data in transit. Our encryption products erect barriers against unauthorized access to the data, including two or more independent encryption layers to protect against compromises of any single layer. In addition, Azure has clearly defined, well-established responses, policies and processes, strong contractual commitments, and strict physical, operational, and infrastructure security controls to provide our customers the ultimate control of their data in the cloud. The fundamental premise of Azure’s key management strategy is to give our customers more control over their data. We use a [zero trust](https://www.microsoft.com/security/business/zero-trust) posture with advanced enclave technologies, hardware security modules (HSMs), and identity isolation that reduces Microsoft access to customer keys and data.
 
-*Encryption at rest* provides data protection for stored data at rest and as required by an organization's need for data governance and compliance efforts. Microsoft’s compliance portfolio is the broadest in all public clouds worldwide, with industry standards and government regulations such as [HIPAA](https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html),  [General Data Protection Regulation](https://gdpr.eu/), and [Federal Information Processing Standards (FIPS) 140-2 and 3](https://csrc.nist.gov/publications/detail/fips/140/2/final). These standards and regulations lay out specific safeguards for data protection and encryption requirements. In most cases, a mandatory measure is required for compliance.
+*Encryption at rest* provides data protection for stored data at rest and as required by an organization's need for data governance and compliance efforts. Microsoft’s compliance portfolio is the broadest in all public clouds worldwide, with industry standards and government regulations such as [HIPAA](https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html) and [Federal Information Processing Standards (FIPS) 140-2 and 3](https://csrc.nist.gov/publications/detail/fips/140/2/final). These standards and regulations lay out specific safeguards for data protection and encryption requirements. In most cases, a mandatory measure is required for compliance.
 
 ## How does encryption at rest work?
 
@@ -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.
 
@@ -123,7 +123,7 @@ Several layers of technical controls in Managed HSM further protect your key mat
   - **Private endpoints**: By enabling a private endpoint, you're bringing the Managed HSM service into your virtual network allowing you to isolate that service only to trusted endpoints like your virtual network and Azure services. All traffic to and from your managed HSM will travel along the secure Microsoft backbone network without having to traverse the public internet.
   - **Monitoring and logging**: The outermost layer of protection is the monitoring and logging capabilities of Managed HSM. By using the Azure Monitor service, you can check your logs for analytics and alerts to ensure that access patterns conform with your expectations. This allows members of your security team to have visibility into what is happening within the Managed HSM service. If something doesn't look right, you can always roll your keys or revoke permissions.
   - **Bring your own key (BYOK)**: BYOK enables Azure customers to use any supported on-premises HSMs to generate keys, and then import them to the managed HSM. Some customers prefer to use on-premises HSMs to generate keys to meet regulatory and compliance requirements. Then, they use BYOK to securely transfer an HSM-protected key to the managed HSM. The key to be transferred never exists outside of an HSM in plaintext form. During the import process, the key material is protected with a key that's held in the managed HSM.
-  - **External HSM**: Some customers have asked us if they can explore the option of having the HSM outside the Azure cloud to keep the data and keys segregated with an external HSM, either on a third-party cloud or on-premises. Although using a third-party HSM outside of Azure seems to give customers more control over keys, it introduces several concerns, such as latency that causes performance issues, SLA slip that's caused by issues with the third-party HSM, and maintenance and training costs. Also, a third-party HSM can't use key Azure features like soft delete and purge protection. We continue to evaluate this technical option with our customers to help them navigate the complex security and compliance landscape.
+  - **External HSM**: Some customers have asked us if they can explore the option of having the HSM outside the Azure cloud to keep the data and keys segregated with an external HSM, either on a non-Microsoft cloud or on-premises. Although using a non-Microsoft HSM outside of Azure seems to give customers more control over keys, it introduces several concerns, such as latency that causes performance issues, SLA slip that's caused by issues with the non-Microsoft HSM, and maintenance and training costs. Also, a non-Microsoft HSM can't use key Azure features like soft delete and purge protection. We continue to evaluate this technical option with our customers to help them navigate the complex security and compliance landscape.
 
 #### Administrative security controls
 
@@ -140,7 +140,7 @@ These administrative security controls are in place in Azure Key Vault Managed H
 - **[Microsoft Security Response Center](https://www.microsoft.com/msrc) (MSRC)**. Managed HSM service administration is tightly integrated with MSRC.
   - Security monitoring for unexpected administrative operations with full 24/7 security response
 - **[Cloud resilient and secure supply chain](https://azure.microsoft.com/blog/advancing-reliability-through-a-resilient-cloud-supply-chain/)**. Managed HSM advances reliability through a resilient cloud supply chain.
-- **[Regulatory compliance built-in initiative](/azure/governance/policy/samples/built-in-initiatives#regulatory-compliance)**. Compliance in Azure Policy provides built-in initiative definitions to view a list of the controls and compliance domains based on responsibility (Customer, Microsoft, Shared). For Microsoft-responsible controls, we provide additional details of our audit results based on third-party attestation and our implementation details to achieve that compliance.
+- **[Regulatory compliance built-in initiative](/azure/governance/policy/samples/built-in-initiatives#regulatory-compliance)**. Compliance in Azure Policy provides built-in initiative definitions to view a list of the controls and compliance domains based on responsibility (Customer, Microsoft, Shared). For Microsoft-responsible controls, we provide additional details of our audit results based on non-Microsoft attestation and our implementation details to achieve that compliance.
 - **[Audit reports](https://servicetrust.microsoft.com/ViewPage/MSComplianceGuideV3)**. Resources to help information security and compliance professionals understand cloud features, and to verify technical compliance and control requirements
 - **Assume breach philosophy**. We assume that any component could be compromised at any time, and we design and test appropriately. We do regular Red Team/Blue Team exercises ([attack simulation](/compliance/assurance/assurance-monitoring-and-testing)).
 

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/07/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
 
@@ -66,7 +66,7 @@ The [Managed HSM soft-delete feature](soft-delete-overview.md) allows recovery o
 
 ## Private link behavior with Multi-region replication
 
-The [Azure Private Link feature](private-link.md) allows you to access the Managed HSM service over a private endpoint in your virtual network. You would configure private endpoint on the Managed HSM in the primary region just as you would when not using the multi-region replication feature. For the Managed HSM in an extended region, it is recommended to create another private endpoint and private DNS zone once the Managed HSM in the primary region is replicated to the Managed HSM in an extended region., which redirects client requests to the Managed HSM closest to the client location.
+The [Azure Private Link feature](private-link.md) allows you to access the Managed HSM service over a private endpoint in your virtual network. You would configure private endpoint on the Managed HSM in the primary region just as you would when not using the multi-region replication feature. For the Managed HSM in an extended region, it is recommended to create another private endpoint and private DNS zone once the Managed HSM in the primary region is replicated to the Managed HSM in an extended region, which redirects client requests to the Managed HSM closest to the client location.
 
 Here are some scenarios with examples: Managed HSM in a primary region (UK South) and another Managed HSM in an extended region (US West Central).
 

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 hardware and cryptographic design, not merely by policy. Protecting the security domain is therefore of the utmost importance for your business continuity.
 
 ## Security domain protection best practices