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.
In this quickstart, you connect your external HSM to Managed HSM, create an external key reference, and test the key-protection path. You then use the Managed HSM key URI to configure customer-managed-key (CMK) encryption at rest in a compatible Azure service.
For the encryption model and service compatibility, see What is Managed HSM external key management?
If you prefer to use the Azure portal, see Quickstart: Create your first external key using the Azure portal.
Prerequisites
Before you begin, you need:
- An existing Managed HSM deployed in any Azure public region, in a subscription enabled for external key management. To create a Managed HSM, see Quickstart: Provision and activate a Managed HSM using Azure CLI.
- An operational EKM Proxy reachable from Azure. The proxy must implement the EKM Proxy API specification. For supported vendors, see What is Managed HSM external key management?.
- A key created in your external HSM with a known external key identifier. The external key identifier is the identifier your proxy uses to look up the key.
- The root CA certificate (PEM format) that signed your proxy's TLS server certificate.
- Azure CLI version 2.x with the latest
keyvaultextension installed. Runaz extension add --name keyvaultoraz extension update --name keyvaultto get the latest version. - The
Managed HSM EKM Administratorrole to manage external key management connections, and theManaged HSM Crypto Userrole to create and use keys. For role assignment steps, see Managed HSM access control.
Sign in to Azure
az login
Set your subscription if you have more than one:
az account set --subscription "<subscription-id>"
Show the Managed HSM client certificate
Managed HSM presents an X.509 client certificate to your EKM Proxy on every inbound mutual TLS (mTLS) connection. Before you create the external key management connection, retrieve the certificate subject common name and the root CA certificate and allow-list it at your proxy. This lets the proxy validate that the connection comes from your Managed HSM, not an arbitrary caller.
az keyvault ekm-connection certificate show --hsm-name <Managed HSM Name>
The output looks similar to this:
{
"caCertificates": [
"MIIDj...<truncated>...MrY="
],
"subjectCommonName": "contoso.managedhsmclient.azure.net"
}
Configure your proxy to trust connections that present certificate with the subjectCommonName and rooted to one of the certificates in caCertificates list above. The exact steps depend on your proxy vendor.
Note
For rotation steps and certificate lifecycle details, see Configure networking and mTLS for Managed HSM external key management.
Create the external key management connection
The external key management connection binds your Managed HSM to a single EKM Proxy. It contains the proxy address, the server CA trust anchor, and an optional path prefix.
This section creates a public internet connection. For Private Link, follow Configure the Azure Private Link model (preview) instead, then continue with Verify the connection.
az keyvault ekm-connection create \
--hsm-name <Managed HSM Name> \
--host <EKMProxy Host> \
--server-ca-certificate <Root cert> \
[--path-prefix <prefix>]
Parameter reference:
--hsm-name: The name of your Managed HSM.--host: The fully qualified hostname of your EKM Proxy. For example,proxy.contoso.com. The proxy must listen on TCP port 443; a nonstandard port isn't supported.--server-ca-certificate: Specifies the path to the root CA certificate file (PEM or DER format) used to verify the proxy's TLS server certificate.--path-prefix(optional): A URL path prefix if your proxy multiplexes multiple customers or pools by path. For example,/contoso/prod.
Note
Pass the root CA certificate to --server-ca-certificate, not the proxy's leaf certificate. Managed HSM uses this CA to validate the entire certificate chain presented by your proxy during the mTLS handshake. Passing the leaf certificate instead causes the handshake to fail for any certificate renewal.
Verify the connection
After creating the connection, verify that Managed HSM can reach your proxy:
az keyvault ekm-connection check --hsm-name <Managed HSM Name>
This command calls the proxy's /info endpoint through the configured connection. Successful output looks similar to this:
{
"apiVersion": "1.0",
"ekmProduct": "Contoso HSM v1.0.0",
"ekmVendor": "Contoso HSM",
"proxyName": "Contoso Proxy Service",
"proxyVendor": "Contoso Proxy"
}
Common failure causes include firewall rules blocking the proxy port, an incorrect --host value, or the proxy rejecting the Managed HSM client certificate. For remediation steps, see Troubleshoot Managed HSM external key management.
Create the external key
Create a Managed HSM key reference that points at the external key in your HSM. Managed HSM doesn't generate any key material. This command registers a reference to an existing key identified by its external key identifier.
az keyvault key create \
--external-key-id <external-key-identifier> \
--hsm-name <Managed HSM Name> \
--name <key-ref-name>
Parameter reference:
--external-key-id: The external key identifier registered at your proxy. This is the identifier the proxy uses to look up the correct key in your external HSM.--hsm-name: The name of your Managed HSM.--name: The name you want to give the Managed HSM key reference. This becomes part of the key URI that Azure services use.
Important
The external key identifier is immutable for the lifetime of a key version. You can't change it after creation. To rotate the key, create a new key version with a new external key identifier using az keyvault key create with the same --name. The key URI (HSM URI + key name) stays stable across versions; only the version segment changes.
The command returns the key URI in the form https://<hsm-name>.managedhsm.azure.net/keys/<key-ref-name>/<version>. Keep this URI for configuring your Azure service.
Verify wrap/unwrap
Test the key protection path with a wrap and unwrap round trip. The external HSM performs the operations through your proxy, and Managed HSM returns the result. This test confirms the key path works. It doesn't configure or validate an Azure service's CMK integration.
Note
Use the wrapkey and unwrapkey data-plane endpoints with az rest for this test. az keyvault key encrypt calls a different key API operation and isn't a substitute for wrapping a data encryption key.
Create a request body for the wrap operation. Set
valueto the base64url-encoded key material you want to wrap.{ "alg": "RSA-OAEP-256", "value": "<base64url-encoded-plaintext-key>" }Save it as
wrapkey.json. For AES external keys, use"alg": "A256KW"instead ofRSA-OAEP-256.Call the
wrapkeyendpoint on your key reference:az rest --method POST \ --uri "https://<Managed HSM Name>.managedhsm.azure.net/keys/<key-ref-name>/wrapkey?api-version=7.5" \ --resource "https://managedhsm.azure.net" \ --headers "Content-Type=application/json" \ --body @wrapkey.jsonThe response returns the key version (
kid) and avaluefield containing the base64url-encoded wrapped key. Copy thevaluefor the next step.Create a request body for the unwrap operation, using the wrapped
valuefrom the previous step:{ "alg": "RSA-OAEP-256", "value": "<wrapped-value-from-previous-step>" }Save it as
unwrapkey.json.Call the
unwrapkeyendpoint to confirm round-trip correctness:az rest --method POST \ --uri "https://<Managed HSM Name>.managedhsm.azure.net/keys/<key-ref-name>/unwrapkey?api-version=7.5" \ --resource "https://managedhsm.azure.net" \ --headers "Content-Type=application/json" \ --body @unwrapkey.jsonA successful response returns the original plaintext
valueyou wrapped in the first step. If the unwrap fails, see Troubleshoot Managed HSM external key management for proxy error codes and remediation steps.
Use the key with an Azure service
Complete the workload integration by following your Azure service's CMK configuration documentation:
- Confirm that the service supports CMKs with Managed HSM and that your external key's type and algorithm meet its requirements.
- Grant the identity used by the service the required Managed HSM local RBAC permissions. For role assignment guidance, see Managed HSM access control.
- Configure the service's CMK settings with your Managed HSM key URI. Use the versioned or unversioned URI format required by that service. For Azure Storage, see Configure customer-managed keys with Azure Key Vault Managed HSM.
- Confirm that the service reports the expected CMK configuration, then perform a read/write operation on the protected workload. Review the service's diagnostics and Managed HSM external key management logs if the operation fails.
The Azure service uses its existing Managed HSM integration. It doesn't need your external HSM's vendor-specific API or credentials.
View audit logs
Every EKM Proxy call produces an EkmProxyOperation entry in your Managed HSM diagnostic logs. To query these in Log Analytics:
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.KEYVAULT"
| where OperationName contains "Ekm"
| project TimeGenerated, Resource, OperationName, requestUri_s, ResultType, ResultDescription
The log includes the operation type (wrap or unwrap), the external key identifier, the HTTP status code returned by the proxy, and the round-trip latency. For the full logging and monitoring guide, including alert configuration and proxy-side log correlation, see Logging and monitoring for Managed HSM external key management.
Clean up resources
If you configured an Azure service to use this key, migrate the workload to another key before deleting the reference or connection. Retain the external key and its connection for as long as the workload's data, backups, or snapshots require it.
To remove the resources created in this quickstart:
Delete the Managed HSM key reference:
az keyvault key delete \ --hsm-name <Managed HSM Name> \ --name <key-ref-name>Delete the external key management connection:
az keyvault ekm-connection delete \ --hsm-name <Managed HSM Name>
Deleting the Managed HSM key reference doesn't affect the key material in your external HSM. That key remains in your HSM until you remove it there.
Next steps
- Quickstart: Create your first external key using the Azure portal: complete the same flow in the Azure portal.
- External key lifecycle in Managed HSM external key management: key rotation, versioning, and decommissioning external keys.
- Configure networking and mTLS for Managed HSM external key management: public internet connectivity, Private Link integration (preview), and certificate rotation.
- Logging and monitoring for Managed HSM external key management: alert rules, Kusto Query Language (KQL) queries, and proxy log correlation.
- Troubleshoot Managed HSM external key management: error codes, proxy diagnostics, and remediation steps.