Edit

SLA and shared responsibility for Managed HSM external key management

Managed HSM external key management connects Azure services' customer-managed-key (CMK) encryption at rest to your external HSM. The Azure service encrypts and decrypts your data; the external HSM protects the service's data encryption keys. Availability of that key-protection path depends on both Managed HSM and the external components you or your operator manage.

This article explains the availability, SLA, and support responsibilities. For the encryption model and service compatibility, see How CMK encryption at rest works.

Headline tradeoff

Important

Microsoft maintains the Managed HSM SLA for the Managed HSM service, but it doesn't cover end-to-end external key availability, your EKM Proxy, or your external HSM. Failures in those external components can interrupt dependent Azure workloads and don't count against the Azure workload SLAs. A workload can be unavailable even while Azure meets its SLA commitments. For workloads that require SLA-backed key availability, use Managed HSM keys instead.

What Microsoft is responsible for

Microsoft operates the service infrastructure inside the Managed HSM service boundary. This covers the service itself, not control of your key material:

  • Managed HSM service availability, covered by the published Managed HSM SLA.
  • Enforcing the authentication and authorization that you define through your Microsoft Entra tenant and Managed HSM local RBAC.
  • Emitting audit events for Managed HSM-side external key management operations (EkmProxyOperation).
  • Outbound mTLS connection initiation from Managed HSM to the EKM Proxy.
  • Error transparency: surfacing proxy and external-HSM errors back to you and to support teams so that root cause is unambiguous.
  • Documentation, samples, and the public EKM Proxy API specification.

What you (the customer) are responsible for

You control access to your keys, and you own everything outside the Managed HSM service boundary:

  • Caller authentication and authorization: the Microsoft Entra identities and Managed HSM local RBAC role assignments that govern who can use your keys, all controlled within your tenant.
  • Managed HSM diagnostic logging: enabling Managed HSM logging and routing it to Azure Monitor or another destination you choose, including retention.
  • Operating and securing the external HSM, yourself or through an operator you designate (such as your HSM vendor or another third party you choose).
  • Operating and securing the EKM Proxy, yourself or through an operator you designate (such as your HSM vendor or another third party you choose).
  • Network availability between Managed HSM and the proxy over its public endpoint.
  • mTLS certificate provisioning, distribution, and rotation on the proxy side.
  • Performance and capacity planning for the proxy and external HSM under your workload.
  • Logging and audit at the proxy and HSM. Azure can't see these logs.
  • Backup, restore, and disaster recovery for external key material.
  • Geographic redundancy of external key material, the proxy, and the external HSM. This customer-operated redundancy is separate from Managed HSM multi-region replication (geo-replication), which isn't supported with external keys.
  • Compliance attestations for the customer-operated portions of the system.

What the proxy and HSM operator are responsible for

You can operate the EKM Proxy and external HSM yourself, or designate an operator (such as your HSM vendor or another third party). Whoever operates these components is responsible for:

  • Implementing the EKM Proxy correctly per the EKM Proxy API specification.
  • Meeting the ≤ 250 ms per-request latency budget.
  • Supporting the required cryptographic algorithms (A256KW, A256KWP, RSA-OAEP, RSA-OAEP-256) and key types (AES-256, RSA 2048 / 3072 / 4096).
  • Strict adherence to encoding rules: raw unsigned big-endian bytes encoded as base64url, never PEM, JWK, hex, or decimal strings.
  • Providing support and incident response for the proxy and external HSM they operate.

Shared-responsibility summary

Area Microsoft Customer Designated operator
Managed HSM service availability ✅ Owns
Caller authentication and authorization (Entra identities, local RBAC) Enforces ✅ Owns
External KEK material custody ✅ Owns
EKM Proxy implementation ✅ Owns When delegated
EKM Proxy operation (deploy, scale, patch) ✅ Owns When delegated
mTLS certificate lifecycle (Managed HSM client cert) ✅ Owns
mTLS certificate lifecycle (proxy server cert and trusted root CA) ✅ Owns When delegated
Network path between Managed HSM and proxy ✅ Owns
External HSM availability ✅ Owns When delegated
Wrap and unwrap latency ✅ Owns When delegated
Managed HSM-side logging Emits audit events ✅ Configures and retains
Logs (proxy and HSM side) ✅ Owns When delegated
Backup and recovery of external keys ✅ Owns
Geographic redundancy of external keys ✅ Owns
Compliance attestations ✅ Azure scope ✅ Customer scope ✅ Operator scope
Incident response ✅ Managed HSM scope ✅ Proxy and HSM scope When delegated

SLA implications

The Managed HSM SLA continues to apply to Managed HSM key operations and to Managed HSM's role in external key management operations.

There's no Microsoft SLA for end-to-end external key availability, the EKM Proxy, or the external HSM. These dependencies operate outside of Microsoft's control.

Failures attributable to the proxy or external HSM - timeouts, authentication failures, and throttling - report with proxy-originated error codes. Failures in those 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, the Storage workload can be interrupted. That interruption doesn't count against either the Azure Storage or Managed HSM SLA.

These exclusions apply to failures attributable to customer-operated EKM components. They don't remove SLA coverage for Microsoft-operated services or for Managed HSM key operations.

If your workload requires SLA-backed key availability, use Managed HSM keys.

Performance expectations

The per-request latency budget through the proxy is ≤ 250 ms. Managed HSM times out if the proxy doesn't respond within that window.

Microsoft doesn't mask, smooth, or compensate for proxy or HSM latency. Your end-to-end performance reflects the slowest link in the chain.

There are no dedicated retry strategies designed to hide proxy or HSM unavailability. Errors propagate to callers.

Error transparency

Errors that originate in the proxy or external HSM are surfaced with their HTTP status code and message back to Managed HSM and into Azure diagnostic logs.

This makes triage unambiguous: support engineers on both sides of the boundary can tell at a glance whether an issue is on Microsoft's side or yours. For cross-source correlation steps, see Correlate logs across the three sources.

Pricing

Standard Managed HSM pricing applies as usual.

There's no additional Microsoft surcharge for using external key management.

You separately bear the cost of the EKM Proxy compute and the external HSM, typically charged by your HSM vendor.

Support boundaries

Microsoft supports Managed HSM and the published EKM Proxy API specification.

Microsoft doesn't provide a reference proxy implementation as a supported product. Sample code in this documentation is illustrative only.

Raise issues isolated to the proxy or external HSM with your HSM vendor or your operations team.

Microsoft support can help correlate symptoms across the boundary using audit logs, the external key identifier, and timestamp alignment.

When to choose Managed HSM keys instead

External key management isn't the right choice for every workload. Consider Managed HSM keys when:

Related content

  • Last updated on