Azure Key Vault Managed HSM Single-Tenant Isolation and Key Sovereignty

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):

  1. Create HSM and specify initial administrators
  2. Wait for provisioning to complete (a few minutes)
  3. Download the security domain using three RSA certificates you generate
  4. Use Shamir's Secret Sharing to split the key across custodians
  5. Activate the HSM by uploading the security domain quorum
  6. 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:

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.

Archives