Azure Managed HSM External Key Management Reaches GA: Requirements, Limits and SLA Risks

While standard Azure Key Vault Managed HSM already gives customers single-tenant, FIPS 140-3 Level 3 validated hardware partitions where Microsoft has no access to key material, certain government, financial services, and strict data-sovereignty frameworks mandate physical possession of the HSM outside the cloud provider's premises. External key management bridges that compliance gap—though, as Microsoft's own documentation candidly warns, it comes with significant architectural, operational, and service-level agreement (SLA) trade-offs that cloud architects need to weigh carefully before flipping the switch.

How External Key Management Works Under the Hood​

To understand what changes with External Key Management, you have to look at how Azure handles Customer-Managed Key (CMK) encryption at rest. Most compatible Azure services—such as Azure Storage and Azure SQL —rely on an envelope encryption pattern. The Azure service encrypts and decrypts bulk data using a local Data Encryption Key (DEK), and that DEK is wrapped and unwrapped by a Key Encryption Key (KEK).

With External Key Management, bulk data encryption stays inside the Azure service, and Azure Key Vault Managed HSM continues to act as the authentication, local Role-Based Access Control (RBAC), and URI endpoint layer that Azure services already know how to talk to. However, Managed HSM no longer holds the actual KEK material. Instead, it stores only a metadata pointer known as an external key identifier.

Whenever an Azure workload needs to wrap or unwrap a DEK, the request follows a specific chain:

• The Azure Service calls the configured Managed HSM key URI using its standard integration.
• Managed HSM authenticates and authorizes the request, then forwards the wrapKey or unwrapKey call over a mutually authenticated TLS (mTLS) connection (requiring TLS 1.3 minimum) to an EKM Proxy.
• The EKM Proxy, operated by the customer or an HSM partner outside Microsoft's infrastructure, translates the request for the External HSM.
• The External HSM performs the cryptographic wrap or unwrap operation internally and returns the unwrapped DEK to the Azure service without the KEK ever leaving the external hardware or transiting Microsoft infrastructure.

According to Microsoft Learn documentation updated alongside the October 16, 2026 general availability release, EKM supports wrapKey and unwrapKey operations using RSA-OAEP, RSA-OAEP-256, A256KW, and A256KWP algorithms across RSA keys (2048, 3072, and 4096 bits) and AES-256 (oct, 256-bit) keys.

Section Summary: EKM keeps the actual Key Encryption Key inside a customer-operated HSM outside Azure while using Managed HSM as a routing and access-control gateway via a customer-managed EKM Proxy.

What Changed Between Preview and General Availability​

During the July 2026 public preview, enabling External Key Management was a manually gated process that required contacting a Microsoft account team to whitelist your subscription. With the October 16, 2026 general availability update on Microsoft Learn, onboarding has transitioned to self-service subscription feature registration that is automatically approved.

However, not every piece of the EKM ecosystem crossed the GA finish line at the same time, and some older Microsoft Learn search indexes still display preview tags. Based on the updated October 16, 2026 Microsoft Learn overview and FAQ documentation, here is where the platform stands today:

• Core EKM Status: Generally available across all Azure public regions.
• Sovereign Clouds: Azure Government and Azure China remain out of scope.
• Networking Models: The public internet connectivity model (where Managed HSM reaches the EKM Proxy via a publicly resolvable FQDN and IPv4 address over mTLS) is generally available. The Azure Private Link integration—which routes traffic over the Microsoft backbone via a managed private endpoint—remains in preview. Each Managed HSM pool supports one external key management connection and up to two EKM Proxy private endpoints.
• Pricing: Standard Managed HSM pricing applies with no additional per-operation surcharge from Microsoft, though customers pay for their own proxy compute, networking, and third-party HSM licensing.

Supported HSM Vendors and the Open Proxy Specification​

Microsoft does not build, ship, or support the EKM Proxy software. Instead, it publishes a public EKM Proxy API specification defining four endpoints, JSON schemas, and mTLS requirements so customers can build their own proxy or use a partner's implementation. According to Microsoft Learn's vendor directory, HSM providers supporting the specification include:

Microsoft explicitly notes that this vendor list is informational and that each vendor is solely responsible for the compatibility, quality, and support of its proxy implementation.

Section Summary: While EKM is now generally available in all public Azure regions with self-service subscription registration, Azure Private Link connectivity for the proxy remains in preview, and sovereign clouds are excluded.

Why Microsoft Calls EKM a "Last-Resort Option"​

It is rare to see a cloud vendor launch a major security feature into general availability while simultaneously urging customers not to use it unless legally forced to do so. Yet Microsoft's updated documentation literally describes External Key Management as a "last-resort option" and emphasizes that it is not a general-purpose upgrade to standard Managed HSM keys.

Why the blunt warning? Because moving your root of trust outside Azure shifts the operational blast radius directly onto your IT team's shoulders:

1. The SLA Boundary Stops at the Door: The Managed HSM SLA covers Microsoft's service only up to the point where it calls your EKM Proxy. If your EKM Proxy, network link, or on-premises HSM goes down, dependent Azure workloads—like an Azure Storage account that needs to unwrap a DEK—can become completely unavailable. Crucially, outages caused by your external components do not count against the SLAs of Managed HSM or the dependent Azure workloads.
2. A Strict 250 ms Latency Budget: Every external key operation adds network round-trips outside Azure. According to Microsoft Learn's FAQ, each proxy round-trip must complete in 250 milliseconds or less, or Managed HSM will time out and return an error.
3. No Geo-Replication or External Key Backup/Restore: Multi-region replication (geo-replication) in Managed HSM is not supported for external keys. Furthermore, Managed HSM backup and restore does not support external keys; Microsoft warns that attempting to restore an external key from a backup can actually place the associated Managed HSM resource into a degraded state. Recovery requires recreating the external key reference instead.
4. No Secure Key Release (SKR) or Confidential VM Disk Encryption: Scenarios that require Secure Key Release are unsupported because SKR requires releasing the KEK into an Azure enclave, which would violate the core guarantee that the external KEK never leaves customer hardware.
5. Immutable Key Types: You cannot convert a Managed HSM key into an external key or vice versa. Moving a workload between them requires generating a new key with a new URI and reconfiguring every consuming Azure service.

Section Summary: Because external key dependencies introduce a 250 ms timeout constraint, forfeit end-to-end Azure workload SLA protections during external outages, and disable geo-replication and backup/restore, EKM should only be deployed when mandated by strict compliance rules.

How to Enable External Key Management on Your Subscription​

If your compliance team has reviewed the shared-responsibility model and confirmed that physical key custody outside Azure is mandatory, administrators with Contributor or Owner permissions (Microsoft.Features/*) can enable EKM per subscription using the Azure CLI.

1. Sign in to the Azure CLI and set your target subscription ID:
   
   Code:

   SUBSCRIPTION_ID="<subscription-id>"
   az feature register \
     --namespace Microsoft.KeyVault \
     --name MHSM_EKM \
     --subscription "$SUBSCRIPTION_ID"

2. Verify the registration state (approval is automatic, though propagation takes a few moments):
   
   Code:

   az feature show \
     --namespace Microsoft.KeyVault \
     --name MHSM_EKM \
     --subscription "$SUBSCRIPTION_ID" \
     --query properties.state \
     --output tsv

3. Once the output returns Registered, deploy your external HSM and EKM Proxy, configure mutual TLS certificates, register the proxy connection inside Managed HSM, and create your external key reference.

Troubleshooting Common Pitfalls​

For administrators running EKM in production, Microsoft Learn highlights two primary failure modes to watch for in AzureDiagnostics (which can be filtered where OperationName contains "Ekm" to inspect EkmProxyOperation records):

• mTLS Handshake Failures: Managed HSM rotates its client certificate on a schedule. If your EKM Proxy's trusted-issuer allow-list isn't kept up to date—or if you rotate the proxy's server certificate without updating the connection object in Managed HSM—connections will fail.
• Identifier Mismatches: The external key identifier stored on the Managed HSM key reference must match the identifier registered at the proxy character-for-character, as external key identifiers are both case-sensitive and URL-encoded.

Ultimately, External Key Management for Azure Key Vault Managed HSM is a specialized regulatory key that unlocks cloud adoption for organizations bound by strict physical custody laws. Just make sure your infrastructure team treats that external proxy and HSM link with the same redundancy and monitoring rigor as a Tier-0 production database—because when your keys live outside the cloud, your uptime lives there too.