Microsoft Secure Boot certificates expiration guide

Because some of Microsoft's Secure Boot certificates expire in 2026, 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. The two most critical certificates nearing expiration are the Microsoft Corporation UEFI CA 2011 (expires June 27, 2026), which signs third-party bootloaders (like the Linux Shim), and the Microsoft Windows Production PCA 2011 (expires October 19, 2026), which signs the Windows bootloader.

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 UEFI certificates.

Secure Boot certificates and expiration dates

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

If you use Secure Boot on Compute Engine instances created before November 7, 2025 and you want to continue receiving firmware updates to avoid potential boot issues in the future, install updated certificates. This document explains how to identify affected instances and perform the necessary updates.

The rollout of new certificates finished on November 7, 2025. Instances created on or after this date include the updated certificates and don't require further action. However, some instances created in the weeks before this date might also include the new certificates. To check if your system is current, use the commands provided in the Verification section of this document.

Note: 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 that don't have the updated certificates, follow the KEK and db update guide to update the certificates; if for whatever reason you can't do that, consider recreating your instances.

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's 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, we recommend that you ensure that the 2023 certificates are installed; otherwise, the compute instance may face boot issues following an update containing a bootloader signed only by the Microsoft UEFI CA 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 might see Event ID 1801 ("Secure Boot CA/keys need to be updated") in the System event log.

Google-provided public images: Update DB and KEK certificates by following the KEK and db update guide. Alternatively, consider recreating any long-running VMs created before November 7, 2025.
Custom or imported images: We recommend that you ensure that instances created using your images trust the Microsoft UEFI CA 2023 certificate. If your image contains embedded certificates that don't include the Microsoft UEFI CA 2023 certificate, you can update your image by deploying the appropriate certificates, or you can rebuild it. To rebuild your image, start from a Google-provided base image and re-apply your customizations. Google-provided images don't contain embedded certificates, so Compute Engine provides the updated certificates when you create an instance from such an image.

Recommended 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 using vTPM Platform Configuration Registers (PCRs) for secret sealing, then you should review 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.

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,shieldedInstanceConfig.enableIntegrityMonitoring:label=INTEGRITY_MONITORING)"

Ensure data integrity: Ensure you have recent data backups and access to any FDE or BitLocker recovery keys before you proceed with any changes.
Update certificates: Update DB and KEK certificates by following the KEK and db update guide. Alternatively, migrate to a compute instance created on or after November 7, 2025, which includes the 2023 certificates, by following the instructions in Recreate a compute instance from a disk snapshot.

Recreate a compute instance from a disk snapshot

When you take a disk snapshot and create a new instance from it, the new compute instance inherits a fresh firmware (vTPM/NVRAM) state that trusts the updated defaults and clears out old certificates.

Before recreating a compute instance from a snapshot, ensure that the guest OS has all the necessary updates installed (such as relevant Microsoft KBs for Windows, or the latest Shim for Linux distributions) to trust the 2023 certificates.

You can use the following sequence of gcloud commands to manage this migration:

Identify the boot disk: Determine the name of the boot disk attached to your source compute instance:

SOURCE_DISK=$(gcloud compute instances describe SOURCE_INSTANCE_NAME \
    --zone=ZONE \
    --format="value(disks[0].source.basename())")

Create a disk snapshot: Take a snapshot of that boot disk. For optimal data integrity, stop the compute instance before running this command:

gcloud compute disks snapshot $SOURCE_DISK \
    --snapshot-names="migration-snapshot-$(date +%s)" \
    --zone=ZONE \
    --storage-location=REGION

Create a new compute instance: Provision a fresh compute instance by using the snapshot as the boot source. If Secure Boot is enabled on the source instance, include the --shielded-secure-boot flag to enable Secure Boot on the new instance.

gcloud compute instances create NEW_INSTANCE_NAME \
    --zone=ZONE \
    --machine-type=MACHINE_TYPE \
    --create-disk=name=NEW_DISK_NAME,source-snapshot=SNAPSHOT_NAME,boot=yes \
    --shielded-secure-boot

Note: Instances provisioned using this approach receive new internal and external IP addresses unless statically allocated and specifically reassigned. Instance-level metadata, tags, and service accounts are not automatically replicated and must be configured explicitly during recreation.

Verification

After updating the firmware and OS for your compute instances, you can verify that the 2023 certificates are present. If both the KEK and db variables show the 2023 certificates are present, your instance is up to date and no further action is required.

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'

# Confirm general Secure Boot enrollment state
Confirm-SecureBootUEFI

Troubleshooting

If an instance fails to boot due to a Secure Boot error after June 2026, 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 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, your instance continues to boot and operate as normal with its existing binaries. However, 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.

Will failing to update certificates prevent Windows instances from starting up?

No. Failure to remediate won't prevent Windows system startup. However, you might see Event ID 1801 ("Secure Boot CA/keys need to be updated") in the System event log, and you won't be able to apply new kernel or bootloader security updates containing binaries signed only with the new 2023 certificate.

What specific conditions trigger boot failures on Linux?

A boot failure may happen on Linux under specific conditions:

The instance has Secure Boot enabled.
The db UEFI variable isn't updated to trust the "Microsoft UEFI CA 2023" certificate.
The OS updates a bootloader (or shim) that relies strictly on that certificate.

If you don't apply certificate updates or shim updates that reference the new certificates, your Linux instance will continue to boot successfully.

How do I determine if my instance has the updated certificates?

To determine if your instance includes the new certificates in its firmware, refer to the commands outlined in the Verification section. If certificates are missing, you can update them by following the KEK and db update guide, or recreate the instance.

Does restarting or rebooting an affected instance solve the issue?

No. Restarting or rebooting a compute instance doesn't update its secure boot certificates, but the instance continues to boot and operate normally with its existing certificates until a bootloader or kernel update is applied that contains binaries signed only with the 2023 certificate. If you restart the compute instance, it retains the old certificates if it was originally created before November 7, 2025. The certificates are part of the instance's firmware (vTPM/NVRAM). Therefore, you need to follow the KEK and db update guide or recreate the instance to apply the new certificates.

How should I prepare for the certificate expiration?

To prepare, take the following steps:

Identify: Audit your usage of Shielded VMs, Secure Boot, 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.
Update or migrate: If you want to update certificates instead of recreating the instance, refer to the KEK and db update guide. Alternatively, consider recreating any long-running compute instances created prior to November 7, 2025, as new instances already include the necessary certificates.

What are the recommended methods for recreating or migrating affected instances?

Standard disk snapshots provide the most reliable method. A snapshot is a block-level copy of the disk and contains no UEFI variables or instance-level metadata. To restore using a snapshot, do the following:

Create a snapshot of the instance's boot disk.
Create a new compute instance and select the snapshot as the source for the boot disk.

You shouldn't use machine images, instance cloning, or the Backup and DR Service for this migration because they replicate the instance firmware and retain the old certificates for any source compute instance created before November 7, 2025.

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 update, but we recommend 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.