Azure Key Vault Managed HSM External Key Management Enters Public Preview, Offering Unprecedented Control Over Cryptographic Keys
Microsoft has officially launched the public preview of External Key Management for Azure Key Vault Managed Hardware Security Module (HSM), a significant advancement in cloud security that grants organizations granular control over their cryptographic keys. This new capability addresses a growing demand from highly regulated industries and specific geopolitical regions for the ability to maintain physical control of the hardware housing their most sensitive encryption keys, even while leveraging Azure’s cloud services. The announcement marks a fulfillment of a commitment made by Microsoft approximately one year ago, underscoring their dedication to providing comprehensive sovereign solutions for their global customer base.
The introduction of external key management directly caters to a niche but critical requirement: the physical isolation of key material from cloud provider datacenters. While Azure Key Vault Managed HSM has long provided robust key sovereignty through its single-tenant, FIPS 140-3 Level 3 certified HSMs, where Microsoft has no access to customer key material, some organizations face regulatory mandates or stringent internal policies that necessitate keys residing on hardware entirely outside of Azure’s physical infrastructure. This new offering ensures that the root of trust and the cryptographic keys themselves remain on HSMs that the customer owns and operates, either on-premises or with a trusted third-party provider, completely independent of Microsoft’s managed environments.
Understanding the Foundation: Azure Key Vault Managed HSM’s Sovereignty Today
To fully appreciate the significance of external key management, it is crucial to understand the robust sovereignty already offered by Azure Key Vault Managed HSM. This service is architected as a single-tenant solution, meaning each customer instance is a dedicated cluster of FIPS 140-3 Level 3 validated HSM partitions. These partitions are built upon Marvell LiquidSecurity adapters, industry-leading hardware designed for secure key generation and storage. A fundamental tenet of Managed HSM is that keys are generated and processed exclusively within this dedicated hardware and never leave it in plaintext. This inherent design prevents any Microsoft operator, regardless of their administrative or physical access privileges to the underlying infrastructure, from accessing or viewing customer key material.
The control over cryptographic keys rests firmly with the customer, not with Microsoft. This is achieved through a multi-layered security approach. Managed HSM leverages confidential computing technology, including Intel SGX, to ensure that request handling, access control policies, and the sensitive key material itself are isolated within hardware enclaves and the HSMs. This isolation creates a secure boundary that is impenetrable even to privileged Microsoft personnel. The service provides inherent redundancy and operational resilience, ensuring high availability and protection of key assets without compromising on security, introducing significant operational overhead, or impacting service uptime. For the vast majority of organizations, including those operating under stringent regulatory frameworks like GDPR, HIPAA, or PCI DSS, the sovereignty assurances provided by the standard Managed HSM offering are more than sufficient.
The Evolution: What External Key Management Adds
External key management builds upon the already strong foundation of Managed HSM by introducing a critical new capability: the option to externalize the physical location of the key material. While Managed HSM already provides comprehensive customer control, enterprise-grade availability, robust security, and operational simplicity, external key management specifically addresses scenarios where regulatory or contractual obligations mandate that cryptographic keys must reside outside the cloud provider’s direct control.
This requirement is particularly prevalent in highly regulated sectors such as government, defense, financial services, and critical infrastructure. Jurisdictions with strict data sovereignty laws also drive this need. External key management ensures that the ultimate root of trust and the sensitive key material remain on hardware that the customer owns and operates, thus placing it outside Microsoft’s infrastructure and under their direct physical stewardship.
However, Microsoft emphasizes that this model is intended for specific use cases and should be adopted deliberately, only when mandated. For the majority of cloud workloads, the native Managed HSM remains the recommended approach. This is due to its superior native availability, significantly reduced operational complexity, and a security posture that meets or exceeds most sovereignty requirements without introducing additional risks or overhead. External key management is positioned as a solution for meeting specific, stringent regulatory constraints, rather than an enhancement to baseline security. When such constraints are not in play, the native Managed HSM offers a more robust, reliable, and operationally efficient solution.
The Mechanics of External Key Management
The operational flow of external key management is designed to be seamless for application developers while maintaining strict isolation for key material. It extends the capabilities of Managed HSM through a dedicated API endpoint. This endpoint establishes a secure connection directly to the customer-controlled HSM, whether it is located on-premises or with a third-party provider.
This integration allows cryptographic operations initiated within Azure to securely invoke and utilize external key material. Critically, applications interacting with Azure services do not need to be modified to accommodate this change; they continue to interact with Azure Key Vault in the same manner. The external key material itself never resides within or traverses Microsoft’s infrastructure. Instead, it is exclusively utilized by the customer’s own hardware. Because the customer retains direct control over this external hardware, they possess the ability to disconnect it at any time, effectively halting all cryptographic operations that rely on those keys, thereby offering an ultimate level of control.
An Expanding Ecosystem for Hardware Security Modules
To facilitate this new paradigm, Microsoft is fostering a growing ecosystem of Hardware Security Module (HSM) vendors. A significant number of providers are actively working to ensure compatibility with the Managed HSM external key management API. This collaborative approach allows customers to leverage existing or preferred HSM solutions.
Microsoft’s strategy here is notable: the company itself does not build or operate the "connecting integration proxy" that bridges Azure and the external HSM. Instead, it champions an open model. Customers have the flexibility to choose from vendor-provided implementations, engage with partners to manage the integration, or even develop their own custom solutions. This empowers organizations to select the approach that best aligns with their technical expertise, operational capabilities, and existing vendor relationships.
Navigating Responsibilities and Trade-offs
The introduction of external key management represents a deliberate shift in operational responsibility. By extending the trust boundary beyond Azure’s managed environment, customers gain direct control over the root of trust. However, this increased control inherently brings with it the ownership and management of the systems that enforce that trust.
The core trade-off is clear: enhanced control necessitates increased responsibility. Customers adopting external key management will be responsible for the provisioning, configuration, maintenance, and security of their on-premises or third-party HSM infrastructure. This includes ensuring the physical security of the hardware, managing access controls to the HSM itself, performing regular software and firmware updates, and maintaining the overall operational health of the system. This stands in contrast to the fully managed nature of the native Azure Key Vault Managed HSM, where Microsoft assumes these operational burdens.
Public Preview Scope and Future Development
The public preview phase is a critical period for gathering feedback and refining the external key management offering. During this phase, Microsoft is actively soliciting input from early adopters. This feedback will directly influence the feature’s development path towards general availability, including the prioritization of operational guidance, the expansion of vendor integrations, and the identification of key scenarios to focus on.
Getting Started with Enhanced Key Sovereignty
For organizations that require the utmost control over their cryptographic keys, the public preview of Azure Key Vault Managed HSM External Key Management offers a compelling solution. To begin, customers will need to set up their own FIPS 140-2 or FIPS 140-3 compliant HSMs, ensuring they meet the required security standards. Following this, they will need to configure the integration between their HSM and Azure, likely involving the deployment of an integration proxy or utilizing a vendor-provided solution. Detailed documentation and guidance are available from Microsoft to assist with this process.
This new offering represents the latest stride in Microsoft’s ongoing commitment to providing customers with granular control over the protection of their sensitive data. By allowing organizations to dictate not only how their keys are protected but also where the underlying hardware resides, Microsoft is empowering businesses to navigate complex regulatory landscapes and meet their unique sovereignty requirements with greater confidence. The public preview phase is an opportune moment for organizations to explore this advanced capability and contribute to its evolution.
