This chapter covers Azure Disk Encryption (ADE) with Azure Key Vault, a critical security feature for protecting data at rest on Azure virtual machines. For the AZ-500 exam, you must understand how ADE works, how to integrate it with Azure Key Vault, and the key management options. This topic typically appears in 5-10% of exam questions, often in scenario-based questions that require you to choose the correct encryption method or diagnose a configuration failure. Mastering ADE is essential for the Compute Security domain (Objective 2.1) and directly relates to encryption at rest requirements for compliance.
Jump to a section
Azure Disk Encryption (ADE) is like a bank's safe deposit box system where each customer gets a personal lockbox stored in a vault (Azure Key Vault). The customer owns the only key to their box, and the bank cannot open it without that key. When a customer wants to store valuables (data), they place them in the box, lock it with their key, and the bank stores the locked box. When the customer needs access, they present their key, unlock the box, and retrieve the valuables. The bank's vault protects the box from theft or damage, but the actual encryption is enforced by the customer's key. In ADE, the BitLocker or DM-Crypt service acts as the lockbox mechanism that encrypts the disk data. The encryption keys are stored in Azure Key Vault, which is the secure vault. The customer (or Azure administrator) controls access to the keys via Key Vault access policies. The disk encryption process ensures that even if the disk is stolen or accessed by unauthorized personnel, the data remains encrypted and unreadable without the correct key. The analogy breaks down in that the bank's safe deposit box system doesn't automatically re-encrypt data every time it's accessed, whereas ADE continuously encrypts data at rest. However, the core concept of a separate, customer-controlled key protecting the data is identical.
What is Azure Disk Encryption and Why Does It Exist?
Azure Disk Encryption (ADE) is a native Azure feature that provides volume-level encryption for both OS and data disks on Azure virtual machines (VMs). It uses BitLocker on Windows and DM-Crypt on Linux to encrypt the entire disk, including the boot volume. The primary purpose is to protect data at rest, ensuring that if a disk is compromised—for example, through unauthorized access to storage or by copying a VHD—the data remains unreadable without the encryption key. ADE is a requirement for many compliance frameworks, including PCI DSS, HIPAA, and FedRAMP.
ADE is distinct from Azure Storage Service Encryption (SSE), which encrypts data at the storage platform layer before it is written to disk. SSE is transparent and automatically enabled for all managed disks, but it encrypts data at the storage service level, not at the VM level. ADE encrypts data within the VM itself, providing an additional layer of security. ADE also allows customers to control their own encryption keys, which is essential for meeting regulatory requirements around key management.
How Azure Disk Encryption Works Internally
ADE leverages the BitLocker Drive Encryption feature on Windows VMs and the DM-Crypt subsystem on Linux VMs. When you enable ADE on a VM, the following steps occur:
Key Vault Preparation: You must have an Azure Key Vault that will store the encryption keys. The Key Vault must have the "Enabled for disk encryption" setting enabled. If you want to use a Key Encryption Key (KEK) to wrap the BitLocker/DM-Crypt key, you must create a key in the Key Vault as well.
Extension Installation: The Azure Disk Encryption extension is installed on the VM. On Windows, this is the AzureDiskEncryption extension; on Linux, it is AzureDiskEncryptionForLinux. The extension handles the encryption process.
Key Retrieval: The extension contacts the Azure Key Vault to retrieve the encryption key (or KEK). It uses the VM's managed identity (or a service principal if not using managed identity) to authenticate to Key Vault.
Encryption Execution: On Windows, the extension enables BitLocker on the OS and data drives. On Linux, it uses DM-Crypt to set up encrypted volumes. The encryption key is stored in a secure location on the VM (e.g., the TPM if available, or a protected file) and is used to encrypt the disk.
Key Escrow: The encryption key (or the wrapped key if using KEK) is then exported to the Key Vault for safekeeping. This allows the VM to be restarted and decrypt the disk on boot without user intervention.
Boot Integrity: On Windows VMs with a TPM, BitLocker can use the TPM to protect the encryption key and ensure the boot process has not been tampered with. Linux VMs use a similar mechanism with the TPM or a passphrase.
Key Components, Values, Defaults, and Timers
Key Vault: The Key Vault must be in the same Azure region and subscription as the VM. The access policy must grant the VM (or the service principal) the Get, WrapKey, and UnwrapKey permissions for keys, and Get, Set, List, and Delete for secrets.
Encryption Key (BEK): This is the actual BitLocker or DM-Crypt key used to encrypt the disk. It is stored as a secret in Key Vault.
Key Encryption Key (KEK): An optional RSA key stored in Key Vault that is used to wrap the BEK. Using a KEK adds an extra layer of security and allows for key rotation without re-encrypting the disk.
Encryption Algorithm: BitLocker uses AES-256 with XTS mode on Windows. DM-Crypt uses AES-256 with CBC or XTS mode on Linux.
Default Volume Encryption: For Windows VMs, both the OS volume and data volumes are encrypted. For Linux VMs, only data volumes are encrypted by default; the OS volume is not encrypted unless you specify --encrypt-all-volumes in the Azure CLI or PowerShell.
Extension Version: The latest version of the extension should be used. As of 2025, the Windows extension version is 2.2 and Linux is 1.2.
Timeout: The encryption process can take several hours depending on disk size and VM performance. There is no specific timeout; the process runs until completion.
Configuration and Verification Commands
To enable ADE on a VM using Azure CLI:
# Create a Key Vault (if not exists)
az keyvault create --name "MyKeyVault" --resource-group "MyRG" --location "eastus" --enabled-for-disk-encryption
# Create a KEK (optional)
az keyvault key create --vault-name "MyKeyVault" --name "MyKEK" --protection software
# Enable encryption on a VM
az vm encryption enable --resource-group "MyRG" --name "MyVM" --disk-encryption-keyvault "MyKeyVault" --key-encryption-key "MyKEK"To verify encryption status:
az vm encryption show --resource-group "MyRG" --name "MyVM"This command returns the status of encryption for each disk, including the encryption settings and key vault URL.
On Windows, you can also check BitLocker status from within the VM:
manage-bde -statusInteraction with Related Technologies
Azure Key Vault: ADE depends on Key Vault to store and manage encryption keys. Key Vault access policies and RBAC roles must be correctly configured.
Managed Disks: ADE works with both managed and unmanaged disks, but managed disks are recommended. Encryption is applied at the VM level, not the disk level.
Azure Backup: Backups of encrypted VMs must be performed using Azure Backup. The backup service can read the encrypted data because it has access to the keys via Key Vault, provided the Backup vault has the necessary permissions.
Azure Site Recovery: Replication of encrypted VMs to another region is supported. The encryption keys must be available in the target region's Key Vault.
Azure Disk Encryption Sets: For managed disks, you can use Disk Encryption Sets (DES) to manage encryption keys at the disk level using customer-managed keys (CMK). ADE is separate from DES; DES encrypts the disk at the storage platform level, while ADE encrypts within the VM. Both can be used together for defense in depth.
Important Considerations
Unsupported Scenarios: ADE is not supported on basic tier VMs, VMs with unmanaged disks in some regions, or VMs with certain Linux distributions (check Microsoft documentation for the current list).
Key Vault Firewall: If Key Vault has a firewall enabled, the VM must be allowed to access it. This is typically done by allowing trusted Microsoft services or configuring a private endpoint.
Key Rotation: To rotate the BEK, you must disable encryption and re-enable it with a new key. For KEK rotation, you can create a new key version in Key Vault and update the VM's encryption settings.
Performance Impact: ADE can cause a slight performance overhead (2-5%) due to real-time encryption/decryption. This is usually negligible for most workloads.
Troubleshooting Common Issues
Encryption Fails: Check that the VM is supported, the Key Vault is enabled for encryption, and the VM has network access to Key Vault.
Key Vault Access Denied: Ensure the VM's managed identity (or service principal) has the correct permissions in the Key Vault access policy.
Extension Failure: Look at the extension logs in the Azure portal or on the VM (e.g., C:\AzureLogs on Windows).
Boot Failure: If the VM fails to boot after encryption, it is often due to missing or corrupted boot files. Use Azure Serial Console to troubleshoot.
Create Azure Key Vault
Create an Azure Key Vault in the same region and subscription as the target VM. Enable the 'Enabled for disk encryption' setting during creation or later via the Azure portal or CLI. This setting allows the Key Vault to be used for Azure Disk Encryption. Optionally, generate a Key Encryption Key (KEK) to wrap the disk encryption key. The Key Vault access policy must grant the VM (or a service principal) permissions to get, wrap, and unwrap keys and secrets.
Configure Key Vault Access Policy
Assign the necessary permissions to the VM's managed identity or the service principal that will perform the encryption. For managed identities, enable system-assigned identity on the VM. Then, in the Key Vault access policy, add the VM's principal ID with permissions: Key permissions - Get, WrapKey, UnwrapKey; Secret permissions - Get, Set, List, Delete. If using a KEK, also include Key permissions for the KEK. This ensures the encryption extension can retrieve and store keys.
Install Azure Disk Encryption Extension
When you enable ADE via Azure CLI or PowerShell, the Azure Disk Encryption extension is automatically installed on the VM. For Windows, the extension is 'AzureDiskEncryption'; for Linux, 'AzureDiskEncryptionForLinux'. The extension handles the encryption process. You can also install it manually, but it's typically done as part of the enable command. The extension requires outbound HTTPS access to Azure Key Vault (port 443) and to Azure Active Directory for authentication.
Encrypt the VM Disks
Run the encryption enable command. For example, using Azure CLI: `az vm encryption enable --resource-group MyRG --name MyVM --disk-encryption-keyvault MyKeyVault --key-encryption-key MyKEK`. This command triggers the extension to encrypt all data disks (and OS disk on Windows). The encryption process runs in the background. You can monitor progress via Azure portal or CLI. The time required depends on disk size and VM performance. During encryption, the VM remains available but may experience reduced performance.
Verify Encryption Status
After encryption completes, verify that the disks are encrypted. Use `az vm encryption show --resource-group MyRG --name MyVM` to see the encryption status for each disk. The output includes 'encryptionSettings' and 'status'. You can also check from within the VM: on Windows, run 'manage-bde -status'; on Linux, check /etc/crypttab. Ensure that no disks show 'NotEncrypted'. Also confirm that the encryption key is stored in Key Vault by listing secrets: `az keyvault secret list --vault-name MyKeyVault`.
In a large financial services company, Azure Disk Encryption is deployed across thousands of VMs to meet PCI DSS compliance requirements. The company uses a centralized Key Vault per region with strict access policies. Encryption keys are wrapped with a KEK that is stored in a hardware security module (HSM) backed Key Vault for FIPS 140-2 Level 3 compliance. The operations team uses Azure Policy to enforce encryption on all new VMs. They also use Azure Monitor to alert on any encryption failures or key access denials. A common problem they encounter is when a VM is moved to a different resource group; the encryption extension may break because the managed identity loses its association. They mitigate this by using a service principal instead of managed identity for critical VMs.
Another scenario involves a healthcare organization that uses Linux VMs for data processing. They discovered that ADE does not encrypt the OS volume by default on Linux, which was a compliance gap. They had to use the --encrypt-all-volumes flag to include the OS disk. They also needed to ensure that the Key Vault firewall was configured to allow access from the VM's subnet via a private endpoint, as they had disabled public access. The team learned that the encryption process can take up to 8 hours for large 2TB data disks, so they schedule encryption during maintenance windows.
A common misconfiguration occurs when an administrator forgets to enable the Key Vault for disk encryption. This results in the error 'KeyVaultNotEnabledForDiskEncryption'. Another frequent issue is when the VM does not have network access to Key Vault due to NSG rules or forced tunneling. In such cases, the encryption extension fails silently. The solution is to add a service endpoint or private endpoint for Key Vault and allow outbound HTTPS traffic. Performance considerations include that ADE can cause a 5-10% CPU overhead during encryption, and I/O latency may increase slightly. For production workloads, it's recommended to test performance impact before rolling out.
The AZ-500 exam tests Azure Disk Encryption under Objective 2.1: Configure security for compute workloads. You must know how to enable ADE, integrate with Key Vault, and differentiate between ADE and other encryption methods. Specific subtopics include:
The prerequisites for ADE: Key Vault enabled for disk encryption, supported VM sizes, and OS versions.
The difference between BEK and KEK, and when to use each.
How to grant permissions to the VM for accessing Key Vault keys.
The default behavior on Linux (only data disks encrypted) and how to change it.
Common wrong answers on exam questions: 1. 'ADE encrypts data at the storage layer' — This is false; ADE encrypts within the VM. Storage Service Encryption (SSE) encrypts at the storage layer. 2. 'ADE requires a premium Key Vault SKU' — False; Standard Key Vault works. 3. 'ADE automatically encrypts OS disks on Linux' — False; only data disks by default. 4. 'You must use a KEK for ADE' — False; KEK is optional but recommended.
The exam often includes numeric values such as:
AES-256 encryption algorithm.
Key sizes: 2048-bit for RSA keys (KEK).
Key Vault must be in the same region.
Edge cases:
Encrypting VMs with unmanaged disks: Supported but not recommended.
Encrypting VMs with existing data: The process will encrypt existing data without data loss.
Encrypting VMs that are part of a scale set: ADE can be applied to scale set VMs, but each VM must be encrypted individually.
To eliminate wrong answers, focus on the mechanism: ADE uses BitLocker/DM-Crypt, which is a volume-level encryption that runs inside the VM. Any answer that suggests encryption at the storage layer or that does not involve Key Vault is incorrect. Also, remember that ADE requires the Key Vault to be enabled for disk encryption, and the VM must have appropriate permissions.
Azure Disk Encryption uses BitLocker (Windows) or DM-Crypt (Linux) to encrypt OS and data disks at the VM level.
The encryption key (BEK) is stored as a secret in Azure Key Vault; optionally, a Key Encryption Key (KEK) can wrap the BEK.
Key Vault must be enabled for disk encryption, and the VM must have Get, WrapKey, UnwrapKey permissions on the key vault.
On Linux, only data disks are encrypted by default; use --encrypt-all-volumes to encrypt the OS disk.
ADE is supported on specific VM sizes and OS versions; check Microsoft documentation for the latest compatibility list.
Azure Backup and Site Recovery work with ADE-encrypted VMs if the Backup vault has access to Key Vault.
The encryption process can take several hours; plan maintenance windows accordingly.
Common exam trap: confusing ADE with SSE. Remember ADE is VM-level, SSE is storage-level.
These come up on the exam all the time. Here's how to tell them apart.
Azure Disk Encryption (ADE)
Encrypts at the VM level using BitLocker/DM-Crypt
Requires Key Vault for key management
Supports customer-managed keys (BEK and KEK)
Must be explicitly enabled by the user
Works with both managed and unmanaged disks
Azure Storage Service Encryption (SSE)
Encrypts at the storage platform level before data is written to disk
Enabled by default for all managed disks
Uses Microsoft-managed keys by default, but supports customer-managed keys via Disk Encryption Sets
Transparent to the VM; no user action required
Only works with managed disks
Mistake
Azure Disk Encryption encrypts data at the storage level, so it is the same as Storage Service Encryption.
Correct
ADE encrypts at the VM level using BitLocker or DM-Crypt, while SSE encrypts at the Azure storage platform level. ADE provides an additional layer of encryption and allows customer-managed keys.
Mistake
You cannot use Azure Backup on VMs encrypted with ADE.
Correct
Azure Backup fully supports ADE-encrypted VMs. The backup service must have permissions to access the Key Vault to read the encryption keys. This is configured via the Backup vault's access policy.
Mistake
ADE automatically encrypts both OS and data disks on Linux VMs.
Correct
By default, ADE on Linux only encrypts data disks. To encrypt the OS disk, you must use the --encrypt-all-volumes flag when enabling encryption.
Mistake
The Key Vault must be in the same resource group as the VM.
Correct
The Key Vault must be in the same region and subscription, but it can be in a different resource group. However, it is best practice to keep them in the same resource group for management simplicity.
Mistake
You must use a Key Encryption Key (KEK) for ADE to be secure.
Correct
A KEK is optional. Using a KEK adds an extra layer of protection by wrapping the disk encryption key, but it is not required. The BEK alone is stored as a secret in Key Vault.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, ADE can be enabled on existing VMs with data. The encryption process encrypts the data in place without requiring data migration. However, the VM must be rebooted during the encryption process, so plan for downtime. The process uses BitLocker or DM-Crypt to encrypt the volumes while the VM is running, but a reboot is needed to complete the encryption on some configurations.
BEK (BitLocker Encryption Key) is the actual key used to encrypt the disk. It is stored as a secret in Azure Key Vault. KEK (Key Encryption Key) is an optional RSA key that wraps (encrypts) the BEK. Using a KEK adds a layer of separation: the BEK is encrypted with the KEK, and both are stored in Key Vault. This allows you to rotate the KEK without re-encrypting the disk. The KEK can be stored in a hardware security module (HSM) for additional security.
This error occurs when the Key Vault does not have the 'Enabled for disk encryption' property set to true. To fix it, update the Key Vault to enable disk encryption. In Azure CLI, run: `az keyvault update --name MyKeyVault --resource-group MyRG --enabled-for-disk-encryption true`. You can also do this in the Azure portal under the Key Vault's 'Properties' blade. Without this setting, ADE cannot use the Key Vault to store or retrieve keys.
Yes, ADE works with Key Vault private endpoints. However, you must ensure that the VM's subnet has a private endpoint configured for the Key Vault, and that the VM can resolve the Key Vault's private IP address. Also, the Key Vault firewall must allow access from the VM's subnet or use 'Allow trusted Microsoft services' if you are using a managed identity. Without proper network connectivity, the encryption extension will fail.
Yes, but it is not enabled by default. By default, ADE on Linux only encrypts data disks. To encrypt the OS disk, you must use the `--encrypt-all-volumes` flag when enabling encryption. For example: `az vm encryption enable --resource-group MyRG --name MyVM --disk-encryption-keyvault MyKeyVault --encrypt-all-volumes`. Note that not all Linux distributions support OS disk encryption; check the Azure documentation for supported distributions.
To rotate the BEK (disk encryption key), you must disable encryption and re-enable it with a new key. This process will re-encrypt the disk with the new key. To rotate the KEK (key encryption key), you can create a new version of the key in Key Vault and then update the VM's encryption settings to use the new key version. Use the `az vm encryption enable` command with the new KEK version. This does not require re-encrypting the disk.
Azure Backup needs permissions to read the encryption keys from Key Vault. Specifically, the Backup vault's managed identity (or the service principal used by Backup) must have `Get`, `WrapKey`, and `UnwrapKey` permissions on the key vault's keys, and `Get` and `List` permissions on secrets. This is configured via the Key Vault access policy. Without these permissions, Backup will fail with an authorization error.
You've just covered Azure Disk Encryption with Azure Key Vault — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?