Azure VM Disk Encryption Options: Azure Disk Encryption vs Encryption at Host

Every managed disk in Azure is already encrypted at rest by default, no configuration required. That baseline (Azure Storage server-side encryption) isn’t what this article is about, and it isn’t what AZ-104 tests. The exam cares about the layer above it: the options you choose deliberately, for a specific compliance or security requirement, that go beyond the automatic default. There are three: Azure Disk Encryption (ADE), encryption at host, and confidential disk encryption. Only the first two show up regularly on AZ-104, and Microsoft has been actively steering customers away from the first one, which changes how you should answer scenario questions about it.

The baseline you don’t have to configure

Azure Disk Storage server-side encryption (SSE) encrypts every managed OS and data disk automatically, using platform-managed keys by default, or customer-managed keys if you attach a disk encryption set. It happens transparently at the storage layer and costs nothing to enable because it’s already on. What it doesn’t cover is the temp disk (the local, ephemeral drive attached to most VM sizes) or the OS and data disk caches, and it doesn’t encrypt the data in flight between the VM and the storage cluster. That gap is exactly what the two options below exist to close.

Azure Disk Encryption (ADE): in-guest encryption, now being phased out

ADE encrypts the OS and data disks from inside the guest operating system, using BitLocker on Windows and DM-Crypt on Linux. It integrates with Azure Key Vault to store and manage the encryption keys and secrets, optionally protecting them with a key encryption key (KEK). Because ADE runs as an in-guest agent, it depends on the VM’s own CPU cycles, and it doesn’t work on custom Linux images, only supported marketplace images.

ADE is scheduled for retirement on September 15, 2028. Microsoft Learn is explicit about what happens on that date: ADE-enabled workloads keep running, but encrypted disks fail to unlock after a VM reboot, which is a service-disrupting failure mode, not a graceful shutdown of the feature. Microsoft’s current guidance is to use encryption at host for new VM deployments, or confidential VM sizes with confidential OS disk encryption for confidential-computing workloads, and to migrate every existing ADE-enabled VM (including its backups) to encryption at host before the retirement date.

For AZ-104 purposes, treat ADE as a legacy option you need to recognize, not the default answer to reach for. If a scenario describes a brand-new VM deployment with no mention of existing BitLocker/DM-Crypt tooling already in place, ADE is very likely the wrong answer, and encryption at host is the one the exam wants.

Encryption at host: the modern default

Encryption at host moves encryption down to the Azure host infrastructure itself, outside the guest OS. Once enabled, it extends encryption to cover the temp disk and the OS/data disk caches, the two things baseline SSE misses, and it ensures data flows encrypted between the VM and the storage service. Because the encryption happens on the host rather than inside the guest, it doesn’t consume the VM’s CPU cycles, and it works with custom images, including custom Linux images, where ADE does not.

A few practical details the exam likes to test:

• It’s a subscription-level feature you register first. Before enabling encryption at host on a VM or scale set, register the EncryptionAtHost feature against the Microsoft.Compute provider (CLI or PowerShell), then confirm the registration state shows Registered.
• It’s mutually exclusive with ADE. You can’t enable encryption at host on a VM that currently has ADE enabled, or ever had it. ADE, in turn, can’t be enabled on a disk that already has encryption at host on. Migrating means disabling ADE first, not layering the two.
• Existing VMs need a deallocate/reallocate cycle. Turning it on for a running VM doesn’t encrypt in place; deallocate and reallocate the VM (a scale set only encrypts new instances created after the setting is enabled).
• Cache encryption follows the disk’s key type. A disk using customer-managed keys via a disk encryption set gets a cache encrypted with that same key; a disk using platform-managed keys gets a platform-managed cache. Temp disk encryption itself only supports platform-managed keys.

Confidential disk encryption: the highest tier

Confidential disk encryption binds the disk encryption keys to the VM’s virtual TPM and makes the protected content accessible only to that VM, with keys released through an attested process that bypasses the hypervisor and host OS entirely. It’s built for confidential computing on DCasv5/ECasv5-series confidential VMs, protecting the OS disk by default with an opt-in path for confidential temp disk encryption too. This is narrower and more specialized than the other two options, and AZ-104 scenarios are far more likely to be choosing between ADE and encryption at host than reaching for this tier, but recognize it as the answer when a scenario calls out confidential computing, TPM-bound keys, or protecting data even from the Azure host administrator.

Comparing the four encryption layers

	Server-side encryption (SSE)	Encryption at host	Azure Disk Encryption (ADE)	Confidential disk encryption
Applies by default	Yes, always on	No, opt in	No, opt in	No, opt in
OS/data disk encryption	Yes	Yes	Yes	Yes (OS disk)
Temp disk encryption	No	Yes (platform-managed keys only)	Yes	Opt-in
Cache encryption	No	Yes	Yes	Yes
Uses VM’s own CPU	No	No	Yes	No
Works with custom Linux images	Yes	Yes	No	Yes
Encryption location	Storage layer	Host infrastructure	Inside the guest OS	TPM-bound, bypasses host
Status	Current	Current, recommended default	Retiring September 15, 2028	Current, specialized use

Where Key Vault fits

All three configurable options touch Azure Key Vault, but not identically. ADE stores its BitLocker/DM-Crypt secrets and optional KEK in Key Vault directly. Encryption at host and confidential disk encryption instead use a disk encryption set, a resource that wraps a Key Vault key so multiple disks can reference it for customer-managed key encryption. The Key Vault instance itself must have soft delete and purge protection enabled before it can back a disk encryption set; that’s a mandatory prerequisite, not a recommendation. If you’re scripting the rollout with ARM templates or Bicep, the EncryptionAtHost provider registration and the disk encryption set both need to exist before the VM deployment that references them.

How the AZ-104 exam tests this

• A scenario asks how to encrypt the temp disk and disk caches, not just OS/data disks. Server-side encryption doesn’t cover them. The answer is encryption at host (or ADE, if the scenario specifically describes an existing BitLocker/DM-Crypt deployment already in place).
• A scenario mentions custom Linux images that need disk encryption. ADE doesn’t support custom Linux images. Encryption at host does. That distinction alone is often the entire question.
• A scenario describes a VM that won’t let you enable encryption at host, and mentions the VM previously had ADE configured. The two are mutually exclusive; you have to disable ADE before encryption at host can be turned on, even if ADE was later removed.
• A scenario asks what happens to ADE-encrypted VMs after a stated future date near or after September 15, 2028. The correct framing is service disruption at reboot (disks fail to unlock), not an immediate hard stop, and the recommended remediation is migrating to encryption at host before that date.
• A scenario wants encryption that survives even a compromised or malicious host administrator. That points to confidential disk encryption on a confidential VM size, not encryption at host, which trusts the host layer by design.
• A scenario references minimizing CPU overhead from encryption. Both encryption at host and confidential disk encryption avoid consuming the VM’s own CPU; ADE does not, because it runs the encryption workload inside the guest.

Once you can place ADE, encryption at host, and confidential disk encryption on the same mental timeline, from legacy and retiring, to current default, to specialized high-assurance tier, the domain stops being a memorization exercise and becomes straightforward requirement-matching. If you want to see how AZ-104 actually phrases these trade-offs, work through AZ-104 practice questions that mix disk encryption scenarios with the rest of the compute domain.