Updated on Sep. 01, 2026
Position: Resource - Disk Utilities - Microsoft UEFI Secure Boot Certificates: 2011 vs. 2023 and How to Update
Most people never think about Secure Boot until Windows refuses to start, a firmware update causes trouble, or a security warning appears. Yet Secure Boot is one of the first security mechanisms involved every time a modern PC starts.
Before Windows loads, the UEFI firmware checks the software involved in the boot process and decides whether it is trusted. Those decisions are based on cryptographic keys, certificates, and signature databases stored in the firmware.
Microsoft is currently replacing several Secure Boot certificates that have been in use since 2011. The older certificates begin expiring in 2026 and are being replaced by new 2023 certificates, including Windows UEFI CA 2023, Microsoft UEFI CA 2023, Microsoft Option ROM UEFI CA 2023, and Microsoft Corporation KEK 2K CA 2023.
This does not mean that a PC will suddenly stop working when an older certificate expires. Microsoft states that affected devices can continue to start and run Windows normally, and standard Windows updates can still be installed. The problem is that devices that have not received the replacement certificates may no longer be able to receive new security protections for the early boot process.
This article explains how Microsoft Secure Boot certificates work, why the 2011 certificates are being replaced, how to check which certificates are stored on your PC, and what you can do if your device has not yet received the new certificates.
In this article:
In the traditional BIOS era, a computer could load boot code from a storage device without checking whether that code had been modified or came from a trusted source. This created an opportunity for bootkits and other malware to run before the operating system started.
UEFI Secure Boot was designed to address that problem.
When Secure Boot is enabled, the firmware verifies the digital signatures of pre-boot software before allowing it to run. This can include UEFI drivers, Option ROMs, bootloaders, and EFI applications. If a component is not trusted by the Secure Boot policy stored in the firmware, it may be blocked.
A simplified Windows boot sequence looks like this:
1. The UEFI firmware initializes the hardware and verifies pre-boot components.
2. The firmware verifies that the bootloader is trusted.
3. Control is passed to the bootloader.
4. The Windows bootloader loads and starts the operating system.
This process creates a chain of trust. The trust decisions made at the firmware level determine what is allowed to run before Windows takes control.
Microsoft describes Secure Boot as a firmware-based authentication process that uses public-key cryptography and certificates to determine whether early boot software should be trusted.
The Secure Boot trust model is built around several firmware variables. The names can look intimidating at first, but the basic idea is straightforward.
The Platform Key, or PK, represents the top level of authority for the Secure Boot configuration.
It is usually controlled by the PC manufacturer or platform owner. The PK determines who is authorized to manage the Secure Boot key hierarchy.
A typical Windows PC does not require the user to manually modify the PK.
The Key Exchange Key, or KEK, authorizes updates to the Secure Boot signature databases.
A Windows PC may contain one or more KEKs, including Microsoft and OEM keys. An authorized KEK can be used to sign updates to the allowed and revoked signature databases.
Microsoft's older Microsoft Corporation KEK CA 2011 is being replaced by Microsoft Corporation KEK 2K CA 2023 as part of the current certificate transition.
The db is the main allow list used by Secure Boot.
It can contain certificates, public keys, and hashes that identify trusted software. If an EFI application or boot component is signed by a trusted certificate or otherwise matches an entry in the database, the firmware can allow it to run.
The Microsoft certificates discussed in this article, including Windows UEFI CA 2023, Microsoft UEFI CA 2023, and Microsoft Option ROM UEFI CA 2023, are used in the Secure Boot trust infrastructure associated with the db.
The dbx is the revocation database.
It contains signatures, certificates, keys, or hashes associated with software that should no longer be trusted. This can include vulnerable bootloaders and compromised components.
For example, if a previously trusted bootloader is later found to contain a serious security vulnerability, its hash or signature can be added to dbx so that Secure Boot will block it.
In simple terms: PK controls the Secure Boot authority. KEK authorizes database updates. DB identifies trusted components. DBX identifies components that must be blocked.
Microsoft's Secure Boot documentation describes the same hierarchy: the PK sits at the top, followed by KEKs, while db and dbx define which pre-boot code is trusted or revoked.
Microsoft is one of the major participants in the Secure Boot ecosystem used by Windows PCs.
Windows-compatible devices commonly include Microsoft certificates and keys that allow the firmware to trust Windows boot components. Microsoft also operates signing infrastructure used in certain cases by third-party UEFI software.
One important example is the shim bootloader used by many Linux distributions. A Microsoft-signed shim allows compatible Linux systems to boot with Secure Boot enabled without requiring the user to replace the Microsoft keys already present in the firmware.
This means Microsoft's Secure Boot certificate infrastructure is not used only by Windows. It can also affect:
• Third-party bootloaders
• EFI applications
• Linux distributions
• Hardware Option ROMs
• Other UEFI software that needs to run before the operating system starts
This broad role is one reason the transition from the 2011 certificates to the 2023 certificates needs to be handled gradually rather than simply replacing all old certificates at once.
The original Microsoft Secure Boot certificates used on Windows devices have been in service since the Windows 8 era. Several of those certificates begin expiring in 2026.
Microsoft has published the following replacement certificates and expiration schedule:
| Expiring certificate | Expiration date | Replacement certificate | Location | Primary purpose |
| Microsoft Corporation KEK CA 2011 | June 24, 2026 | Microsoft Corporation KEK 2K CA 2023 | KEK | Authorizes updates to DB and DBX |
| Microsoft UEFI CA 2011 | June 27, 2026 | Microsoft UEFI CA 2023 | DB | Signs third-party bootloaders and EFI applications |
| Microsoft UEFI CA 2011 | June 27, 2026 | Microsoft Option ROM UEFI CA 2023 | DB | Signs third-party Option ROMs |
| Microsoft Windows Production PCA 2011 | October 19, 2026 | Windows UEFI CA 2023 | DB | Signs the Windows bootloader |
Microsoft has confirmed these expiration dates and replacement certificates as part of its Secure Boot certificate update guidance.
Why Is Microsoft UEFI CA 2011 Being Replaced by Two Certificates? This is one of the more interesting changes in the new certificate structure.
The older Microsoft UEFI CA 2011 covered multiple types of pre-boot software. During the transition, Microsoft separated those functions into two certificates:
• Microsoft UEFI CA 2023 for third-party bootloaders and EFI applications
• Microsoft Option ROM UEFI CA 2023 for third-party Option ROMs
The separation gives OEMs and platform owners more control over the trust policy.
For example, a system that needs to trust hardware Option ROMs does not necessarily need to trust the same set of third-party bootloaders. By separating these functions, the Secure Boot configuration can be more granular.
This is probably the question most Windows users want answered. The short version is: your PC can still work normally, but it may not be able to receive future Secure Boot protections.
Microsoft states that devices that have not received the replacement 2023 certificates can continue to start and operate normally. Standard Windows updates can also continue to install.
However, those devices may no longer be able to receive new security protections for the early boot process. According to Microsoft's guidance, this can include protections and updates related to:
• Windows Boot Manager
• Secure Boot databases
• Secure Boot revocation lists
• Mitigations for newly discovered boot-level vulnerabilities
In other words, the immediate problem is not that Windows suddenly stops booting. The bigger concern is that the device may gradually fall behind in an area of security that operates before Windows itself starts.
What About Existing 2011-Signed Bootloaders?
The expiration of a certificate does not automatically mean that every component signed by that certificate suddenly becomes unusable.
Microsoft's current guidance for the Linux Secure Boot transition specifically notes that an existing bootloader signed with the older 2011 certificate can continue to boot if the certificate is still trusted by the system and the component has not been revoked. What changes is the ability to move forward with new boot components and security fixes that depend on the newer certificate infrastructure.
This is why the transition is gradual.
There are two main reasons: certificate lifecycle management and the need to strengthen protection against modern boot-level attacks.
The Microsoft certificates originally deployed with Secure Boot have been in use for more than a decade.
Several of them now reach their expiration dates in 2026. Replacing them is necessary to maintain a trust infrastructure that can continue to support Windows boot components and Secure Boot database updates.
For example, Microsoft's Secure Boot guidance for Windows 11 version 25H2 and later specifies a configuration using Microsoft Corporation KEK 2K CA 2023 and Windows UEFI CA 2023. Microsoft also provides an alternative configuration for systems that need Linux, third-party UEFI applications, or Option ROM support.
The Secure Boot transition also takes place against a changing security landscape.
BlackLotus, associated with CVE-2023-24932, demonstrated the danger of attacks that abuse vulnerable but legitimately signed boot components. Such attacks can operate before Windows fully starts, making them particularly difficult to detect and remove.
Microsoft's response to this class of threat involves more than simply replacing one certificate with another. It includes:
• Updating boot components
• Maintaining Secure Boot revocation data
• Blocking vulnerable boot software
• Moving toward newer certificate authorities for future signing
The 2023 certificate transition is therefore part of a broader effort to keep the Windows boot environment serviceable and secure.
There are several ways to check the Secure Boot configuration. The easiest method depends on how comfortable you are working with firmware settings and command-line tools.
For most users, the simplest option is to view the Secure Boot certificate databases directly.
DiskGenius can display the Secure Boot certificates stored in the UEFI firmware without requiring you to manually parse firmware variables.
1. Open DiskGenius Free Edition. Click "Tools" and Select "Set UEFI BIOS Boot Entries".
2. Click "View Secure Boot Certificates".
3. Select "Signature Database (db)" from the certificate database list. The window displays certificates currently stored in the selected Secure Boot database.
Depending on your PC, you may see older certificates such as:
• Microsoft Windows Production PCA 2011
• Microsoft UEFI CA 2011
You may also see newer certificates such as:
• Windows UEFI CA 2023
• Microsoft UEFI CA 2023
• Microsoft Option ROM UEFI CA 2023
You can double-click a certificate to view a system pop-up that shows additional information, such as the issuer and validity period.
Because different systems have different Secure Boot configurations, do not assume that every PC must contain exactly the same combination of certificates. Some systems need additional certificates for Linux compatibility, third-party UEFI applications, or Option ROM support.
Windows includes PowerShell cmdlets for reading Secure Boot variables.
1. Check whether Secure Boot is enabled: Confirm-SecureBootUEFI
If Secure Boot is enabled, the command should return: True
2. Check if the db contains the Windows UEFI CA 2023 certificate:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
Note: If the output returns True, it means the certificate is already included in the db.
3. Check if the db contains the Microsoft UEFI CA 2023 certificate:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft UEFI CA 2023'
These commands are useful for confirming that the variables are present, but the returned certificate data is stored in binary EFI signature structures and is not especially easy to read directly.
For that reason, converting the raw bytes to ASCII and searching for certificate names is not a reliable way to determine exactly which certificates are installed. If you need to inspect the certificate names visually, a graphical tool that can parse the Secure Boot databases is usually more convenient.
Some computers allow you to inspect Secure Boot keys directly from the firmware setup screen.
The exact steps vary by manufacturer, but the general process is:
1. Restart the PC and enter the UEFI/BIOS setup.
2. Open the Security or Boot section.
3. Find the Secure Boot settings.
4. Look for options such as Key Management, Secure Boot Keys, or Certificate Management.
Many consumer PCs only provide an option to enable or disable Secure Boot and do not show the actual certificate contents. If that is the case, checking the database from Windows may be easier.
If your PC does not appear to have the replacement certificates, start with the least invasive option.
Microsoft manages the deployment of the new Secure Boot certificates for a significant portion of Windows devices.
1. Open: Settings → Windows Update.
2. Click Check for updates.
3. Install all available updates.
4. Restart the PC when prompted.
5. Check the Secure Boot certificate databases again.
Certificate deployment can depend on the Windows version, firmware, device configuration, and whether the OEM has provided the necessary update packages.
Installing the latest Windows updates does not necessarily mean that every PC will immediately receive every 2023 certificate. The transition is staged, and different devices may follow different update paths. Microsoft also provides separate guidance for organizations and OEMs that manage their own Secure Boot updates.
Some devices require an OEM firmware update.
Check your PC or motherboard manufacturer's support page for a newer BIOS or UEFI version. Firmware updates may include changes required for the Secure Boot certificate transition.
Before updating:
• Make sure you are downloading firmware for the exact PC or motherboard model.
• Read the manufacturer's instructions carefully.
• Keep the computer connected to a stable power source. >
• Do not interrupt the update process.
For laptops, it is generally a good idea to connect the AC adapter before starting the update.
After installing Windows updates or a firmware update, check the Secure Boot databases again.
If you are using DiskGenius Free Edition:
1. Open Tools → Set UEFI BIOS Boot Entries.
2. Click View Secure Boot Certificates.
3. Select KEK and Signature Database (db) in turn.
4. Check for the applicable 2023 certificates.
For a typical updated Windows configuration, the certificates you may expect to see include:
• Microsoft Corporation KEK 2K CA 2023 in KEK
• Windows UEFI CA 2023 in db
Depending on the device and its compatibility requirements, db may also contain:
• Microsoft UEFI CA 2023
• Microsoft Option ROM UEFI CA 2023 /p>
• Older Microsoft certificates retained for compatibility
For example, Microsoft's Windows 11 25H2 Secure Boot guidance allows additional 2023 and legacy certificates on systems that need to support Linux, third-party UEFI applications, or Option ROMs.
So the presence of both 2011 and 2023 certificates is not necessarily a problem.
Some older devices may not receive a firmware update from their manufacturer, or they may not be supported by the same certificate deployment path as newer hardware.
If that happens:
• Keep Windows updated.
• Keep Secure Boot enabled if your system supports it.
• Do not manually delete existing Secure Boot certificates.
• Check the PC manufacturer's support page periodically.
• Follow Microsoft's guidance for your specific Windows and hardware configuration.
A device that has not yet received the 2023 certificates is not necessarily unusable. The important distinction is that Microsoft has warned that such devices may be unable to receive future early-boot security protections after the older certificates expire.
If BitLocker or Windows Device Encryption is enabled, make sure your recovery key is available before updating:
• BIOS or UEFI firmware
• Secure Boot settings
• Boot configuration
• Other firmware security settings
Changes to the boot environment can trigger BitLocker recovery.
You can check whether your recovery key is backed up through your Microsoft account or your organization's management system, depending on how the PC is configured.
The Secure Boot certificate transition is designed to preserve compatibility while new certificates are introduced.
Some systems may still need older certificates to boot existing software or support third-party UEFI components.
Removing certificates from db or KEK without understanding the complete boot configuration can leave a PC unable to start.
The dbx database exists to block known vulnerable or compromised boot components.
Clearing dbx or manually removing revocations may make an older bootloader work again, but it can also restore trust in software that was specifically blocked for security reasons.
If a legitimate operating system or bootloader stops working after a Secure Boot update, the better solution is usually to update the affected boot component.
If your PC runs both Windows and Linux, update your Linux distribution before making major Secure Boot changes.
Pay particular attention to: shim, GRUB, bootloader updates, secure boot-related distribution updates.
Microsoft's current Linux transition guidance notes that existing bootloaders signed under the older 2011 certificate can continue to boot under certain conditions, but future bootloader updates and security fixes will require the newer 2023 signing infrastructure.
1. Do I need to update my Secure Boot certificates?
If your PC is receiving the appropriate Windows or OEM updates, the transition may happen automatically.
However, because the original Microsoft Secure Boot certificates are expiring in 2026, it is worth checking whether your device has received the relevant replacement certificates.
2. Will my PC stop working if it does not have the 2023 certificates?
Not necessarily. Microsoft states that affected devices can continue to start and operate normally, and standard Windows updates can still be installed.
The main concern is that the device may no longer be able to receive new security protections for the early boot process.
3. Is it normal to have both 2011 and 2023 certificates?
Yes. During the transition, newer certificates may be added while older certificates remain in place for compatibility. The exact certificate set can vary depending on the PC, OEM configuration, Linux support, third-party UEFI applications, and hardware that uses Option ROMs.
4. What is the difference between Windows UEFI CA 2023 and Microsoft UEFI CA 2023?
They serve different purposes. Windows UEFI CA 2023 is used for the Windows boot environment. Microsoft UEFI CA 2023 is intended for third-party bootloaders and EFI applications. Microsoft also introduced Microsoft Option ROM UEFI CA 2023 for third-party Option ROMs. Separating these roles allows the Secure Boot trust policy to be configured more precisely.
5. Will updating Secure Boot certificates affect my installed applications?
Normally, no. Secure Boot operates before Windows starts and focuses on firmware-level and pre-boot components. Ordinary applications that run after Windows has started are not directly affected by Secure Boot certificate changes.
6. Should I disable Secure Boot if I encounter a compatibility problem?
Usually, disabling Secure Boot should not be the first solution. First, identify the component that is failing signature verification and check whether an updated version is available. Disabling Secure Boot removes an important layer of protection against untrusted boot-time software.
Microsoft's Secure Boot certificate transition is not something most users need to manage manually, but it is becoming increasingly important as the original 2011 certificates reach their expiration dates in 2026.
A PC that still relies on the older certificates can usually continue to boot and run Windows normally. The more significant issue is future protection: without the replacement certificates, the device may no longer be able to receive new security updates for the Windows boot environment, Secure Boot databases, revocation lists, and newly discovered boot-level threats.
The easiest approach is to keep Windows and your firmware up to date, then check the Secure Boot databases to see which certificates are actually present.
For users who want to inspect those certificates without manually parsing UEFI variables, DiskGenius provides a direct way to view the Secure Boot certificate databases stored in the firmware and check whether the relevant 2023 certificates have been added.
DiskGenius is a one-stop solution to recover lost data, manage partitions, and back up data in Windows.
Download
Facebook
YouTube
X