Azure Key Vault Managed Hardware Security Module (HSM) provides strong sovereignty over your encryption keys. Keys are generated and stored in a single-tenant, FIPS 140-3 Level 3 HSM that only you control: Microsoft has no access to your key material, and you govern who can use each key. For most organizations, including those with stringent regulatory requirements, this level of control is sufficient.
Some organizations have a further requirement: the hardware that holds their key must reside physically outside Azure datacenters. External key management for Azure Key Vault Managed HSM is now in public preview to address that requirement, delivering on a commitment made a year ago . Try External key management for Azure Key Vault Managed HSM How Managed HSM delivers sovereignty today Before looking at external key management, it’s worth being precise about the sovereignty Managed HSM already provides.
Managed HSM is a single-tenant service: each instance is a dedicated cluster of FIPS 140-3 Level 3 validated HSM partitions for each customer—built on Marvell LiquidSecurity adapters. Keys are generated inside that hardware and never leave it in plaintext, making the keys inaccessible to Microsoft operators. Control rests with you, not Microsoft: Customer-specific security domain.
Each HSM cluster is cryptographically isolated by a security domain that you generate and own. Microsoft can’t decrypt your key material or recover your HSM cluster without it. You are in full control of the security domain as it’s protection and safeguarding is outside of Microsoft.
Multiperson control. The security domain is protected by a quorum of RSA key pairs that you hold offline. Recovery requires your quorum, so no single person—and no Microsoft operator—can act alone.
Local role-based access control ( RBAC). A data-plane authorization model, independent of Azure RBAC , governs who can perform each cryptographic operation. Key attestation.
You can obtain cryptographic proof that a key was generated and is used within the FIPS 140-3 Level 3 hardware boundary. Managed HSM is built on FIPS 140-3 Level 3 HSMs and confidential computing technology based on Intel SGX, so request handling, access control, and key material are isolated in hardware enclaves and HSMs that no Microsoft operator—even one with administrative or physical access to the host—can read.
Managed HSM provides redundancy, isolation, and protection—giving organizations the sovereignty assurances they need without compromising on key security, operational overhead or availability. What external key management adds Managed HSM already provides full customer control over your keys, with enterprise-grade availability, security, and operational simplicity.
External key management adds one capability: the option to keep your key material on an HSM that you own and operate, either on-premises or with a trusted third party, completely outside Microsoft infrastructure. External key management is designed for scenarios where regulation or contractual obligations mandate the cryptographic keys must reside outside the cloud provider’s environment.
These requirements are sometimes found in highly regulated sectors such as government, financial services, and critical infrastructure, and in jurisdictions with strict data-sovereignty rules. External key management ensures the root of trust and key material remain on hardware you own and operate, outside Microsoft infrastructure, and under your direct physical control.
However, this model should only be adopted deliberately and only when required. For most workloads, Managed HSM keys remain the recommended approach, delivering higher native availability, reduced operational complexity, and a security posture that meets or exceeds sovereignty requirements without introducing additional risk or overhead. External key management is about meeting specific regulatory constraints, not increasing baseline security.
When those constraints do not apply, Managed HSM provides a stronger, more reliable, and more operationally efficient solution. How it works External key management extends Managed HSM through a dedicated API endpoint that connects directly to the HSM you control. It allows cryptographic operations in Azure to invoke external key material without changing how applications interact with the service.
The external key never resides in or passes through Microsoft infrastructure; only your hardware uses it. Because you control that hardware, you can disconnect it at any time to halt all cryptographic operations. Integration is transparent to applications.
Applications continue to use Managed HSM and the Azure Key Vault API with the customer-managed key envelope encryption pattern unchanged. When an data access requires your external key to decrypt local data encryption keys, Managed HSM forwards it to your hardware and returns the result. You choose the hardware and partner.
Because the external key management API is an open specification, you decide how to implement it. Your hardware, your partner, or your implementation. All connections are mutually authenticated and encrypted.
Traffic between Azure and your hardware is secured with mutual TLS, ensuring a secure and trusted connection between Azure and your HSM. HSM ecosystem A growing ecosystem of HSM vendors support integration with the Managed HSM external key management API, as many providers are actively enabling compatibility for their platforms. Microsoft doesn’t build or operate the connecting integration proxy itself.
Instead, you benefit from an open model: you can use a vendor provided implementation, reply on a partner to operate it, or build your own. Responsibilities and tradeoffs External key management deliberately shifts a portion of operational responsibility to you. This is the direct consequence of extending the trust boundary beyond Azure: you gain control over the root of trust, and with it, ownership of the systems that enforce it.
Originally published at azure.microsoft.com
