Microsoft Secure Boot certificates expiration guide

This document provides guidance for how to update Compute Engine Shielded VM instances so that they trust the updated Microsoft Secure Boot certificates for UEFI (Unified Extensible Firmware Interface) Secure Boot.

UEFI Secure Boot is a security standard that Shielded VMs use to ensure that only trusted software and firmware run during the VM boot process. To support Secure Boot across various operating systems, Microsoft manages the following certificates.

Expiring Secure Boot certificates

Certificate name	Role	Expiration date
Microsoft Corporation UEFI CA 2011	Signs third-party bootloaders (for example, Linux Shim)	June 27, 2026
Microsoft Windows Production PCA 2011	Signs the Windows bootloader	October 19, 2026
Microsoft Corporation KEK CA 2011	Used to update the DB and DBX	June 24, 2026

To avoid potential boot issues, if you use Secure Boot on Compute Engine instances created before November 7, 2025, you must ensure your instances have the updated certificates installed. This update is equally critical for compute instances using full disk encryption (FDE) software, including BitLocker, or secret sealing to vTPM Platform Configuration Registers (PCRs). This guide outlines how to identify affected instances and perform the necessary updates.

Compute instances created on or after November 7, 2025, include the updated certificates and don't require further action. Additionally, the Secure Boot certificate expiration doesn't affect the following:

Instances that don't use vTPM Platform Configuration Registers (PCRs) for secret sealing and don't have Secure Boot enabled. Secure Boot isn't enabled by default when you create a Shielded VM instance.
Instances running Container-Optimized OS (COS).
Instances where you provide your own Secure Boot Platform Key (PK) or Key Enrollment Key (KEK).

For compute instances created before November 7, 2025, the primary recommendation is to migrate these instances to new instances created on or after this date. For compute instances that you can't recreate, Google plans to provide manual update instructions in this document when they are available.

How Secure Boot certificate expiration affects Shielded VM

If enabled, Shielded VM enforces Secure Boot using UEFI firmware, which maintains a set of trusted certificates (in the db variable) to verify boot sequence binaries' signatures. If, for example, an OS update replaces a bootloader with one signed only by Microsoft UEFI CA 2023, and the compute instance's firmware doesn't trust this certificate authority, Secure Boot verification fails, and Secure Boot stops the boot process.

For more details on this transition, see guidance from Microsoft and other OS vendors:

Operating system impact

If you enabled Secure Boot on a Shielded VM instance created before November 7, 2025, you must ensure the guest OS trusts the Microsoft UEFI CA 2023 certificate. If you don't install the new certificates, the compute instance may face potential boot issues following an update containing a bootloader signed only by the 2023 certificate. If you take no action, you might not be able to apply new bootloader or kernel updates containing binaries signed only with the 2023 certificate, potentially leaving systems more vulnerable to certain attacks. For compute instances created prior to November 7, 2025, if you don't apply certificate updates before mid-2026, Windows customers may see Event ID 1801 ("Secure Boot CA/keys need to be updated") in the System event log.

Google-provided public images: We recommend that you recreate the compute instance. Recreating the instance ensures that it uses the latest firmware, certificates, and OS configuration by default.
Manual update: If you can't recreate the instance, you can't update the instance firmware with new certificates. You must wait for Google to provide the manual update instructions.
Custom or imported images: You must ensure your images trust the Microsoft UEFI CA 2023 certificate. To ensure this trust, rebuild your custom images by using a Google-provided base image, or manually deploy the appropriate certificates.

Required actions

If you have compute instances that were created before November 7, 2025, with Secure Boot enabled, or if they use full disk encryption (FDE) software (including BitLocker on Windows and other FDE on Linux), Virtual Secure Mode (VSM) on Windows, or secret sealing in vTPM Platform Configuration Registers (PCRs), then you must perform the actions that are detailed in the following sections. This guidance also applies if you roll back to a machine image from before November 7, 2025.

Important: If you use full disk encryption (FDE) software, including BitLocker, ensure you have access to your recovery keys before you make any changes.

Identify affected compute instances and plan for update

By June 24, 2026, we recommend that you identify the affected compute instances, and take the following steps to prepare for the update:

Identify instances: You can use the gcloud compute instances list command to identify instances that have Secure Boot enabled and were created before the cutoff date:

gcloud compute instances list \
--filter="creationTimestamp < '2025-11-07' AND shieldedInstanceConfig.enableSecureBoot=true" \
--format="table(name, zone, creationTimestamp, shieldedInstanceConfig.enableSecureBoot:label=SECURE_BOOT)"

Ensure data integrity: Ensure you have recent data backups and access to any full disk encryption (FDE) or BitLocker recovery keys before you proceed with any changes.
Recommendation: Migrate to a compute instance created on or after November 7, 2025, which includes the necessary certificates.
Manual update instructions: Google plans to provide instructions for manually updating certificates on long-running instances on this page after testing is complete and the necessary commands are available. Google doesn't recommend upgrading db or KEK certificates manually at this time. Wait for additional instructions.

Verification

After updating the firmware and OS for your compute instances, you can verify that the 2023 certificates are present.

Linux

If efi-readvar isn't present, install the efitools package. To install on Linux, run the command for your distribution:

Debian/Ubuntu
```
sudo apt update && sudo apt install efitools
```
RHEL/CentOS/Fedora
```
sudo yum install efitools
```
SLES
```
sudo zypper install efitools
```
Check for the certificates in the KEK and db variables:

sudo efi-readvar -v KEK | grep "KEK 2K CA 2023"
sudo efi-readvar -v db | grep "UEFI CA 2023"

Windows (PowerShell)

Run the following in an administrator PowerShell prompt. Each command should return True.

# Check for Microsoft KEK 2K CA 2023
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).bytes) -match 'Microsoft Corporation KEK 2K CA 2023'

# Check for UEFI CA 2023
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'UEFI CA 2023'

Troubleshooting

If an instance fails to boot due to a Secure Boot error after June 2026, you can try one of the following options to recover it:

Temporarily disable Secure Boot: This lets you boot the instance to apply updates.

Note: Disabling Secure Boot changes the PCR values (specifically PCR7), which may affect secret sealing or disk encryption functionality.

To disable Secure Boot, run the following command:
```
gcloud compute instances update INSTANCE_NAME --no-shielded-secure-boot
```
After the instance boots, apply the required operating system and boot component updates, and then re-enable Secure Boot:
```
gcloud compute instances update INSTANCE_NAME --shielded-secure-boot
```
Restore from backup: Restore the instance from a machine image created before boot issues began.
Recreate instance: Recreate the instance and recover data from a snapshot.

If you continue to encounter issues or need help, contact Cloud Customer Care.

Frequently Asked Questions (FAQ)

This section provides answers to common questions about the Microsoft Secure Boot certificate expiration.

When do Secure Boot certificates expire?

Microsoft's Secure Boot certificates are expiring in 2026. Specifically:

The two most critical certificates nearing their end of life are the Microsoft Corporation UEFI CA 2011 (expires June 2026), which signs third-party bootloaders (like the Linux Shim), and the Microsoft Windows Production PCA 2011 (expires October 2026), which signs the Windows bootloader.

Does the expiration affect both Windows and Linux customers?

Yes, the expiration affects both Windows and Linux customers.

Who is affected by the certificate expiration?

This issue might affect only customers with long-running compute instances created before November 7, 2025. Affected instances include the following:

Linux and Windows VMs with Secure Boot enabled.
Any instance using Virtual Trusted Platform Module (vTPM) Platform Configuration Registers (PCRs) for secret sealing.
Windows compute instances that use disk encryption (BitLocker) or Virtual Secure Mode (VSM).
Linux VMs using full disk encryption (FDE).
Instances that roll back to a pre-November 2025 machine image.

Who is not affected by the certificate expiration?

You are not affected if you fall into one of the following categories:

You don't use Secure Boot, secret sealing in vTPM PCRs, or full disk encryption (including BitLocker).
You use Container-Optimized OS (COS) Linux instances.
You provide your own Platform Key (PK) or Key Enrollment Key (KEK). If you use your own PK or KEK, Compute Engine uses your custom keys, so the expiration of the default certificates doesn't affect you. However, you are responsible for managing your own keys and ensuring your certificates are up to date.

What happens if I take no action?

If you take no action, you might not be able to apply new bootloader or kernel updates containing binaries signed only with the 2023 certificate, potentially leaving systems more vulnerable to certain attacks. For compute instances created prior to November 7, 2025, if you don't apply certificate updates before mid-2026, Windows customers may see Event ID 1801 ("Secure Boot CA/keys need to be updated") in the System event log.

How should I prepare for the certificate expiration?

To prepare, take the following steps:

Identify: Audit your usage of Shielded VMs, Secure Boot, full disk encryption (FDE), BitLocker, or any software that relies on vTPM PCRs.
Recovery keys & backups: Ensure prompt availability of recovery keys (for FDE/BitLocker) and latest data backups.
Manage images: Identify legacy custom images and discontinue their usage or ensure they include the new certificates.
Migrate: Consider recreating any long-running compute instances created prior to November 7, 2025, as new instances already include the necessary certificates.
Note: Google doesn't recommend manually upgrading certificates at this time. Wait for future instructions from Google that we'll publish on this document.

What should I do if my system stops booting after June 2026?

If you believe this issue caused a boot failure, see Troubleshooting.

How is Google Cloud handling the Microsoft Secure Boot certificates expiration?

Google Cloud automatically included the new certificates for compute instances created after November 7, 2025. Only customers who want to keep their pre-November 7, 2025, compute instances running might need to apply a future manual update, but Google recommends migrating to an instance created on or after November 7, 2025.

What's next

Learn more about Shielded VM.
Learn how to modify Shielded VM options.
Learn more about Secure Boot.

Microsoft Secure Boot certificates expiration guide Stay organized with collections Save and categorize content based on your preferences.