Scenario
Secure Boot was always a long bet on the idea that the PC boot chain could be made boring, predictable, and resistant to tampering. When UEFI replaced the old BIOS model, Microsoft and the PC industry moved toward a world where firmware checks signatures before handing control to bootloaders, option ROMs, and operating system components. That model depends on certificates, and certificates depend on time.
The awkward part is that the first generation of Microsoft Secure Boot certificates has lasted nearly the entire modern Windows era. The same 2011-era authorities that helped usher in Windows 8-era hardware are still present across huge numbers of Windows 10, Windows 11, and Windows Server machines. That longevity was convenient until it became a deadline.
The first wave of expiration begins in late June 2026, with additional Secure Boot certificate expiration following in October 2026. Microsoft’s answer is a new 2023 certificate generation, distributed through Windows servicing, firmware updates, and enterprise deployment channels.
In ordinary desktop language, that means Windows Update and possibly a BIOS or UEFI firmware update. In enterprise language, it means inventory, sequencing, rollback planning, BitLocker testing, and a nervous eye on every server SKU that does anything unusual before boot.
This is not a story about PCs refusing to turn on the morning after a certificate expires. It is more subtle than that, and therefore easier to underestimate: unsupported or unrefreshed systems may continue to boot and receive normal operating system patches, while losing the ability to receive future Secure Boot protections for early boot components.
UEFI critical keys
The following UEFI keys are the ones affected by the Microsoft’s 2011 certificate expiration:
- Key Exchange Key (KEK)
The Key Exchange Key is used to update the signature database and is stored in the KEK variable. It may be used either to update the current signature databases or to sign binaries for valid execution. In most current implementations, the KEK variable may contain multiple keys which may be of type X509 or RSA2048 any of which may perform the function of the key exchange key. - The Signature Database (DB)
The signature database is used to validate signed efi binaries and loadable roms when the platform is operating in secure mode. It is stored in the db variable. The db variable may contain a mixed set of keys, signatures or hashes. In secure boot mode, the signature stored in the efi binary (or the SHA-256 hash if there is no signature) is compared against the entries in the database. The image will be executed if either
the image is unsigned and a SHA-256 hash of the image is in the database or the image is signed and the signature itself is in the database or the image is signed and the signing key is in the database (and the signature is valid).
The db variable may only be updated by an authentication descriptor signed with the key exchange key. - The vendor Signature Database (DBDEFAULT)
The vendor signature database contains a default set of keys and it’s used to create the Signature Database at the first Operating System installation time or to recover the Signature Database in case of malfunction.
It doesn’t automatically replace the Signature Database without a manual operation: usually by resetting the Signature Database to its default.
The vendor Signature Database is updated by BIOS and Firmware vendor updates.
How to check the UEFI keys status
On Windows operating systems, the UEFI keys status could be performed through powershell:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).Bytes) -match 'Microsoft Corporation KEK 2K CA 2023'([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbdefault).bytes) -match 'Windows UEFI CA 2023')([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')The three admin powershell commands will return True if the new Microsoft certificates released in 2023 are present into UEFI KEK, DBDEFAULT and DB.
On linux operating system, the UEFI keys could be verified using the command:
efi-readvarsWhat happens on not updated systems?
The expiration of the old certificates does not mean every affected Windows system becomes a brick. Microsoft’s own guidance has been clear that devices may keep starting normally. Existing signed boot components do not simply vanish from trust because the calendar has advanced.
Secure Boot is a chain of trust, not a subscription license check. Firmware uses databases of allowed and revoked signatures to decide whether pre-OS code should run. If the old trust material is still present, already-signed components can continue to work.
But the second half of that sentence is where the risk lives. A system that has not moved to the 2023 authorities may be unable to accept future updates to the Secure Boot database, the revocation database, or boot components signed under the newer chain. That leaves the machine in what Microsoft describes as a degraded security posture. For home users, “degraded” can sound abstract. For administrators, it is concrete. It means future defenses against rootkits, vulnerable boot managers, or malicious pre-OS components may not apply. The operating system can still be patched while the layer beneath it stops receiving the same quality of protection.
Worst scenario
No one knows if and when Microsoft will decide to revoke the 2011 certificates through a standard windows update patch!
If this happens, all the systems not updated with the 2023 certificate won’t boot anymore.
Alessandro Romboli
Author
