# Choose UEFI key replacement or extension deliberately in a gallery image

> Will a custom Azure image replace the default Secure Boot databases or add to their trust?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-095-choose-uefi-key-replacement-or-extension-deliberately-in-a-gallery-image/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:30:21+00:00
- Modified: 2026-09-10T00:35:08+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, IT
- Reading time: 2 minutes

## What you need to know

Will a custom Azure image replace the default Secure Boot databases or add to their trust?

## Potentially affected

Advanced image owners customizing UEFI trust for secure-boot-capable Azure VMs in supported public-cloud regions.

## DSE recommendation

Have the signing owner approve the exact trust databases that will be retained, replaced, or extended.

## Article

## Source facts

Azure’s custom UEFI-key feature operates through Compute Gallery image versions and is currently exposed only through REST. Its documented scenarios distinguish replacing all default PK, KEK, DB, and DBX values from adding DB and DBX entries to a default signature template. The image definition must use a supported security type. Microsoft excludes US Government and China clouds and lists public-region exceptions. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/virtual-machines/trusted-launch-secure-boot-custom-uefi).

## Applicability

Limit this work to an advanced image-signing requirement with an owner who understands Secure Boot trust. Check the exact region and image-definition security type against the current source. Identify the boot components that must remain trusted before choosing a replacement or append scenario.

## DSE recommendation

Have the signing owner approve the exact trust databases that will be retained, replaced, or extended. Keep the proposed keys and revocations associated with a specific image version and review the chosen signature template explicitly. Preserve a separately validated recovery image and prevent a sample template from becoming the production trust policy without review.

## Verification

Create a bounded test VM from the intended image version, then inspect its actual UEFI databases against the approved entries. Verify that the intended boot chain works and that a deliberately disallowed test component is rejected under controlled conditions. Retain public-certificate fingerprints, image identity, and results without exporting private signing keys. Treat successful VM creation as separate from confirmation that the resulting trust database matches the design.

## Official references

[Microsoft Learn: Secure Boot UEFI keys](https://learn.microsoft.com/en-us/azure/virtual-machines/trusted-launch-secure-boot-custom-uefi). Source reviewed September 9, 2026.

## Primary reference

- Name: Secure Boot UEFI keys - Azure Virtual Machines | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/virtual-machines/trusted-launch-secure-boot-custom-uefi
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Choose UEFI key replacement or extension deliberately in a gallery image,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-095-choose-uefi-key-replacement-or-extension-deliberately-in-a-gallery-image/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.
