Secure Boot Certificates 2026: What administrators need to do now

In 2026, secure boot certificates from 2011 will expire, certificates that have been an integral part of almost all Windows systems since Windows 8. The good news: No system will simply fail. The important news is that without updated certificates, devices will no longer be able to receive security-relevant boot updates in the long term and will therefore remain permanently unpatched at a particularly critical level.

This article is aimed at IT administrators and IT architects and answers the key questions: Which certificates are due to expire and what testing and preparation measures should be planned now?

Secure Boot Certificates 2026: Facts for IT administrators

What is changing:

• Secure Boot does not check expiry dates, systems will continue to boot after 2026
• Expired Secure Boot certificates can no longer sign new boot components
• Devices without updated certificates will no longer receive security-relevant boot updates in the long term
• Microsoft has been distributing new certificates via Windows Update since 2023

What IT admins need to do now:

• Check whether managed environments explicitly allow the update
• Verify whether devices are already using certificates from the new chain

Consequence: Systems without updated secure boot certificates remain operational, but will not receive boot security updates in the long term.

What is Secure Boot? Brief classification for administrators

Secure Boot is a component of the UEFI firmware and protects the so-called boot chain. When the system starts up, it checks whether the boot loader, UEFI drivers and other early components are cryptographically signed. The basis of trust is formed by certificates and keys that are stored directly in the firmware.

Important in practice: Secure Boot is not a Windows feature in the narrower sense, but a combination of firmware, secure boot databases (PK, KEK, db, dbx) and the Boot Manager signed by Microsoft. Although Windows actively manages this data, it is technically dependent on the capabilities of the UEFI firmware.

Secure Boot is therefore part of a continuously maintained trust model in which trustworthy components are defined and regularly adapted via updated keys and revocation lists.

Which secure boot certificates will expire in 2026?

Secure boot certificates from 2011, which have been used as standard since Windows 8, are particularly affected. These include certificates for the Key Exchange Key database (KEK) and signature certificates for the Windows Boot Manager.

The following overview shows which certificates are specifically affected, when they expire and which replacements Microsoft is providing:

* Microsoft will split the previous UEFI CA 2011 into two certificates in future. This enables more precise control over which components you trust.

Important: Secure Boot does not actively evaluate the expiry date of these certificates. A device with expired certificates will therefore continue to boot without problems even after 2026. Boot components that have already been signed will continue to function without restriction.

The actual impact: Update capability, not boot failure

The critical impact is not seen at startup, but with future updates. Expired certificates can no longer be used to sign new or updated boot components. This means that systems without updated secure boot databases cannot receive any further security fixes for the boot process.

For administrators, this means that everything remains calm in the short term, but in the medium term a security gap is created at a particularly sensitive level. Especially in regulated environments or with longer hardware runtimes, this is not an acceptable situation.

What should administrators do now?

For most environments, no hectic action is necessary, but conscious preparation is. The measures can be divided into three levels.

• Update level
  • Ensure that Windows updates are not permanently blocked or extremely delayed
  • Check in WSUS, Intune or GPO setups whether secure boot servicing is explicitly permitted
• Firmware level
  • Evaluate UEFI/BIOS versions, especially for devices that are more than three to four years old.
  • Include firmware updates in the regular lifecycle planning
• Operation & special cases
  • Check whether devices are already using certificates from the 2023 secure boot chain
  • Consider offline systems, isolated networks, custom key setups and old reference images separately

Check secure boot status: PowerShell, event log and registry

There are several ways to check whether a system is already using the new secure boot certificate chain (e.g. Windows UEFI CA 2023). Ideally, PowerShell queries should be combined with event log analyses and, if necessary, a check in the UEFI setup.

In practice, three key questions are sufficient:

• Does the device already use the new secure boot certificate chain (e.g. "Windows UEFI CA 2023")?
• Has the update been carried out successfully according to the event log?
• What rollout status does the registry report?

The following steps can be carried out directly under Windows with an administrative PowerShell:

1. Check the active secure boot database (DB)

The active DB contains the certificates that are actually used during the boot.

Use this command to check whether "Windows UEFI CA 2023" is already active:

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).Bytes) -match "Windows UEFI CA 2023"

• True: The new certificate is active and will be used at startup.
• False: The device is still using the old (2011) certificates.

2. Eventlog: Has the update been completed?

The secure boot servicing process logs its progress in the system event log:

• Event 1801: Update prepared / in progress
• Event 1808: Update successfully completed

3. Registry: Read rollout status

Windows also documents the status in the registry:

HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing

Key: UEFICA2023Status possible values:

• Updated: Update completed
• InProgress: Rollout in progress
• NotStarted: Update not yet started

4. Check in the UEFI/BIOS setup (optional)

If you want to be sure, also check the firmware. Depending on the manufacturer, the entries can be found under e.g:

Secure Boot → Key Management

Entries such as these should be visible there:

• Windows UEFI CA 2023
• Microsoft Corporation KEK 2K CA 2023

New group policies (ADMX) for Secure Boot from October 2025

For larger and centrally managed environments, Microsoft will provide new administrative templates (ADMX) from October 2025. These ADMX templates contain three new Group Policies that are specifically designed to manage the Secure Boot certificate update.

These can be found within the Group Policy Editor under

Computer Configuration → Administrative Templates → Windows Components → Secure Boot

The new policies are used to configure the already known registry keys and allow administrators to control the update process in a more structured and consistent way.

The three new policies:

• Enable Secure Boot certificate updates Enables the secure boot servicing mechanism for updating the certificates and the signed boot manager.
• Configure Microsoft Update Managed Opt In Sets the registry value MicrosoftUpdateManagedOptIn. It allows Microsoft to update the secure boot certificates as part of a controlled feature rollout via Windows Update.
• Configure High Confidence Opt Out Controls whether a device is excluded from the so-called high-confidence bucket. This mechanism is used by Microsoft to prioritise certificate updates on systems where firmware and hardware compatibility are considered to be particularly high.

All three policies write values below:

HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot

Technically, this is nothing new; the policies are an administrative simplification for what could previously only be done manually via the registry. For managed environments, however, this is a relevant difference: the rollout can now be controlled consistently and documented.

Typical pitfalls during secure boot rollout

The most common source of errors is not Windows itself. In practice, the rollout almost always fails due to boundary conditions that at first glance have nothing to do with Secure Boot:

• deactivated Secure Boot options
• outdated firmware
• restrictive update releases or
• long unpatched reference images.

Devices that receive regular Windows security updates but where secure boot servicing is unknowingly blocked are particularly critical. Monitoring and patch reporting show these systems as up-to-date, but they are still left out of the secure boot rollout without anyone noticing.

Conclusion: No alarmism, but a clear admin task

The expiry of the Secure Boot certificates in 2026 is not an emergency, but a clear task for administrators. Anyone who actively runs Windows Update, firmware and Secure Boot will hardly see any problems. On the other hand, anyone who has not considered Secure Boot for years should consciously put the topic on the agenda now. Precisely because the effect is delayed, now is the right time for testing, planning and a clean rollout.

Secure Boot is not a project for "sometime later", but one that can be completed today in a controlled manner without time pressure. If you wait until a critical update fails, you have already missed the window of opportunity for controlled preparation.

Now is the right time, not later.

Do you know where your environment really stands?

The critical pitfalls in a secure boot rollout are rarely obvious: blocked servicing, outdated firmware, overlooked offline systems. In a free readiness check, we work together to see whether and where there is a need for action in your environment.

Request a readiness check now and arrange an appointment

Frequently asked questions about Secure Boot Certificates 2026

Will Windows continue to boot after the Secure Boot certificates 2026 expire?

Yes, Secure Boot does not check the expiry date at system startup, only the signature. Devices with the 2011 certificates will therefore start as usual even after June and October 2026. Boot components that have already been signed will continue to work. What will be lost is the option to receive new boot security updates and updated revocation lists.

Which devices are particularly affected by the secure boot certificate change?

Three device groups are particularly critical: systems with permanently blocked or heavily delayed Windows updates, devices with outdated UEFI firmware, often more than three to four years old, as well as offline or isolated environments that do not receive servicing automatically. You should also check devices with custom key setups and old reference images separately.

Do I have to deactivate Secure Boot to avoid problems?

No. Disabling Secure Boot is not a recommended response to the certificate change and significantly weakens platform security. The clean solution is to allow Secure Boot Servicing and ensure that the device receives the new 2023 certificates via Windows Update.

Are Windows Servers affected by the Secure Boot certificate change?

Yes, Windows Server uses the same chain of trust as Windows Client and is therefore equally affected. Unlike client systems, the new certificates on servers are not rolled out automatically via the regular updates. Administrators must actively initiate and monitor the update.