Azure Key Vault Managed HSM: Single-Tenant Isolation & Key Sovereignty - Part 2

If Part 1 on Azure Key Vault Premium left you asking "But what if we need complete control over our encryption keys?" You're asking exactly the right question. Welcome to Part 2, where we explore Azure Key Vault Managed HSM, the service built specifically for organizations that require key sovereignty and single-tenant isolation.
The fundamental shift here is control. With Managed HSM, your organization has exclusive authority over the cryptographic boundary, the keys, and the security domain. Microsoft operates the infrastructure, but has no technical means to access your key material.
What is Azure Key Vault Managed HSM?
Azure Key Vault Managed HSM is a single-tenant, fully managed cloud service that provides exclusive control over a dedicated Hardware Security Module (HSM) instance. Unlike Premium tier where you share HSM infrastructure, Managed HSM provisions three dedicated HSM partitions exclusively for your organization, acting as one logical appliance.
Key characteristics:
- Single-tenant architecture - Exclusive HSM partition(s) dedicated to your organization
- FIPS 140-3 Level 3 compliance - Highest civilian security standard for cryptographic modules
- Marvell LiquidSecurity HSM with Intel SGX - Specialized hardware combined with secure enclaves
- Customer controls root of trust - YOU generate, manage, and control the security domain
- Zero-access guarantee - Microsoft has no technical means to access your keys
- Triple-redundant architecture - Three HSM instances across different datacenters for availability
Key Sovereignty: The Core Differentiator
This is the moment where Managed HSM becomes essential for certain organizations. Key sovereignty means:
Your organization has full and exclusive control over:
- Who can access keys and change key management policies
- What Azure services consume these keys
- The cryptographic root of trust (the security domain)
- Key generation, rotation, and deletion
- Role-based access even Microsoft cannot override
This is not a soft capability—it's enforced at the cryptographic boundaries. Microsoft personnel are technically prevented from accessing your key material, even with high-level Azure administrative privileges. The isolation is built into the hardware and encryption layers.
Single-Tenant Cryptographic Isolation
Here's how the physical isolation works:
| Aspect | Azure Key Vault Premium | Managed HSM |
|---|---|---|
| Hardware Sharing | Shared Marvell LiquidSecurity HSM adapters across customers | Dedicated HSM partition(s) exclusively for your org |
| Root of Trust | Microsoft controls root keys | Customer controls security domain (root keys) |
| Physical Isolation | Logical isolation via cryptographic boundaries | Physical HSM partition + cryptographic boundary + TEE |
| Microsoft Access | Technical means to request keys (with legal process) | No technical means to access keys—cryptographically prevented |
| Architecture | Multitenant | Single-tenant with triple redundancy |
The Managed HSM partitions are created during provisioning and are exclusive to you. Even if Azure infrastructure team members have physical access to the servers, they cannot access your HSM partition without the security domain you control.
The Security Domain: Your Cryptographic Root of Trust
The security domain is a concept unique to Managed HSM. It's an encrypted blob containing:
- HSM backup material
- User credentials
- The signing key for your HSM partition
- The data encryption key unique to your managed HSM
This security domain is generated in the HSM and in the service software enclaves (Intel SGX). After provisioning, you download it to your organization's secure location. Microsoft has no way of recovering the security domain, making it the true expression of your key sovereignty.
Important: When you download the security domain during HSM activation, you're protecting it with RSA key pairs you generate. Using Shamir's Secret Sharing, you can split the security domain across multiple custodians, requiring a quorum (e.g., 3 of 5) to recover it.
FIPS 140-3 Level 3 and Physical Security Controls
Managed HSM's FIPS 140-3 Level 3 validation goes beyond software compliance. The physical security controls include:
- Hardened epoxy and metal casing - Tamper-resistant hardware enclosures
- Dedicated cryptographic processor - Specialized CPU for cryptographic operations
- High-entropy generation - Secure random number generation
- Physical access controls - Servers locked in cages, cameras monitoring 24/7, biometric access
- Geographically dispersed datacenters - Your three HSM instances in different racks across regions
- Trusted execution environment (TEE) - Intel SGX enclaves prevent even host OS access to key material
These controls meet FedRAMP-High, PCI DSS, SOC 1/2/3, ISO 27001, and NIST SP 800-53 standards—making Managed HSM suitable for:
- Financial services and investment banking
- Government and defense contracting
- Healthcare organizations (HIPAA)
- Organizations subject to strict regulatory audits
Encryption Capabilities
Managed HSM supports the full range of cryptographic operations needed for enterprise scenarios:
| Key Type | Supported Algorithms | Use Cases |
|---|---|---|
| RSA Keys | 2048-bit, 3072-bit, 4096-bit | Encryption, signing, TLS offload |
| Elliptic Curve | P-256, P-384, P-521 | High-performance signing |
| Symmetric Keys | AES (128, 192, 256-bit) | Direct encryption, key wrapping |
Most importantly, you own the key material. Keys generated in HSM partitions are non-extractable by default—they never exist in plaintext outside the HSM boundary.
Access Control: Two-Plane Model with Separation of Duties
Managed HSM enforces strict separation of duties:
- Control plane: Managing the HSM itself (create, delete, properties) - Azure RBAC via Azure Resource Manager
- Data plane: Accessing keys and performing cryptographic operations - Managed HSM local RBAC, enforced at the HSM level
Critical: A subscription administrator with full Azure RBAC cannot access your keys unless explicitly granted data-plane permissions through Managed HSM local RBAC. This is enforced at the HSM firmware level, not just policy level.
You can assign role-based permissions directly in the Managed HSM itself:
- Managed HSM Administrator - Full control (key lifecycle, role assignments, security domain)
- Managed HSM Crypto User - Can use keys for cryptographic operations
- Managed HSM Crypto Officer - Can create/manage keys
- Custom roles - Define granular permissions for separation of duties
Pricing Model: Fixed Hourly Rate
Managed HSM uses fixed hourly billing from the moment of provisioning:
- Single fixed rate per HSM (not per key or per operation)
- Covers unlimited cryptographic operations
- Triple-redundant infrastructure included
- Current pricing is roughly $2,000 - $2,500 per month per HSM
This is ideal for organizations that:
- Need predictable costs and capacity planning
- Have high-volume cryptographic operations
- Can't tolerate per-operation billing surprises
- Require dedicated cryptographic infrastructure
Important: Managed HSM charges from the moment of provisioning. Even if you immediately deprovision it, you'll be billed for that day. Deprovisioning only puts the HSM in soft-delete state; you must purge it separately to stop charges.
High Availability and Confidential Service Healing
Managed HSM automatically maintains high availability through three mechanisms:
- Triple redundancy: Three HSM instances across different racks and availability zones
- Automatic synchronization: Instances stay in sync through attested TLS connections
- Confidential service healing: If one instance fails, Azure automatically provisions a replacement without exposing keys
The healing process is "confidential"—the new instance is added to the pool and synchronized with the existing instances using cryptographic attestation, all without plaintext key exposure. Even Microsoft cannot access the key material during this healing process.
Bring Your Own Key (BYOK)
For organizations with strict regulatory requirements to generate keys on-premises, Managed HSM supports BYOK:
- Generate keys in your on-premises HSM
- Securely import them into the Managed HSM
- Key material never exists in plaintext outside an HSM
- Maintain compliance with "generate internally" requirements
Key Rotation and Lifecycle Management
Like Premium tier, Managed HSM supports automatic key rotation:
- Set rotation policies (rotate every 90 days, annually, etc.)
- Automatic version creation without service interruption
- Manual rotation on demand
- NIST recommendation: rotate at least every 2 years (3 months for actively used keys)
Integration with Azure Services
Managed HSM integrates with:
- Azure SQL Database & Managed Instance: Transparent Data Encryption (TDE)
- Azure Storage: Customer-managed key encryption
- Microsoft 365: Customer Key for enterprise encryption
- Azure Information Protection: Data classification and protection
- F5 and Nginx: TLS/SSL offloading with keyless infrastructure
Provisioning Managed HSM: What to Know
Before provisioning, understand the prerequisites:
Cost commitment: Managed HSM will cost money from the moment of provisioning. There's a separate check box during creation to confirm this.
Provisioning steps (via Azure Portal or CLI):
- Create HSM and specify initial administrators
- Wait for provisioning to complete (a few minutes)
- Download the security domain using three RSA certificates you generate
- Use Shamir's Secret Sharing to split the key across custodians
- Activate the HSM by uploading the security domain quorum
- Create or import cryptographic keys
Deprovisioning and Soft Delete
This is the gotcha that caught many organizations:
Deprovisioning does NOT immediately stop billing. When you delete a Managed HSM, here's what happens:
- It enters soft-delete state (recoverable for 90 days)
- You continue to be billed during soft-delete period
- You must explicitly PURGE it to stop charges
- If your subscription is disabled, you cannot purge until you re-enable it
If you need to delete an HSM with a disabled subscription:
# Enable subscription az account show --subscription SUBSCRIPTIONID --query state # List soft-deleted HSMs az keyvault list-deleted --subscription SUBSCRIPTIONID --resource-type hsm # Purge the deleted HSM az keyvault purge --hsm-name HSMNAME --location westus3 --subscription SUBSCRIPTIONID
How to Remove Managed HSM
You tried it, but now you want to remove it. Well, that won't be super easy, but here's how—and I found at least one reason why.
When you deprovision the HSM, your subscription must be in Enabled state. Otherwise, you'll get an error:
(ProviderError) Resource provider 'Microsoft.KeyVault' failed to return collection response for type 'deletedManagedHSMs'.
Code: ProviderError
Message: Resource provider 'Microsoft.KeyVault' failed to return collection response for type 'deletedManagedHSMs'.
If your subscription is in Disabled state, here's how to fix it:
# Check subscription state az account show --subscription SUBSCRIPTIONID --query state # List deleted HSMs from the subscription az keyvault list-deleted --subscription SUBSCRIPTIONID --resource-type hsm # Delete the HSM from your subscription az keyvault delete --hsm-name HSMNAME --location westus3 --subscription SUBSCRIPTIONID # Purge the deleted HSM (stops billing) az keyvault purge --hsm-name HSMNAME --location westus3 --subscription SUBSCRIPTIONID # Remove the resource group az group delete --name YourResourceGroup
Important: Deleting the resource group puts the Managed HSM into soft-deleted state, but billing continues. You must explicitly PURGE the HSM to stop charges and fully remove it.
If your subscription is active, removal is straightforward through the Azure Portal or a simple Azure CLI delete command.
When to Choose Azure Key Vault Managed HSM
Select Managed HSM if:
- ✓ You require key sovereignty - exclusive control over keys and security domain
- ✓ Your organization must control the root of trust
- ✓ You're in highly regulated industries (finance, defense, government)
- ✓ Compliance requires single-tenant infrastructure
- ✓ You have high-volume cryptographic operations (fixed pricing is more economical)
- ✓ You need strict separation of duties with HSM-level enforcement
- ✓ You generate keys on-premises and import via BYOK
- ✓ You require disaster recovery with customer-controlled security domain
Do NOT choose Managed HSM if:
- ✗ You want to minimize operational overhead (Premium tier simpler)
- ✗ You have low-volume key operations (Premium transactional pricing better)
- ✗ Your organization can accept Microsoft having technical access capability
- ✗ You're just starting with cloud and need to learn gradually
Premium vs Managed HSM: A Quick Reference
| Aspect | Key Vault Premium | Managed HSM |
|---|---|---|
| Tenancy | Multitenant | Single-tenant |
| FIPS Compliance | FIPS 140-3 Level 3 | FIPS 140-3 Level 3 |
| Root of Trust | Microsoft | Customer (you) |
| Billing | Transactional (per key + per operation) | Fixed hourly rate |
| Cost (approx) | $1-2/key/month + operations | ~$2,000-2,500/month |
| Best For | Moderate keys, compliance baseline | Key sovereignty, high volume, strict compliance |
| Operational Complexity | Low | Medium (security domain management) |
| Disaster Recovery | Azure-managed backup/restore | Customer-managed security domain |
Resources for Managed HSM
For implementation and deeper learning:
- What is Azure Key Vault Managed HSM?
- Control Your Data in the Cloud Using Managed HSM
- Key Sovereignty, Availability, Performance in Managed HSM
- Access Control for Managed HSM
- Configure Key Autorotation in Managed HSM
- How to Choose the Right Key Management Solution
Conclusion: Key Sovereignty is Worth the Investment
The journey from Azure Key Vault Premium to Managed HSM is really a journey toward control and accountability. For organizations with strict compliance mandates or those handling sensitive data at scale, the investment in Managed HSM is justified by the security guarantees and operational control it provides.
The choice between Premium and Managed HSM isn't just technical—it's a statement about your organization's security posture and your relationship with cloud infrastructure ownership.