This chapter covers the critical differences between Azure Key Vault (Standard and Premium tiers) and Azure Managed HSM, focusing on their security boundaries, key management capabilities, compliance certifications, and appropriate use cases. Understanding these distinctions is essential for the AZ-500 exam, as questions on key management and secret storage appear frequently, accounting for approximately 10-15% of the exam. You will learn exactly what each service offers, how they differ under the hood, and which scenarios demand the higher assurance of Managed HSM.
Jump to a section
Imagine a company with two storage systems for sensitive documents. The first is a standard filing cabinet in a locked office (Key Vault Standard). It has a simple lock that can be opened with a key held by several employees. The filing cabinet can hold many documents, but the lock mechanism is relatively simple and the keys are managed by the company's own security team. The second is a high-security executive safe (Managed HSM) in a vault with multiple layers of security. The safe uses a complex combination lock that requires two separate codes to open, each held by different executives. The safe itself is tamper-proof and certified to military standards. The safe's combination mechanism is built into a hardened, dedicated device that only accepts commands from authorized personnel. When an executive needs to access a document, they must present their code, and the safe verifies it against a list of authorized users before opening. The safe automatically logs every access attempt and can be configured to require multiple approvals for critical operations. The company uses the filing cabinet for everyday documents that are sensitive but not critical, while the executive safe is reserved for the company's most valuable secrets, like merger plans or patent filings. In Azure, Key Vault Standard provides software-backed encryption keys suitable for most scenarios, while Managed HSM offers FIPS 140-2 Level 3 validated hardware security modules for the highest security requirements, with dedicated HSM instances, full key lifecycle control, and mandatory role separation.
What Are Azure Key Vault and Managed HSM?
Azure Key Vault is a cloud service for securely storing and accessing secrets, keys, and certificates. It comes in two tiers: Standard (software-backed) and Premium (hardware-backed with HSM). Azure Managed HSM (Hardware Security Module) is a fully managed, single-tenant HSM service that provides the highest level of key protection, meeting FIPS 140-2 Level 3 validation.
Why Both Exist
The primary driver is the need for different security assurance levels. Key Vault Standard is cost-effective and suitable for most applications where encryption keys are managed by Microsoft's shared HSM infrastructure. Managed HSM addresses scenarios requiring dedicated HSM instances, full tenant isolation, and compliance with strict regulations like PCI DSS, GDPR, and government standards. Managed HSM gives customers exclusive control over the HSM partition, ensuring no other tenant can access the key material.
How They Work Internally
Key Vault uses a multi-tenant architecture. When you create a key in Key Vault Standard, the key material is generated and stored in Microsoft's software-based HSM clusters (for Premium tier, it uses shared HSM pools). The key material is encrypted at rest using a tenant key managed by Microsoft. Access is controlled via Azure RBAC and vault access policies. Key Vault supports up to 25 vaults per subscription, with a maximum of 10,000 keys/secrets/certificates per vault.
Managed HSM provisions a dedicated HSM partition (a 'pool') for each customer. The HSM hardware is FIPS 140-2 Level 3 validated, meaning it is tamper-resistant and provides physical security. Each pool consists of at least 3 HSM nodes in a cluster, ensuring high availability. The customer manages the HSM's security domain (a set of cryptographic keys that protect the HSM's master keys) and must back it up to avoid data loss. Managed HSM supports up to 5 pools per subscription, with a limit of 10,000 keys per pool.
Key Components and Defaults
Key Vault Standard: Software-protected. Key types: RSA 2048, 3072, 4096; EC P-256, P-384, P-521, P-256K. No dedicated HSM. Default retention for soft-delete: 90 days (configurable 7-90).
Key Vault Premium: HSM-protected using shared HSM pools. Same key types as Standard but keys are generated and stored in HSM. Soft-delete retention same as Standard.
Managed HSM: Dedicated HSM pool. Supports RSA 2048, 3072, 4096; EC P-256, P-384, P-521. Also supports symmetric keys (AES 128, 192, 256) and octet string (OCT) keys. Soft-delete retention: 90 days (configurable 7-90). Managed HSM also supports custom key attributes, key rotation policies, and role-based access control (RBAC) natively.
Configuration and Verification Commands
To create a Key Vault (Standard or Premium):
az keyvault create --name MyVault --resource-group MyRG --location eastus --sku standardTo create a Managed HSM pool:
az keyvault create --hsm-name MyHSM --resource-group MyRG --location eastus --administrators "user@domain.com" --sku Standard_B1To add a key to Key Vault:
az keyvault key create --vault-name MyVault --name MyKey --protection softwareTo add a key to Managed HSM:
az keyvault key create --hsm-name MyHSM --name MyKey --protection hsm --kty RSA-HSM --size 2048To verify the HSM status:
az keyvault show --hsm-name MyHSM --query "properties.hsmPool"Interaction with Related Technologies
Both services integrate with Azure services like Azure Disk Encryption, SQL Server TDE, and Azure Storage encryption. Managed HSM is required for Azure Confidential Computing scenarios where keys must never leave the HSM boundary. It also supports Azure Dedicated HSM integration for lift-and-shift scenarios. Key Vault can be used with Azure Policy to enforce key types and rotation. Managed HSM provides audit logs via Azure Monitor and supports BYOK (Bring Your Own Key) with key import using secure methods.
Security Boundaries
Key Vault's security boundary is the vault itself, protected by Azure AD authentication and RBAC. The underlying HSM (for Premium) is shared. Managed HSM's boundary is the HSM partition, isolated at the hardware level. The customer manages the security domain, which is required for disaster recovery. If the security domain is lost, the HSM pool cannot be recovered. Managed HSM also enforces mandatory separation of duties: the 'Administrator' role can manage the pool but cannot access keys, while 'Crypto Officer' can manage keys but not the pool.
Compliance Certifications
Key Vault Standard: FIPS 140-2 Level 1 (software) or Level 2 (Premium with HSM).
Managed HSM: FIPS 140-2 Level 3, Common Criteria EAL4+, PCI DSS, GDPR, and more.
Cost Model
Key Vault Standard charges per vault and per operation (e.g., key creation, encryption). Premium adds an HSM-backed key premium. Managed HSM charges per pool (dedicated HSM nodes) and per operation, with significantly higher base cost due to dedicated hardware.
Limitations
Key Vault: Max 25 vaults per subscription; 10,000 keys/secrets/certificates per vault; no key rotation policies; no symmetric key support.
Managed HSM: Max 5 pools per subscription; 10,000 keys per pool; requires at least 3 nodes for high availability; backup of security domain is mandatory; cannot be moved between regions without rebuilding.
Assess Security Requirements
Begin by determining the level of security required for your cryptographic keys. For most applications, Key Vault Standard (software-backed) or Premium (shared HSM) is sufficient. If you need FIPS 140-2 Level 3 validation, dedicated HSM isolation, or must meet compliance standards like PCI DSS, select Managed HSM. Also consider key types: if you need symmetric keys (e.g., AES) for data encryption at rest, Managed HSM is required as Key Vault does not support symmetric keys.
Provision the Service
For Key Vault, use the Azure portal, CLI, or PowerShell to create a vault with the desired SKU (Standard or Premium). For Managed HSM, create a pool specifying the SKU (Standard_B1 is the only current option). During creation, assign initial administrators who will manage the HSM. The pool will provision at least 3 HSM nodes across availability zones. For Managed HSM, you must also download and securely store the security domain after creation.
Configure Access Control
Key Vault uses Azure RBAC and vault access policies. Assign roles like 'Key Vault Administrator' or 'Key Vault Crypto Officer' at the vault scope. Managed HSM uses a built-in RBAC model with roles such as 'Managed HSM Administrator' (pool management only) and 'Managed HSM Crypto Officer' (key operations). You can also create custom roles. For Managed HSM, role assignment is done via Azure RBAC at the pool level, but fine-grained permissions are managed within the HSM using the 'az keyvault role' commands.
Create and Manage Keys
In Key Vault, create keys using Azure CLI or portal. Specify key type, size, and protection (software or HSM). Keys can be imported using BYOK (Bring Your Own Key) with an HSM-protected key exchange. In Managed HSM, keys are created directly in the HSM and never leave the hardware boundary. Managed HSM supports key rotation policies, key attributes, and symmetric keys. For Managed HSM, you can also generate keys on-premises and import them securely using the 'az keyvault key import' command with the HSM protection flag.
Monitor and Audit
Both services integrate with Azure Monitor and Azure Log Analytics. Enable diagnostics settings to send logs to a Log Analytics workspace, storage account, or Event Hub. Key Vault logs all operations (read, write, delete) and authentication attempts. Managed HSM provides additional logs for HSM-specific events like security domain backup/restore and role assignments. Use Azure Policy to audit key types and enforce compliance. For Managed HSM, regularly test disaster recovery by restoring the security domain to a new pool.
Scenario 1: Financial Services Compliance A multinational bank must store encryption keys for payment card data (PCI DSS). They require FIPS 140-2 Level 3 validated HSMs and full tenant isolation. They choose Azure Managed HSM. They provision a pool in a primary region and a second pool in a paired region for disaster recovery. They configure RBAC to separate duties: the security team manages the pool (Administrator role) while the application team manages keys (Crypto Officer role). They enable soft-delete with a retention of 90 days and regularly back up the security domain to a secure on-premises location. In production, the HSM handles thousands of cryptographic operations per second. A common pitfall is failing to back up the security domain; if lost, the entire HSM pool must be rebuilt and keys cannot be recovered.
Scenario 2: Enterprise Application Key Management A large SaaS provider uses Azure Key Vault Standard to store secrets (database connection strings, API keys) and encrypt application data using software-backed keys. They have 20 vaults across multiple subscriptions. They use RBAC to grant developers access to specific secrets and keys. They enable soft-delete and purge protection to prevent accidental deletion. The cost is low, and the performance meets their needs. However, when they need to implement customer-managed keys for Azure Storage encryption, they upgrade to Key Vault Premium to use HSM-backed keys. They discover that Key Vault does not support key rotation policies natively, so they implement a custom solution using Azure Functions to rotate keys periodically.
Scenario 3: Government Agency High-Security Deployment A government agency requires encryption keys that are never accessible to Microsoft or any third party. They deploy Azure Managed HSM with a dedicated HSM pool. They configure the security domain and store it in a government-approved offline location. They enforce mandatory approval workflows for key operations using the 'key approval' feature in Managed HSM. They also integrate with Azure Confidential Computing to ensure data is encrypted throughout its lifecycle. The challenge is the cost: Managed HSM is significantly more expensive than Key Vault, so they only use it for the most sensitive keys. They also face complexity in managing the HSM pool, requiring specialized training for their security team.
AZ-500 Objective 2.3: Configure and manage key vaults — This includes comparing Key Vault Standard, Premium, and Managed HSM. Expect 3-5 questions on this topic.
Common Wrong Answers: 1. 'Key Vault Premium provides FIPS 140-2 Level 3 validation.' Wrong — Key Vault Premium uses shared HSM pools validated at Level 2, not Level 3. Managed HSM provides Level 3. 2. 'Managed HSM supports the same key types as Key Vault.' Wrong — Managed HSM also supports symmetric keys (AES) and octet string keys, which Key Vault does not. 3. 'Both services have the same maximum number of keys per vault/pool.' Wrong — Key Vault limits to 10,000 keys per vault; Managed HSM also limits to 10,000 keys per pool, but the pool limit is 5 per subscription vs 25 vaults. 4. 'You can move a Managed HSM pool between regions.' Wrong — Managed HSM pools are region-bound; you must create a new pool and restore the security domain.
Specific Numbers and Terms: - Soft-delete retention: 7-90 days (default 90) for both services. - Key Vault Standard: software-only; Premium: HSM-backed (shared). - Managed HSM: FIPS 140-2 Level 3, dedicated HSM, at least 3 nodes per pool. - Key types: RSA (2048, 3072, 4096), EC (P-256, P-384, P-521, P-256K) for both; Managed HSM adds AES (128, 192, 256) and OCT. - Managed HSM roles: Administrator (pool management), Crypto Officer (key operations). - The exam may ask: 'Which service supports key rotation policies?' Answer: Managed HSM only.
Edge Cases: - If you need to bring your own key (BYOK) but require FIPS 140-2 Level 3, you must use Managed HSM. - For Azure Disk Encryption with customer-managed keys, you can use Key Vault Premium or Managed HSM, but if you need symmetric keys, only Managed HSM works. - Managed HSM can be used with Azure Dedicated HSM for lift-and-shift of on-premises HSM workloads.
How to Eliminate Wrong Answers: - If the question mentions 'dedicated HSM' or 'single-tenant,' the answer is Managed HSM. - If the question mentions 'symmetric key' or 'key rotation policy,' the answer is Managed HSM. - If the question mentions 'FIPS 140-2 Level 2,' it's Key Vault Premium; if 'Level 3,' it's Managed HSM. - If the question mentions 'shared HSM infrastructure,' it's Key Vault Premium.
Key Vault Standard is software-backed; Premium is HSM-backed with shared HSMs (FIPS 140-2 Level 2).
Managed HSM provides dedicated HSM partitions with FIPS 140-2 Level 3 validation.
Managed HSM supports symmetric keys (AES) and key rotation policies; Key Vault does not.
Key Vault limit: 25 vaults per subscription, 10,000 keys per vault.
Managed HSM limit: 5 pools per subscription, 10,000 keys per pool.
Soft-delete retention: 7-90 days (default 90) for both services.
Managed HSM requires backup of security domain; loss means unrecoverable.
Managed HSM roles: Administrator (pool management) and Crypto Officer (key operations).
Key Vault uses Azure RBAC and vault access policies; Managed HSM uses RBAC at pool level and fine-grained roles within HSM.
For BYOK with highest security, use Managed HSM.
These come up on the exam all the time. Here's how to tell them apart.
Key Vault Standard
Software-backed key storage (no HSM).
FIPS 140-2 Level 1 (software) validation.
Lower cost per vault and per operation.
Supports RSA and EC key types only.
Suitable for most general-purpose secret and key storage.
Key Vault Premium
HSM-backed key storage using shared HSM pools.
FIPS 140-2 Level 2 validation.
Higher cost due to HSM premium.
Same key types as Standard, but keys are generated in HSM.
Required for scenarios where keys must be HSM-protected but dedicated HSM is not needed.
Key Vault Premium
Shared HSM infrastructure (multi-tenant).
FIPS 140-2 Level 2 validation.
Max 25 vaults per subscription.
No symmetric key support.
No key rotation policies; rotation must be implemented externally.
Managed HSM
Dedicated HSM partition (single-tenant).
FIPS 140-2 Level 3 validation.
Max 5 pools per subscription.
Supports symmetric keys (AES) and OCT keys.
Built-in key rotation policies and mandatory role separation.
Mistake
Managed HSM is just a more expensive version of Key Vault Premium.
Correct
Managed HSM provides a dedicated HSM partition (single-tenant) with FIPS 140-2 Level 3 validation, while Key Vault Premium uses shared HSM pools validated at Level 2. Managed HSM also supports symmetric keys, key rotation policies, and mandatory role separation.
Mistake
Key Vault Standard does not use any HSM.
Correct
Key Vault Standard uses software-based key storage, not HSM. The keys are encrypted at rest using Microsoft-managed keys. Key Vault Premium uses shared HSM hardware.
Mistake
You can upgrade a Key Vault to Managed HSM.
Correct
You cannot upgrade a Key Vault to Managed HSM. They are separate services with different provisioning and management. You must create a new Managed HSM pool and migrate keys manually.
Mistake
Both services support the same number of keys per vault/pool.
Correct
Both have a limit of 10,000 keys per vault/pool, but Key Vault allows up to 25 vaults per subscription, while Managed HSM allows up to 5 pools per subscription.
Mistake
Managed HSM does not support soft-delete.
Correct
Managed HSM supports soft-delete with a configurable retention period of 7 to 90 days (default 90), similar to Key Vault.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Key Vault Standard stores keys in software, while Premium stores keys in shared HSM hardware. Premium provides FIPS 140-2 Level 2 validation; Standard is Level 1. Premium is more expensive but offers HSM-backed key protection. Both support the same key types (RSA, EC) but Premium keys are generated in HSM.
You can, but it may be overkill and cost-prohibitive. Managed HSM is designed for high-security environments requiring dedicated HSM, FIPS 140-2 Level 3, symmetric keys, or key rotation policies. For most applications, Key Vault Standard or Premium is sufficient.
Yes, Managed HSM supports soft-delete with a configurable retention period from 7 to 90 days (default 90). You can enable purge protection to prevent permanent deletion during the retention period.
You cannot directly migrate keys. You must manually recreate or re-import keys into Managed HSM. For BYOK, you can use the same key material if you have it backed up. For keys generated in Key Vault, you cannot extract the private key (it is non-exportable). You would need to generate new keys in Managed HSM.
The security domain is essential for disaster recovery. If lost, you cannot restore the HSM pool or recover keys. You must delete the pool and create a new one, losing all keys. Always back up the security domain to a secure, offline location.
Yes, you can use Managed HSM for Azure Disk Encryption (ADE) by specifying the key URI. However, ADE typically uses Key Vault for simplicity. Managed HSM is used when you need dedicated HSM and FIPS 140-2 Level 3.
No, Key Vault does not have built-in key rotation policies. You must implement rotation manually using Azure Functions, Logic Apps, or other automation. Managed HSM supports key rotation policies natively.
You've just covered Azure Managed HSM vs Key Vault Standard — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?