Executive Overview: Redefining Cloud Boundaries and Key Sovereignty
In a strategic bid to address the most stringent global compliance requirements, Microsoft has officially launched the public preview of External Key Management for Azure Key Vault Managed Hardware Security Module (HSM). This capability marks a pivotal shift in cloud security architecture, directly fulfilling a high-profile sovereign solutions commitment made by the technology giant last year to European enterprise customers and regulatory bodies.
While Azure Key Vault Managed HSM has historically provided dedicated, single-tenant FIPS 140-3 Level 3 cryptographic protection within Microsoft’s cloud footprint, certain highly regulated organizations—including government entities, defense contractors, central banks, and critical infrastructure operators—face legal or contractual mandates requiring complete physical detachment from cloud infrastructure. The newly introduced External Key Management feature resolves this tension by allowing organizations to generate, store, and maintain their root encryption keys entirely on hardware they physical own and operate outside Azure datacenters.
+--------------------------------------------------------------+
| CUSTOMER CONTROLLED ENVIRONMENT |
| +------------------------+ +------------------------+ |
| | On-Premises / Vendor | | Vendor Integration | |
| | Physical HSM | <--->| Proxy / REST API | |
| +------------------------+ +------------------------+ |
+----------------------------------------------^---------------+
| Secure TLS
| Remote Procedure Call
+----------------------------------------------v---------------+
| AZURE INFRASTRUCTURE |
| +--------------------------------------------------------+ |
| | Azure Key Vault Managed HSM Instance | |
| | +--------------------------------------------------+ | |
| | | Confidential Computing Enclave (Intel SGX) | | |
| | | Handles App Requests & Coordinates External Ops | | |
| | +--------------------------------------------------+ | |
| +--------------------------------------------------------+ |
| |
| +--------------------------------------------------------+ |
| | Azure Workloads & Services | |
| | (Storage, SQL Azure, Compute, etc.) | |
| +--------------------------------------------------------+ |
+--------------------------------------------------------------+Under this model, cryptographically enforced operations inside Azure delegate key usage to external, physical HSMs via a dedicated API endpoint. The root key material never passes through, resides in, or touches Microsoft infrastructure in plaintext or ciphertext form. Consequently, enterprise security teams retain an absolute operational lever: the ability to unilaterally sever connection to the external HSM, instantly neutralizing all associated cryptographic and data processing activities across their Azure ecosystem.
Chronology of Azure’s Key Sovereignty Evolution
The release of External Key Management represents the culmination of a multi-year evolutionary arc in cloud encryption, driven by evolving regulatory framework obligations such as the European Union’s Digital Operational Resilience Act (DORA), NIS2, and the aftermath of Schrems II rulings.
+-------------------------------------------------------------------------+
| EVOLUTION OF AZURE KEY MANAGEMENT & SOVEREIGNTY |
+-------------------------------------------------------------------------+
| Phase 1: Shared Key Vault (Software & Multi-Tenant HSMs) |
| - Multi-tenant physical security; logical tenant segregation |
+-------------------------------------------------------------------------+
| Phase 2: Bring Your Own Key (BYOK) |
| - Secure import of customer-generated keys into Azure HSMs |
+-------------------------------------------------------------------------+
| Phase 3: Single-Tenant Managed HSM |
| - Dedicated Marvell LiquidSecurity hardware; FIPS 140-3 Level 3 |
| - Hardware isolation via Intel SGX Confidential Enclaves |
+-------------------------------------------------------------------------+
| Phase 4: Sovereign Cloud Commitments (June 2025) |
| - Strategic pledge to deliver total operational & key sovereignty |
+-------------------------------------------------------------------------+
| Phase 5: Public Preview of External Key Management (Present) |
| - Hold Your Own Key (HYOK) architecture launched globally |
+-------------------------------------------------------------------------+Phase 1: Multi-Tenant Key Vault Infrastructure
In the early iterations of Azure, key management relied heavily on multi-tenant architecture. Cryptographic operations were backed by software mechanisms or shared physical HSMs where logical boundaries separated tenant workloads. While sufficient for general enterprise workloads, it offered limited cryptographic control for regulated sectors.
Phase 2: Bring Your Own Key (BYOK) Standardization
To give customers greater confidence, Microsoft introduced Bring Your Own Key (BYOK) mechanisms. This permitted enterprises to generate keys in their local HSMs and securely transfer them into Azure’s hardware ecosystem using secure key-exchange protocols. However, once imported, the operational execution still resided entirely on cloud-hosted hardware.
Phase 3: Native Managed HSM and Confidential Computing
Addressing strict single-tenancy needs, Microsoft deployed Azure Key Vault Managed HSM. Built on dedicated Marvell LiquidSecurity adapters and backed by Intel SGX confidential computing enclaves, this service isolated customer key partitions at the hardware level. It guaranteed that even Microsoft administrators with root physical access to hypervisors could not inspect or exfiltrate key material.
Phase 4: The European Sovereignty Pledge
A year ago, amid mounting geopolitical debates regarding digital sovereignty and data localization in Europe and APAC, Microsoft publicly committed to delivering a comprehensive suite of sovereign cloud controls. A primary milestone in this pledge was the explicit promise to provide a native "Hold Your Own Key" (HYOK) paradigm for Azure Key Vault.
Phase 5: External Key Management Public Preview
With today’s public preview rollout, Microsoft fulfills that commitment. The integration extends the native Managed HSM control plane to communicate out-of-band with external physical security appliances located in customer-owned datacenters or third-party colocation facilities.
Supporting Context, Architecture, and Metrics
To evaluate the impact of this release, enterprise security architects must analyze the underlying technical mechanics, hardware security specifications, and performance trade-offs associated with offloading cryptographic roots of trust outside the hyper-scaler boundary.
Technical Mechanics: How External Key Management Operates
External Key Management operates by converting the Azure Key Vault Managed HSM instance into an orchestration and validation boundary that proxies request flows to an external endpoint:
- API Endpoint Invocation: Applications or Azure native services (such as Azure Storage Encryption, Azure SQL Transparent Data Encryption, or confidential virtual machines) issue a standard REST API call to Managed HSM requesting an operation (e.g., wrap key, unwrap key, sign, or decrypt).
- Proxy Forwarding: Rather than processing the operation inside its native Marvell LiquidSecurity partition, Managed HSM routes the cryptographic payload to a customer-hosted or partner-hosted Integration Proxy via a secure, mutual TLS (mTLS) channel.
- External HSM Execution: The Integration Proxy converts the payload into the native protocol (such as PKCS#11 or proprietary REST APIs) required by the customer’s physical HSM. The physical HSM performs the operation using the localized root key material.
- Encrypted Return: The cryptographically transformed response is sent back through the proxy to Managed HSM, which completes the transaction for the requesting Azure service.
At no point in this request lifecycle does the unencrypted root key material cross the boundary from the customer’s physical premises into Azure.
+-----------------------------------------------------------------------------------+
| COMPARATIVE ANALYSIS: NATIVE VS. EXTERNAL MANAGED HSM |
+-----------------------------------------------------------------------------------+
| Architectural Metric | Native Azure Managed HSM | External Key Management |
+----------------------------+------------------------------+-----------------------+
| Physical Key Location | Azure Datacenters | Customer On-Prem/Colo |
| Hardware Isolation Level | Dedicated Single-Tenant Partition | Customer Owned Hardware |
| Cryptographic Validation | FIPS 140-3 Level 3 | Vendor/Customer Defined|
| Confidential Compute Base | Intel SGX Hardware Enclaves | On-Premises Architecture|
| Microsoft Administrative Access | Cryptographically Blocked| Physical & Network Blocked|
| Round-Trip Network Latency | Ultra-Low (<2-5 ms) | Variable (15-100+ ms) |
| Native Service SLA | 99.99% Availability | Dependent on On-Prem Infrastructure |
| "Kill Switch" Capability | Policy / Access Revocation | Immediate Physical Network Severance |
+-----------------------------------------------------------------------------------+The Hardware Enclave Foundation
For workloads that remain on Native Managed HSM, Microsoft relies on a combination of Marvell LiquidSecurity HSM adapters and Intel SGX (Software Guard Extensions) enclaves. This architecture creates an isolated memory region (Enclave Page Cache) that encrypts code and data in transit through CPU-level hardware mechanisms.
External Key Management builds atop this base by allowing the enclave software to act as the client caller to external hardware. However, shifting the root cryptographic material external to Azure introduces significant infrastructure variables:
- Latency Overhead: Native Managed HSM operations execute within the same datacenter fabric, yielding single-digit millisecond latency. External key management introduces network round-trips over express connections (e.g., Azure ExpressRoute) or encrypted internet channels, adding latency penalties ranging from 15 to over 100 milliseconds per operation depending on geographic distance.
- Availability Dependencies: High availability transitions from a Microsoft-backed 99.99% service level agreement (SLA) to a shared responsibility model. If a customer’s on-premises network, proxy layer, or local HSM clusters experience an outage, dependent Azure workloads—such as database clusters or encrypted storage volumes—will immediately fail to process cryptographic requests.
+------------------------------------------------------------------------------+
| RESPONSIBILITY MATRIX (SHARED MODEL) |
+------------------------------------------------------------------------------+
| Security Domain | Managed HSM Native | External Key Management|
+--------------------------+--------------------------+------------------------+
| Physical Hardware Security| Managed by Microsoft | Managed by Customer |
| HSM Patching & Firmware | Managed by Microsoft | Managed by Customer |
| Proxy Layer Availability | N/A | Managed by Customer/Partner |
| Cloud Key Policy | Managed by Customer | Managed by Customer |
| Root Key Material Backup | Automated by Azure | Managed by Customer |
| Network Connectivity | Managed by Microsoft | Customer ExpressRoute/WAN |
+------------------------------------------------------------------------------+Vendor Ecosystem and Proxy Architecture
To avoid vendor lock-in, Microsoft has avoided releasing a proprietary, closed connection agent. Instead, Microsoft published an open Integration Proxy Specification. This allows organizations to choose from three distinct deployment paths:
- Vendor-Provided Proxies: Turnkey solutions from established HSM manufacturers—including Thales, Entrust, Fortanix, and Utimaco—that natively translate Azure Managed HSM requests to their respective physical appliances.
- Managed Partner Services: Proxy infrastructure operated by regional systems integrators or specialized cloud service providers who manage high-availability operations on behalf of the enterprise.
- Custom Internal Build: In-house developed proxies built against Microsoft’s open API specifications, tailored to legacy or proprietary cryptographic hardware.
Official Statements and Industry Perspectives
The announcement has drawn significant attention from enterprise architects, regulatory analysts, and cybersecurity officers evaluating the trade-offs between ultimate control and operational overhead.
In official documentation accompanying the preview release, Microsoft’s Cloud Security Engineering Group emphasized both the power and the deliberate trade-offs of the technology:
"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… 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."
The engineering team explicitly noted that External Key Management is not inherently designed to increase baseline cryptographic strength, but rather to fulfill specific compliance demands:
"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… External key management is about meeting specific regulatory constraints, not increasing baseline security."
Industry analysts concur with this assessment. Chief Information Security Officers (CISOs) in the financial services sector have noted that while the "Hold Your Own Key" strategy solves strict cross-border regulatory concerns, it requires rigorous architectural management.
"When you extend the cryptographic trust boundary out of hyperscale datacenters and back into your own, you become the primary variable in service availability," stated a senior cybersecurity analyst covering cloud compliance. "If your external HSM proxy drops offline, your cloud-hosted database reading that encrypted storage stops working. It is the ultimate expression of control, but it demands carrier-grade operational maturity on-premises."
Future Outlook: Strategic Imperatives and the GA Roadmap
As Azure Key Vault External Key Management moves through its public preview phase, Microsoft plans to iteratively refine the service based on real-world enterprise telemetry, vendor proxy validations, and latency optimization feedback.
Key Milestones on the Path to General Availability (GA)
- Expanded Partner Certification: Formal certification programs for third-party HSM vendors to ensure out-of-the-box compatibility with zero-trust network configurations.
- Enhanced Diagnostic Tooling: Integration of specialized Azure Monitor metrics and event logging to isolate network latency, proxy errors, and target HSM failures in real time.
- Azure Service Ecosystem Integration: Broader compatibility validation across high-throughput data services, ensuring seamless operation with complex workload structures such as Azure Databricks, Cosmos DB, and Confidential Virtual Machine disks.
The Broader Market Context
With this release, Microsoft strengthens its competitive standing against rivals AWS (which offers AWS KMS External Key Store – XKS) and Google Cloud (which provides Google Cloud External Key Manager – EKM). By anchoring its solution inside the established single-tenant Azure Key Vault Managed HSM platform—and leveraging its Intel SGX confidential computing foundation—Microsoft aims to capture highly regulated European, Asian, and North American public sector accounts that previously stalled cloud migrations due to data sovereignty deadlocks.
For enterprise IT leaders, the rollout offers a clear decision framework:
+----------------------------------------------+
| Does regulation or contract dictate physical|
| key retention outside cloud datacenters? |
+----------------------+-----------------------+
|
+-----------------+-----------------+
| |
YES NO
| |
v v
+----------------------------------------------+ +----------------------------------+
| Deploy External Key Management | | Deploy Native Azure Managed HSM |
| - High control over key material | | - Maximize service availability |
| - Increased management responsibility | | - Minimal operational complexity |
| - Additional latency overhead | | - Native sub-5ms performance |
+----------------------------------------------+ +----------------------------------+As digital sovereignty compliance requirements continue to expand globally, tools like Azure External Key Management mark a structural transition in enterprise cloud architecture—enabling organizations to leverage hyperscale cloud computing capacity without relinquishing ultimate authority over their cryptographic assets.
