Secure Boot is a security standard that ensures only trusted software runs during the boot process. In Azure, Secure Boot uses UEFI (Unified Extensible Firmware Interface) keys to validate the integrity of boot loaders and drivers.
- Default Keys: Azure VMs use Microsoft-signed UEFI keys by default.
- Custom Keys: You can configure custom Secure Boot keys for specialized workloads.
- Benefits: Protects against rootkits and boot-level malware, ensuring a trusted boot environment.
For advanced scenarios, you may need to customize Secure Boot keys. This feature allows you to modify Unified Extensible Firmware Interface (UEFI) keys—PK, KEK, DB, and DBX—within your image for Secure Boot–enabled Azure virtual machines (Trusted Launch and Confidential VMs). You can fully replace the default UEFI key databases or append custom keys to them, providing greater flexibility and control over the boot process.
UEFI Secure Boot relies on four key databases stored in firmware:
| Key | Purpose |
|---|---|
| PK (Platform Key) | Root of trust, controls Secure Boot state |
| KEK (Key Exchange Keys) | Authorizes updates to signature databases |
| db | Allowed bootloader & driver signatures |
| dbx | Revoked / blocked signatures |
High‑level sequence for using Azure Secure Boot UEFI keys with Trusted Launch / Confidential VMs. This focuses on the custom‑keys path where you control PK/KEK/DB/DBX.
Prerequisites
- Use Generation 2 VM images that support Trusted Launch or Confidential VMs (image definition with
TrustedLaunchSupportedorTrustedLaunchAndConfidentialVmSupported). - Decide whether to append to Microsoft’s default keys or fully replace them with your own PK/KEK/DB/DBX set
Create or collect keys and certificates
- Generate X.509 certificates for: Platform Key (PK), Key Exchange Key (KEK), one or more DB (allow) certs, and optional DBX (deny) certs.
- Export each relevant certificate (and hashes, if used) in a format acceptable for UEFI (typically DER/PEM, then base64 for ARM calls or templates).
Build or prepare the OS image
- Install your OS and boot stack (bootloader, kernel, drivers) so they are signed with your DB/KEK chain or other trusted certificates you plan to place in DB.
- Generalize the VM (e.g.,
sysprepfor Windows orwaagent -deprovision+userfor Linux) and capture it as a managed image or Azure Compute Gallery image.
Define custom UEFI key settings
- On the image definition (or gallery version), configure
securityProfile.uefiSettingsto include your PK/KEK/DB/DBX (base64‑encoded certs/hashes) and indicate whether to replace or append to defaults. - Validate the JSON structure for these fields against the “Secure Boot UEFI keys” schema in Azure VM docs before creating/updating the image definition.
Create a VM with Trusted Launch + Secure Boot

- When creating the VM, set:
securityProfile.securityTypetoTrustedLaunchorConfidentialVMas required. - Enable Secure Boot in
securityProfile.uefiSettingsalong with vTPM if using Trusted Launch defaults. - Use the custom image definition/version that already has your UEFI key configuration
Boot and verify keys inside the VM
- Start the VM and connect (RDP/SSH). On Linux, inspect Secure Boot state and key databases using tools such as
mokutil --sb-state,mokutil --db, andmokutil --dbxto confirm your certs and hashes are present. - On Windows, verify Secure Boot is on and confirm that only binaries signed with the expected certs load at boot (for example via event logs and driver signature checks).
Test allow/deny behavior
- Test a binary or driver signed with a trusted certificate to confirm it boots/loads successfully under Secure Boot.
- Test a binary signed with an untrusted or explicitly revoked certificate (present in DBX) and confirm it is blocked from boot or driver loading.
Verify keys in UEFI databases
To verify the keys stored in the UEFI databases, run the following commands via SSH on the target virtual machine.
// For key(s) added to db
$ mokutil –db
// For keys(s) added to dbx
$ mokutil –dbx
Reference: Secure boot UEFI keys for Azure Trusted LaunchVMs