The Big Picture
Azure gives you five overlapping ways to encrypt VM disk data. They sound similar, use some of the same terminology, and the Azure portal mixes them all together in the "Encryption" blade — which makes choosing correctly genuinely confusing. Then in late 2025, Microsoft announced that one of the most commonly used options — Azure Disk Encryption (ADE) — is being retired. If you have ADE-encrypted VMs and you do nothing before September 15, 2028, your disks will fail to unlock after any reboot.
Retirement alert: Azure Disk Encryption After September 15, 2028, ADE-enabled workloads will continue to run — but encrypted disks will fail to unlock after VM reboots, causing service disruption. All ADE-enabled VMs (including backups) must migrate before this date. There is no in-place migration path; you must rebuild the VM.
This article covers what each option actually does, where it operates in the stack, detailed pros and cons, and a clear decision guide — plus the full migration picture.
Diagram 1 shows where each encryption option operates in the Azure stack.
SSE with PMK is the Azure default. Azure manages the key lifecycle and encryption happens at the storage cluster level after data leaves the VM and host. It uses AES-256 on every managed disk, snapshot, and image. It is transparent and cannot be turned off.
Pros: zero configuration, no cost overhead, Microsoft handles key rotation and lifecycle, works with every disk type including Ultra Disk and Premium SSD v2, and no operational burden.
Cons: Microsoft holds the keys, no customer control, no audit trail of key access, does not satisfy compliance requirements needing key control, temp disks and disk caches are not encrypted, and data is unencrypted in transit between VM host and storage cluster.
SSE with CMK is the option when you want to supply and manage your own keys. You store a key in Azure Key Vault and create a Disk Encryption Set (DES) that links the key to managed disks. Azure generates a unique Data Encryption Key (DEK) per disk, wraps it with your CMK, stores the wrapped DEK with the disk, and unwraps it on access. Revoking the CMK locks all linked disks.
Diagram 2 shows SSE with CMK and Disk Encryption Set architecture.
Pros: full key lifecycle control, satisfies HIPAA/PCI-DSS/ISO 27001/FedRAMP key control needs, Key Vault audit logs give a complete access trail, instant access revocation is possible, supports BYOK, works with Ultra Disk and Premium SSD v2, and is compatible with Encryption at Host.
Cons: temp disks and disk caches are still not encrypted without Encryption at Host, transit between host and storage is not encrypted, switching to CMK is one-way, VMs must be deallocated to assign disks to a DES, Key Vault setup adds operational overhead, and Key Vault availability is now in the critical path for VM operations.
Encryption at Host is the recommended long-term option. It encrypts at the VM host level, covering temp disks, OS/data disk caches, and the transit channel from host to storage. It does this in host hardware, so there is no measurable CPU impact on the VM. It can work with either PMK or CMK.
Feature registration required: register the EncryptionAtHost feature on your subscription with Azure before enabling it.
Pros: true end-to-end encryption, zero VM CPU overhead, works with PMK and CMK, supports Ultra Disk and Premium SSD v2, Microsoft recommended replacement for ADE, supported on most current VM sizes, and can be enabled at VM creation or after deallocation.
Cons: requires subscription-level feature registration, not supported on all older VM SKUs, cannot be combined with ADE, and not available for VMs that have ever had ADE enabled.
Azure Disk Encryption (ADE) encrypts at the OS layer using BitLocker on Windows or dm-crypt on Linux. That means the OS performs encryption and the encrypted data path extends from the VM through storage. ADE was attractive for some compliance scenarios because it gave OS-layer encryption that appeared to cover transit before data left the VM.
The problem is the complexity. ADE requires the VM to be running to enable it. It conflicts with SSE+CMK. It cannot be used with Encryption at Host. It does not support newer disk types like Ultra Disk or Premium SSD v2. It imposes CPU overhead on the VM. It creates a UDE metadata flag on disks that persists after ADE is disabled, which makes migration more involved than a simple switch.
Do not enable ADE on any new VM. Microsoft says use Encryption at Host for new deployments. ADE should only remain in use on existing VMs that have not yet migrated, and only until September 15, 2028.
Pros (historical): full data path encryption including OS-layer transit, BitLocker/dm-crypt are well understood and auditable technologies, encrypts temp disk when VolumeType=All is set, and satisfied strict in-transit compliance requirements.
Cons: retiring September 15, 2028, incompatible with SSE+CMK and Encryption at Host, does not support Ultra Disk or Premium SSD v2, not supported on Basic/A-series/v6+ VM sizes, VM must be running to enable it, UDE flag persists after decryption, cannot encrypt failover cluster VMs, significant VM CPU overhead, and there is no in-place migration path to Encryption at Host.
The Retirement means that ADE-enabled workloads will continue to run, but encrypted disks will fail to unlock after VM reboots. That means any planned or unplanned reboot after September 15, 2028, will leave disks locked and VMs unable to start. This is a hard service disruption on a known date, not a soft deprecation.
Diagram 3 shows the ADE retirement timeline and migration path.
Decision guide: For new VM deployments, if you do not need customer-controlled keys then SSE + PMK is the simplest default. If compliance needs customer key control, use SSE + CMK with Disk Encryption Set. If you need true end-to-end coverage for temp disk, cache, and transit, choose Encryption at Host. Never enable ADE on new VMs; it is retiring and has no new-workload path.
Diagram 4 helps choose the right Azure disk encryption option for your situation.
Full comparison summary SSE + PMK is the default and low-cost option with no VM CPU overhead, but it does not offer customer key control and it leaves temp disk, cache, and host-to-storage transit unencrypted. SSE + CMK adds customer key control through a Disk Encryption Set, though it still does not encrypt temp disk, cache, or transit. Encryption at Host provides true end-to-end coverage and can work with PMK or CMK. ADE covers OS and data disk encryption but is retiring, incompatible with SSE + CMK and Encryption at Host, and has significant VM overhead.
Migration steps from ADE to Encryption at Host cannot be done in place. Back up all data and document VM configuration. Disable ADE and wait for full OS-level decryption to complete before proceeding. Create new disk objects using the Upload method instead of Copy so you do not keep the UDE flag. Build a new VM with Encryption at Host enabled and attach the clean disks. For Linux OS disks, ADE disable is unsupported; you must create a fresh VM with a clean OS disk and migrate data disks separately.
The bottom line For new VMs, use Encryption at Host + CMK for full end-to-end coverage with customer key control. If you do not need CMK, Encryption at Host with PMK still gives complete coverage with minimal operational overhead. For existing ADE VMs, start planning your migration now. The rebuild requirement means this is a multi-sprint project for large VM estates, not a one-day task.
No comments:
Post a Comment