Get answers to common questions about Azure Key Vault Managed HSM external key management, including how it differs from Managed HSM keys, what's covered by SLA, and which HSM vendors are supported.
Overview
What is Managed HSM external key management?
External key management connects Azure services' customer-managed-key (CMK) encryption at rest to an HSM you operate outside Microsoft infrastructure. The Azure service uses its Managed HSM key interface and continues to encrypt your data. Your external HSM protects the service's data encryption keys through a proxy you or your HSM vendor operate.
Which Azure services can use external keys?
Use external keys with Azure services that support CMKs with Managed HSM. Check the service's CMK configuration documentation for supported key types, algorithms, and identity requirements. For the encryption model, see How CMK encryption at rest works.
Why use Managed HSM instead of connecting an Azure service directly to my external HSM?
Managed HSM provides the key interface and access-control model that compatible Azure services already support. You configure the service with a Managed HSM key URI; Managed HSM routes the key operations through your EKM Proxy to the external HSM. Calling an external HSM from your own application doesn't replace this built-in Azure service integration.
When should I use external key management instead of Managed HSM keys?
Managed HSM keys provide complete customer sovereignty and the best high-availability experience. Use external key management only as a last-resort option when you have a legal or contractual requirement to keep key material physically outside Microsoft infrastructure. It's not a general-purpose upgrade to Managed HSM keys.
When should I not use external key management?
Use Managed HSM keys when you don't have a legal or contractual requirement for external key custody. They provide complete customer sovereignty, lower latency, and SLA-backed key availability without an external proxy or HSM dependency. Review the availability and support responsibilities before choosing external keys.
Availability and access
In which regions are external key management and its Private Link integration available?
Managed HSM external key management and its Azure Private Link integration are available in all Azure public regions. External key management is generally available; the Private Link integration is in preview. Sovereign clouds (Azure Government, Azure China) are out of scope.
Who can use external key management, and how do I enable it?
External key management is available to all customers. Enable it for each subscription by registering the MHSM_EKM feature in the Microsoft.KeyVault namespace. Registration is automatically approved.
Why does external key management require subscription enablement?
A workload that uses external keys depends on the availability of your EKM Proxy, external HSM, and connectivity. Failures attributable to your EKM Proxy or external HSM can interrupt dependent Azure workloads and don't count against the Azure workload SLAs. You or your designated operator are responsible for high availability, disaster recovery, and support of these external components. Subscription registration is an explicit opt-in so you can review these responsibilities before using external keys. Registration is automatically approved. For details, see SLA and shared responsibility for Managed HSM external key management.
Is external key management generally available?
Yes. Managed HSM external key management is generally available. Its Azure Private Link integration for connecting to an EKM Proxy is in preview.
What restrictions apply to external key management?
External key management requires subscription registration. Failures attributable to customer-operated external components don't count against Azure workload SLAs. Secure Key Release, backup/restore of external keys, and Managed HSM geo-replication aren't supported. For details and the Confidential VM exception, see Scope and limitations.
Can I use geo-replication with external keys?
No. Managed HSM multi-region replication (geo-replication) isn't supported with external keys. Geographic redundancy of your external HSM and EKM Proxy is separate and remains your responsibility or your designated operator's responsibility. For details, see SLA and shared responsibility for Managed HSM external key management.
Architecture and operations
What operations does external key management support?
External keys support wrapKey and unwrapKey to protect the data encryption keys used by compatible Azure services. For supported algorithms and the precise operation scope, see Supported and unsupported operations.
Why aren't Secure Key Release and Confidential VM disk-encryption scenarios supported?
Those scenarios require releasing the external key encryption key (KEK) into Azure, which would require it to be marked exportable and violate the promise that it remains outside Microsoft infrastructure. For the distinction between key release and unwrapping a data encryption key, see Scenarios that require key release.
What algorithms does external key management support?
External key management supports RSA-OAEP, RSA-OAEP-256, A256KW, and A256KWP.
What key types and sizes does external key management support?
External key management supports RSA keys at 2048, 3072, and 4096 bits, and AES-256 keys (oct, 256 bits). Key material lives in your external HSM; Managed HSM stores only the key reference called an external key identifier.
Can I migrate an external key to a Managed HSM key?
No. In external key management, a key's status as either an external key or a Managed HSM key is immutable by design. External key management blocks transitions in both directions at the API. Azure Key Vault and Managed HSM also don't allow key material to be exported, so external keys and Managed HSM keys can't be converted into one another by any mechanism. To switch a workload from an external key to a Managed HSM key (or vice versa), migrate the workload to a new key as described in Migrate workloads off external keys. The new key has a different key URI, and every consuming Azure service must be reconfigured to use it.
Can Microsoft access my key material?
No. The KEK never leaves your external HSM, and Microsoft has no path to it. Managed HSM stores only the external key identifier reference, not the key itself. The EKM Proxy operates entirely outside Microsoft infrastructure, and Microsoft has no visibility into the proxy or the external HSM.
Performance and SLA
What's the latency budget for an external key management operation?
Each proxy round-trip must complete in 250 ms or less. Managed HSM times out and returns an error if the proxy doesn't respond within that window. For guidance on sizing and network topology to stay within budget, see Managed HSM external key management architecture.
Is external key management covered by the Managed HSM SLA?
Partially. The Managed HSM SLA covers Managed HSM up to and including the point at which it calls your EKM Proxy. End-to-end external key availability, the EKM Proxy, and the external HSM aren't covered by the SLA. Enabling external key management doesn't change SLA coverage for Managed HSM keys. For the full breakdown, see SLA and shared responsibility for Managed HSM external key management.
How do external component failures affect the SLAs of dependent Azure workloads?
Failures in customer-operated external components can interrupt dependent Azure workloads and don't count against the Azure workload SLAs. For example, if Azure Storage can't unwrap a data encryption key through Managed HSM because your EKM Proxy or external HSM is unavailable, that interruption doesn't count against either the Azure Storage or Managed HSM SLA. Microsoft remains responsible for the services it operates. For details, see SLA and shared responsibility for Managed HSM external key management.
What does external key management cost?
Standard Managed HSM pricing applies for the Managed HSM service. Microsoft doesn't add a per-operation surcharge for external key management. You separately bear the cost of the EKM Proxy compute and your HSM vendor's licensing.
Networking and security
How does Managed HSM connect to the EKM Proxy?
Managed HSM supports two connectivity models. In the public internet model, Managed HSM connects to the proxy over the public internet on a publicly resolvable FQDN that resolves to a publicly routable IPv4 address. In the Azure Private Link (preview) model, Managed HSM connects through a managed private endpoint to an Azure Private Link Service you publish in front of the proxy, so traffic stays on the Microsoft backbone network. Both models are secured with mutual TLS (mTLS) and TLS 1.3 as the minimum version, and the proxy must be configured with the subject common name and root CA of the Managed HSM client certificate to authenticate inbound requests. For step-by-step setup, see Configure networking and mTLS for Managed HSM external key management.
How many EKM Proxy private endpoints can a Managed HSM pool have?
A pool supports up to two EKM Proxy private endpoints, but has one external key management connection. In PrivateEndpoint mode, the connection's host is the name of an approved private endpoint, not a Private Link Service identifier, DNS name, or IP address. For setup steps, see Configure the Azure Private Link model (preview).
Can I change an existing connection from public internet to Private Link?
Yes. You can use the Private Link integration in preview. Create the private endpoint, wait for creation to succeed, have the Private Link Service owner approve it, and verify that its connection state is Approved. Then update the existing external key management connection with connectivity_mode set to PrivateEndpoint and host set to the approved endpoint's name. For commands, see Change from public internet to Private Link (preview).
Who owns the EKM Proxy?
You or your HSM vendor. Microsoft doesn't ship or support the EKM Proxy as a product. You're responsible for deploying, operating, securing, and scaling the proxy.
How are mTLS certificates managed?
Managed HSM rotates its client certificate on a schedule; you must keep the proxy's trusted-issuer allow-list current. The proxy's server certificate and its root CA trust anchor are customer-rotated and must be kept synchronized with the external key management connection object in Managed HSM. For detailed certificate management guidance, see Configure networking and mTLS for Managed HSM external key management.
HSM vendors and self-serve onboarding
Which HSM vendors support external key management?
See HSM vendors that support external key management for the current list of HSM vendors that support the external key management API specification. The list is informational; Microsoft makes no representations about the compatibility or availability of any specific vendor's proxy. Each vendor is responsible for the functionality and support of its own implementation.
I'm an HSM vendor. How do I add external key management support?
Build a conformant EKM Proxy that implements the EKM Proxy API specification exactly. The specification defines four endpoints, the JSON request and response schemas, encoding rules, error model, and mTLS requirements. For the full specification and implementation details, see EKM Proxy API reference for Managed HSM external key management.
Can I run my own proxy without a vendor partner?
Yes. The EKM Proxy API specification is publicly available, and any organization can implement a conformant proxy without a vendor partner. See EKM Proxy API reference for Managed HSM external key management for the specification and implementation details.
Logging and troubleshooting
Where do I find audit logs for external key management operations?
Managed HSM emits an EkmProxyOperation record in AzureDiagnostics for every proxy call. Filter by OperationName contains "Ekm" to isolate external key management activity. The proxy and external HSM produce their own logs, which you're responsible for collecting and retaining. For log schema and query examples, see Logging and monitoring for Managed HSM external key management.
What are common failure causes?
Common failure causes include mTLS handshake errors (usually caused by certificate allow-list drift after a Managed HSM client certificate rotation) and external key identifier mismatches (where the external key identifier stored on the Managed HSM key reference doesn't exactly match the identifier registered at the proxy). External key identifiers are case-sensitive and URL-encoded. See Troubleshoot Managed HSM external key management for the full diagnostic guide.