Azure Compute Gallery image version does not persist securityProfile.uefiSettings even with supported security type (ConfidentialVmSupported)

Question

I’m trying to append custom UEFI DB keys to a private Azure Compute Gallery image version for a Confidential VM. I understand from Microsoft’s guidance and Q&A that **uefiSettings **is only supported when the image definition security type is one of: TrustedLaunchSupported, ConfidentialVmSupported, or TrustedLaunchAndConfidentialVmSupported. (learn.microsoft.com)

We’ve confirmed the image definition is set to** ConfidentialVmSupported (not ConfidentialVM****)**, and the VM is created with --security-type ConfidentialVM + Secure Boot + vTPM enabled.

Issue: The REST PUT response for the image version includes securityProfile.uefiSettings (with signatureTemplateNames + additionalSignatures.db), but once the version reaches Succeeded, a GET / az sig image-version show no longer contains securityProfile.uefiSettings. The setting appears to be dropped internally. As a result, the VM boots with the stock Canonical UKI and ignores our re‑signed UKI/initrd changes.

What I need:

• A supported and working way to persist custom UEFI DB keys on a Compute Gallery image version for Confidential VMs, given the image definition security type is already supported.
• Confirmation whether there are additional constraints (region/subscription/feature flag) that cause the platform to drop uefiSettings even when the image definition is compliant.

Environment summary:

• PII info

Question: What is the correct, supported way to persist securityProfile.uefiSettings on a SIG image version when the image definition is already** ConfidentialVmSupported**, and why might Azure drop it after provisioning?

Answer 1

Hello Patrick Foley

This behavior is by design when using Azure Compute Gallery (SIG) image versions with Confidential VM security.

Although the image definition security type is set to confidential VM supported, custom security Profile.uefisettings are not persisted on the image version for Confidential VMs. During image version creation, the REST API may temporarily accept the uefisettings payload, but once the image version reaches the Succeeded state, the platform drops this configuration internally. As a result, any VM created from that image boots using the default Microsoft/Canonical UEFI trust chain, and custom DB keys are ignored.

This matches what you are observing:

• PUT on the image version includes security Profile.uefisettings
• GET on the finalized image version no longer shows uefisettings
• The VM boots with the stock UKI instead of the re‑signed components

At this time, Azure does not support persisting custom Secure Boot UEFI keys on Compute Gallery image versions for Confidential VMs, even though the image definition security type is marked as supported.

Actions to perform

Use Trusted Launch :
If persisting custom UEFI DB keys is a requirement:

1. Create the image definition with security type set to Trustedlaunchsupported or Trusted Launch and confidentail VM support
2. Apply security Profile.uefisettings at image version creation time using the REST API
3. Deploy VMs using Trusted Launch (Secure Boot + vTPM)

This is the only documented and supported path for custom UEFI key persistence today.

https://learn.microsoft.com/en-us/azure/virtual-machines/trusted-launch-secure-boot-custom-uefi

Confidential VM

If you must stay on Confidential VM security:

• Use default Microsoft‑signed boot components
• Custom DB/DBX/KEK keys cannot be persisted via Compute Gallery
• This is a current platform limitation, not a configuration issue

https://learn.microsoft.com/en-us/azure/confidential-computing/create-confidential-vm-from-compute-gallery

Thanks,
Manish.