External key management for Azure Managed HSM is now in public preview

Azure Key Vault Managed Hardware Security Module (HSM) offers robust control over your encryption keys. These keys are generated and kept in a dedicated FIPS 140-3 Level 3 HSM, exclusively for your use. This means that Microsoft cannot access your key data, and you decide who can utilise each key. For many organisations, especially those with strict regulatory needs, this level of control is adequate.

However, some organisations have a requirement that the hardware storing their keys must not be located within Azure data centres. To meet this need, external key management for Azure Key Vault Managed HSM is currently in public preview, fulfilling a commitment made last year.

How Managed HSM Delivers Sovereignty Today

Before diving into external key management, let’s clarify the sovereignty that Managed HSM already provides. Managed HSM is a single-tenant service, meaning each instance is a dedicated cluster of validated FIPS 140-3 Level 3 HSM partitions designed for individual customers, powered by Marvell LiquidSecurity adapters. Keys are generated inside this hardware and never leave it in plain text, keeping them secure from Microsoft operators.

Control is firmly in your hands:

• Customer-Specific Security Domain: Each HSM cluster is cryptographically isolated by a security domain that you create and manage. Microsoft cannot decrypt your key material or recover your HSM cluster without your specific security domain. You hold full control over safeguarding it, outside of Microsoft’s reach.
• Multiperson Control: The security domain is backed by a quorum of RSA key pairs that you store offline. Recovery processes require this quorum, ensuring that no single person—or Microsoft staff—can act alone.
• Local Role-Based Access Control (RBAC): Your operations are protected by a data-plane authorisation model which is separate from Azure RBAC, determining who can perform cryptographic tasks.
• Key Attestation: You can receive cryptographic proof that a key was created and remains within the FIPS 140-3 Level 3 hardware environment.

Managed HSM relies on FIPS 140-3 Level 3 HSMs and confidential computing tech based on Intel SGX. This means that request processing, access control, and key data are isolated in hardware enclaves. No Microsoft operator, even those with administrative access, can read them. Managed HSM ensures redundancy, isolation, and protection, granting organizations the sovereign assurances they need without sacrificing key security, operational load, or availability.

What External Key Management Adds

While Managed HSM provides complete control over your keys, external key management offers an additional option: the ability to keep your key material on an HSM that you own and oversee, which can be on-premises or managed by a trusted third party, completely separate from Microsoft’s infrastructure.

External key management is particularly relevant in scenarios where regulations or contractual obligations dictate that cryptographic keys must exist outside of the cloud provider’s environment. This is often necessary in heavily regulated sectors, such as government, finance, and critical infrastructure, and in regions with strict data-sovereignty laws. You retain physical control of the root of trust and key material on hardware that you directly manage.

However, adopting this model should be a considered decision, ideally only when necessary. For most workloads, using Managed HSM keys is still the recommended strategy, as it offers greater availability, simpler operations, and a security stance that meets or exceeds sovereignty standards without introducing extra risks or management burden. External key management focuses on meeting specific regulatory requirements rather than enhancing fundamental security. When such regulations do not apply, Managed HSM proves to be a more effective, dependable, and operationally efficient choice.

How It Works

External key management expands the capabilities of Managed HSM with a dedicated API endpoint that directly connects to the HSM you control. This setup allows cryptographic operations in Azure to use your external key material without altering how your applications interact with the service. The external key never resides within, or even passes through, Microsoft infrastructure; only your hardware has access to it. Since you control that hardware, you can disconnect it whenever you wish, stopping all cryptographic operations.

• Integration is Seamless for Applications: Applications continue to utilise Managed HSM and the Azure Key Vault API without changes. When an application needs to decrypt local data encryption keys with your external key, Managed HSM simply forwards it to your hardware and returns the outcome.
• You Decide on Hardware and Partners: Given that the external key management API is an open specification, you have the flexibility to choose its implementation. The choice of hardware and partners is entirely yours.
• Secure Connections: All communications between Azure and your hardware are encrypted and mutually authenticated, ensuring a trusted connection between Azure and your HSM.

HSM Ecosystem

A growing range of HSM vendors support integration with the Managed HSM external key management API, with numerous providers currently working to enable compatibility with their platforms.

Microsoft does not manage or create the connecting integration proxy themselves. Instead, the model is open, allowing you to use an implementation provided by a vendor, partner with someone to operate it, or build your own solution.

Responsibilities and Trade-offs

Choosing external key management shifts a portion of the operational responsibility to you. This shift results from extending the trust boundary beyond Azure: you take on control of the root of trust, along with the responsibility to maintain the systems that uphold it.

• Availability of Your Hardware: The Managed HSM SLA only applies up to the point that it calls your external HSM proxy. The uptime of your hardware and proxy is your responsibility, meaning any interruptions can impact cryptographic operations and data access in Azure.
• Scope of Operations: External key management is focused on operations safeguarding data at rest. It doesn’t expose the full range of key functions available with Managed HSM, reflecting a conscious trade-off between control and capabilities.
• Hardware Operations: You are accountable for the provisioning, securing, scaling, monitoring, and recovery of your proxy and HSM, regardless of whether you handle it directly or through a partner.
• Error Transparency: Any failures from your end are logged in Managed HSM but diagnosing and fixing these issues remains your responsibility.

This is the essential trade-off: increased control brings about more responsibility.

Public Preview Scope

• Availability: The service is available across all Azure public regions during this public preview.
• Access: Access is gated. Your Microsoft account team will enable external key management on your Managed HSM, so reach out to them to request it.
• Use Case: This feature protects data at rest for Azure services that support customer-managed keys with Managed HSM.
• Pricing: You will be charged standard Managed HSM rates, with no additional fees from Microsoft. You will cover the expenses of your hardware and any needed partner licensing.

Get Started

External key management marks a significant step towards granting customers detailed control over how and where their keys are secured. During this public preview phase, we encourage you to provide feedback, which will directly influence the development of this feature towards general availability, including operational guidelines, vendor integrations, and future scenarios we should prioritise.