With increasing security requirements, organizations are moving towards hardware-backed key management using Azure Key Vault Managed HSM. In this blog, we’ll walk through how to: - Deploy Azure resources using customer-managed keys (CMK) stored in Managed HSM - Automate the entire setup using Azure Bicep - Handle identity, access policies, and encryption configuration
Architecture Overview
The deployment includes:
- Managed HSM instance
- Key creation inside HSM
- User-assigned managed identity / service principal
- Role assignments for key access
- Azure resource (e.g., Storage / Databricks / Disk) using CMK
Flow:
- Create Managed HSM
- Create encryption key
- Assign permissions
- Deploy resource with CMK reference
Prerequisites
Before starting, ensure:
- Azure subscription with proper permissions
- Access to create Managed HSM
- Knowledge of RBAC vs access policies
- Bicep CLI installed
Step 1: Deploy Managed HSM
Managed HSM is different from regular Key Vault:
- Uses RBAC only (no access policies)
- Requires security domain initialization
Bicep snippet:
|
resource managedHsm 'Microsoft.KeyVault/managedHSMs@2023-02-01' = { name: hsmName location: location sku: { name: 'Standard_B1' family: 'B' } properties: { tenantId: tenant().tenantId initialAdminObjectIds: [ adminObjectId ] } } |
Step 2: Create Key in Managed HSM
|
resource key 'Microsoft.KeyVault/managedHSMs/keys@2023-02-01' = { name: '${managedHsm.name}/cmk-key' properties: { kty: 'RSA-HSM' keySize: 2048 } } |
Step 3: Assign Permissions
Since Managed HSM uses RBAC, assign roles like:
- Managed HSM Crypto User
- Managed HSM Crypto Officer
|
resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = { name: guid(resourceGroup().id, principalId, roleDefinitionId) properties: { principalId: principalId roleDefinitionId: roleDefinitionId scope: managedHsm } } |
Step 4: Configure Resource with CMK
Example: Storage Account encryption
|
resource storage 'Microsoft.Storage/storageAccounts@2023-01-01' = { name: storageName location: location kind: 'StorageV2' sku: { name: 'Standard_LRS' } properties: { encryption: { keySource: 'Microsoft.Keyvault' keyvaultproperties: { keyname: key.name keyvaulturi: managedHsm.properties.hsmUri } } } } |
Common Challenges
1. Permission Issues
- Resource identity must have access to HSM key
- Missing role → deployment failure
2. Key Rotation Impact
When keys are rotated:
- Resource may not automatically pick latest version
- You may need to redeploy or update configuration
3. Deployment Errors
Typical issue:
Storage/Databricks cannot access HSM key
Fix:
- Ensure correct RBAC role assignment
- Validate principal ID used during deployment
Key Rotation Strategy
Managed HSM supports:
- Manual rotation
- Rotation policies
Best practice:
- Use version-less key URI if supported
- Automate redeployment pipeline
When to Use Managed HSM vs Key Vault
| Feature | Managed HSM | Key Vault |
|---|---|---|
| FIPS Level | Level 3 | Level 2 |
| Multi-tenant isolation | No (dedicated) | Yes |
| RBAC only | Yes | Optional |
| Cost | Higher | Lower |
Conclusion
Using Managed HSM with Bicep enables:
- Stronger security with hardware-backed keys
- Full automation via Infrastructure as Code
- Enterprise-grade compliance
However, it requires careful handling of:
- RBAC permissions
- Key rotation
- Resource integration
Microsoft