diskEncryptionSet planning for custom CMK from managed HSM

Question

diskEncryptionSet planning for custom CMK from managed HSM

prasantc 981

I am working on script to replace all vm disk encryption for both Linux dm-crypt and windows bitlocker with the HSM generated key.

I wonder if it is recommended to create diskEncryptionSet per vm that way same key is not used per VM and perhaps used single key and diskEncryptionSet per VM and scalset, that way scaletset and VM disks could share same key and diskEncryptionSet.

diskEncryptionSet can only support single key. I see the potential for 2k to 3k diskEncryptionSet per subscription. Is it a normal approach for diskEncryptionSet?

Ankit Yadav 4,385 Reputation points Microsoft External Staff Moderator

2025-11-06T02:24:04.6766667+00:00

Hello @prasantc

Azure does not require a separate Disk Encryption Set (DES) and key per VM. You can reuse a single Disk Encryption Set (and its customer-managed key) across multiple VMs or an entire scale set.

In practice, many deployments use one DES per application or scale set for simpler management, rather than one per VM. Creating 2,000–3,000 DES (one per VM) is supported but this is at the high end of usage and adds significant management overhead.

From Security standpoint, using unique encryption keys per VM is the safest option because it provides the highest isolation and if one VM’s key is compromised or misused, it doesn’t directly affect others.

However, using unique keys per VM may be overkill if all those VMs are under the same administrative control and security policy. In such cases, the extra isolation might not meaningfully reduce risk but will increase admin burden.

Reference: https://learn.microsoft.com/en-us/azure/virtual-machines/disk-encryption

Conclusion: The idea is to strike a balance between security and ease of management—go for unique keys (one DES per VM) only if you have strict compliance or isolation needs. Otherwise, it's fine to group VMs and let them share DES/keys where it makes sense.

Just let me know if this answers your query up or if you have any other questions related to it.
prasantc 981 Reputation points

2025-11-06T15:47:54.1+00:00

Some document says it maintains separate version for key used on each VM but I am not seeing different versions to the key on my test.

If there is not different version, then I am thinking of one DES per env/ per subscription / per region approach. Hopefully, it wont be an overkill.

Not sure how DES plays when HSM copy needs to be replicated the DR situation when KV is restored in DR site and VM are restored with ASR?
Ankit Yadav 4,385 Reputation points Microsoft External Staff Moderator

2025-11-07T07:45:58.8566667+00:00

Few clarifications @prasantc

Separate version for key per VM?

This is not by default. All VMs using the same DES will show the same key version (current or latest) unless you use different key versions.

One DES per env/sub/region—overkill?
Yes it's not, it's common manageable pattern that keeps secret rotation/RBAC easy however it becomes difficult for users sometimes to manage that many keys so it's advised to avoid per‑VM DES unless you have strict isolation requirements.

Not sure how DES plays when HSM copy needs to be replicated the DR situation when KV is restored in DR site and VM are restored with ASR?

This kind of goes out of the scope of this question as it needs to be covered under ASR topic thus, I'd recommend posting a new question with the ASR or keyvault related query as per the community guidelines. We sincerely appreciate your understanding, and we look forward to supporting you on the new thread.

Reference : https://learn.microsoft.com/en-us/answers/support/quality-question#avoid-posting-multiple-questions…

Your answer

Ankit Yadav 4,385 Reputation points Microsoft External Staff Moderator

2025-11-06T02:24:04.6766667+00:00

Hello @prasantc

Azure does not require a separate Disk Encryption Set (DES) and key per VM. You can reuse a single Disk Encryption Set (and its customer-managed key) across multiple VMs or an entire scale set.

In practice, many deployments use one DES per application or scale set for simpler management, rather than one per VM. Creating 2,000–3,000 DES (one per VM) is supported but this is at the high end of usage and adds significant management overhead.

From Security standpoint, using unique encryption keys per VM is the safest option because it provides the highest isolation and if one VM’s key is compromised or misused, it doesn’t directly affect others.

However, using unique keys per VM may be overkill if all those VMs are under the same administrative control and security policy. In such cases, the extra isolation might not meaningfully reduce risk but will increase admin burden.

Reference: https://learn.microsoft.com/en-us/azure/virtual-machines/disk-encryption

Conclusion: The idea is to strike a balance between security and ease of management—go for unique keys (one DES per VM) only if you have strict compliance or isolation needs. Otherwise, it's fine to group VMs and let them share DES/keys where it makes sense.

Just let me know if this answers your query up or if you have any other questions related to it.
prasantc 981 Reputation points

2025-11-06T15:47:54.1+00:00

Some document says it maintains separate version for key used on each VM but I am not seeing different versions to the key on my test.

If there is not different version, then I am thinking of one DES per env/ per subscription / per region approach. Hopefully, it wont be an overkill.

Not sure how DES plays when HSM copy needs to be replicated the DR situation when KV is restored in DR site and VM are restored with ASR?
Ankit Yadav 4,385 Reputation points Microsoft External Staff Moderator

2025-11-07T07:45:58.8566667+00:00

Few clarifications @prasantc

Separate version for key per VM?

This is not by default. All VMs using the same DES will show the same key version (current or latest) unless you use different key versions.

One DES per env/sub/region—overkill?
Yes it's not, it's common manageable pattern that keeps secret rotation/RBAC easy however it becomes difficult for users sometimes to manage that many keys so it's advised to avoid per‑VM DES unless you have strict isolation requirements.

Not sure how DES plays when HSM copy needs to be replicated the DR situation when KV is restored in DR site and VM are restored with ASR?

This kind of goes out of the scope of this question as it needs to be covered under ASR topic thus, I'd recommend posting a new question with the ASR or keyvault related query as per the community guidelines. We sincerely appreciate your understanding, and we look forward to supporting you on the new thread.

Reference : https://learn.microsoft.com/en-us/answers/support/quality-question#avoid-posting-multiple-questions…

Share via

diskEncryptionSet planning for custom CMK from managed HSM

Your answer