Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Azure Key Vault Managed HSM external key management (EKM) connects Azure services' customer-managed-key (CMK) encryption at rest to an HSM you operate outside Microsoft infrastructure. You can protect supported Azure workloads with an externally held key while using Managed HSM for authentication, authorization, and the key interface those services already support.
The Azure service continues to encrypt and decrypt your data. Your external HSM protects the service's data encryption keys through an EKM Proxy that you or your HSM vendor operate. The key encryption key stays in your external HSM.
EKM provides this integration for Azure services that support CMKs with Managed HSM. Review the supported-service guidance and your service's CMK configuration documentation before planning your deployment.
External key management is generally available. Azure Private Link integration for connecting Managed HSM to your EKM Proxy is in preview. For setup and preview terms, see Configure the Azure Private Link model (preview).
How CMK encryption at rest works
Most Azure customer-managed-key (CMK) encryption-at-rest integrations use envelope encryption. The Azure service encrypts and decrypts data with a data encryption key (DEK), while the customer-managed key acts as a key encryption key (KEK) to wrap and unwrap the DEK. External key management supports this pattern for Azure services that support CMKs with Managed HSM. It moves the KEK operation to your external HSM, not the service's bulk-data encryption. Unwrap returns the DEK to the Azure service; it doesn't release the external KEK.
Why use external key management?
External key management is the right choice when you have a hard requirement that your key material never physically resides on Microsoft infrastructure. Specific drivers include:
- Compliance with physical HSM possession requirements. Use external key management when legal, regulatory, or contractual requirements mandate that you physically possess and operate the HSM outside Microsoft infrastructure. The KEK remains in that HSM and never resides in or transits Microsoft infrastructure.
- Vendor agnosticism. Microsoft publishes a standard EKM Proxy API. Any HSM vendor can implement a compliant proxy, and you can implement one yourself.
- Clear responsibility boundary. Microsoft is responsible for Managed HSM up to and including the service boundary. You and your HSM vendor own everything beyond it: the proxy, the external HSM, networking, availability, and support.
- No Microsoft surcharge. External key management doesn't add a per-operation fee on top of standard Managed HSM pricing. You bear the cost of your proxy infrastructure and your HSM vendor licensing.
When not to use external key management
Managed HSM keys provide complete customer sovereignty and the best high-availability experience. External key management is a last-resort option for workloads with legal or contractual requirements to keep key material physically outside Microsoft infrastructure. It's not a general-purpose upgrade to Managed HSM keys.
If you don't have a requirement for that external custody, use Managed HSM keys instead. External key management introduces additional availability, performance, and operational responsibilities.
Specific reasons to choose Managed HSM keys over external key management:
- No end-to-end Microsoft service-level agreement (SLA) for external keys. The Managed HSM SLA continues to cover the Managed HSM service, but it doesn't cover your EKM Proxy or external HSM. Failures in those external components can interrupt dependent Azure workloads and don't count against the Azure workload SLAs. You or your designated operator are responsible for their high availability, disaster recovery, and support. For details, see SLA and shared responsibility for Managed HSM external key management.
- Lower availability and performance. Every external key operation adds network round-trips to your proxy and HSM. Managed HSM keys are faster and more available by design.
- Higher operational cost. You're responsible for provisioning, patching, scaling, and monitoring the proxy and the external HSM.
- Microsoft provides no proxy or HSM support. Microsoft doesn't ship, run, or support the EKM Proxy or the external HSM. That responsibility belongs to you or your HSM vendor.
Comparison: External keys versus Managed HSM keys
| External key | Managed HSM key | |
|---|---|---|
| Key material location | Customer-owned HSM outside Microsoft infrastructure | FIPS 140-3 Level 3 HSM inside Azure |
| Key ownership and sovereignty | Customer (or your HSM vendor) - key material resides in your own HSM | Customer - sole control of key material through partition ownership; Microsoft has no access to your keys |
| SLA | No end-to-end Microsoft SLA for external keys; Managed HSM service remains covered | Covered by Managed HSM SLA |
| Geo-replication | Not supported | Managed HSM multi-region replication |
| Latency | Higher (proxy + HSM round-trip added to each operation) | Lower (no external round-trip) |
| Azure service integration | CMK encryption at rest for compatible Azure services | CMK encryption at rest and other supported key scenarios |
| Networking | You manage: public internet or Azure Private Link (preview), secured by mutual TLS (mTLS) | Managed by Azure |
| Logging | Azure Monitor for Managed HSM; proxy and HSM logs are your responsibility | Azure Monitor, fully integrated |
| Pricing | Standard Managed HSM pricing plus your proxy and HSM costs | Standard Managed HSM pricing |
| Recommended use case | Regulatory or sovereignty mandate requiring physical key control outside Microsoft | All other encryption-at-rest workloads |
How external key management works (high level)
An Azure service, such as Azure Storage, uses a Managed HSM key URI for its CMK configuration. Managed HSM authenticates and authorizes the service's identity, then routes external-key operations through your EKM Proxy to your external HSM.
The service uses its existing Managed HSM integration rather than calling your HSM's vendor-specific API. Your proxy translates the key operations, and the external HSM performs them without releasing the KEK. You manage service access through Managed HSM local RBAC.
For the request flow, trust boundaries, and network topology options, see Managed HSM external key management architecture.
HSM vendors that support external key management
The following HSM vendors support the Managed HSM external key management API specification.
| Vendor name | Supported products | More information |
|---|---|---|
| Entrust | Entrust Cryptographic Security Platform Key Manager, backed by Entrust nShield HSMs | Entrust key management solutions |
| Eviden | Eviden Proteccio HSM and Eviden KMS | Eviden Proteccio HSM and Eviden KMS |
| Fortanix | Data Security Manager | Fortanix solutions for Microsoft Azure |
| Futurex | CryptoHub | Futurex |
| Securosys SA | Primus HSM family and Securosys Cloud HSM | Securosys External Key Management Proxy |
| Thales | Thales Luna HSM | Advanced encryption with comprehensive Azure key management |
| Utimaco | Enterprise Secure Key Manager (ESKM) and Enterprise Key Manager as a Service (EKMaaS) | Utimaco Enterprise Secure Key Manager |
This list is informational. Microsoft makes no representations about the compatibility, availability, or quality of any particular vendor's proxy implementation. Each HSM vendor is responsible for the functionality of its proxy and for supporting its own customers. Evaluate vendors based on the deployment guidance, conformance results, and support commitments that each vendor publishes for its own product.
Microsoft doesn't ship a proxy. Vendors implement the proxy using a public EKM Proxy API. You can also implement your own proxy against the same public API.
Scope and limitations
Keep the following constraints in mind when you use external key management:
- Subscription enablement. All customers can use external key management, but you must enable it for each subscription. Registration is automatically approved.
- Region. External key management and its Azure Private Link integration (preview) are available in all Azure public regions. Sovereign clouds (Azure Government, Azure China) are out of scope.
- CMK encryption-at-rest integration. Use external keys with Azure services that support CMKs with Managed HSM. For the key operation and algorithm reference, see Supported and unsupported operations.
- SLA boundary. The Managed HSM SLA continues to cover the Managed HSM service, but it doesn't cover end-to-end external key availability, the EKM Proxy, or the external HSM.
- Error transparency. Managed HSM logs surface failures attributable to the proxy or external HSM. These failures don't count against the Managed HSM SLA or the SLAs of dependent Azure workloads.
- External key identifier immutability. An external key identifier is immutable after assignment. Rotate keys by creating new key versions, not by modifying an existing external key identifier.
- Key release not supported. Secure Key Release (SKR) and Confidential VM disk-encryption scenarios that require it aren't supported. See Scenarios that require key release.
- Backup and restore not supported. Managed HSM does not currently support backup and restore operations for external keys. Attempting to restore an external key from backup can cause the associated Managed HSM resource to enter a degraded state. To recover an external key reference, recreate the external key reference in Managed HSM rather than using restore operations.
- Geo-replication not supported. Managed HSM multi-region replication (geo-replication) isn't supported with external keys.
Scenarios that require key release
Secure Key Release (SKR) would release the external KEK into an Azure workload and require the external key to be marked exportable. That action would violate the external key management guarantee that the KEK never resides in or transits Microsoft infrastructure. Confidential VM disk-encryption scenarios that require SKR are therefore unsupported. This limitation differs from unwrapKey, which returns a DEK to the Azure service without releasing the external KEK.
Enable external key management for your subscription
External key management is available to all customers. You must enable it separately for each subscription.
Caution
External dependencies can interrupt your Azure workloads. When you use external keys, access to encrypted data depends on your EKM Proxy, external HSM, and their connectivity. Failures in these components can make dependent Azure workloads unavailable even when Azure services remain healthy.
Interruptions attributable to customer-operated external components don't count against the SLAs of affected Azure services, including Azure Storage and Managed HSM. These exclusions don't remove SLA coverage for Microsoft-operated services or for Managed HSM key operations. You or your designated operator are responsible for the availability, recovery, and support of the external components.
Review the SLA and shared-responsibility model before proceeding.
Sign in to Azure CLI with an identity that can register subscription features. The Contributor and Owner roles include the required Microsoft.Features/* permissions. These subscription permissions are separate from the Managed HSM data-plane roles used to manage connections and keys.
Register the feature for your subscription by using az feature register. Replace <subscription-id> with the ID of the subscription that contains your Managed HSM.
SUBSCRIPTION_ID="<subscription-id>"
az feature register \
--namespace Microsoft.KeyVault \
--name MHSM_EKM \
--subscription "$SUBSCRIPTION_ID"
Check its registration status by using az feature show:
az feature show \
--namespace Microsoft.KeyVault \
--name MHSM_EKM \
--subscription "$SUBSCRIPTION_ID" \
--query properties.state \
--output tsv
Wait until the result is Registered before continuing. If it returns Registering, run the status command again later. If registration fails or doesn't reach Registered, see Get help.
Registration makes EKM available in the subscription. It doesn't convert existing keys, configure your proxy connection, or change your workloads' encryption settings.
Get started
Follow this path from service selection to workload integration:
- Confirm that your Azure service supports CMKs with Managed HSM, review the availability and support responsibilities, and enable external key management for your subscription.
- Deploy your external HSM and EKM Proxy with your chosen operator. Review the architecture and networking and mTLS guidance.
- Register the proxy connection and create an external key reference by using the Azure CLI quickstart or Azure portal quickstart.
- Grant your Azure service access to the key, configure its CMK settings with the Managed HSM key URI, and verify a read/write operation on the protected workload. Follow your service's documentation for the exact steps.