Secure Boot in Windows: completing the core chain-of-trust transition

Microsoft is completing the transition to new Secure Boot certificates. The final and most significant stage is the replacement of Microsoft Windows Production PCA 2011, which is used to sign the Windows boot loader. It will be replaced by the new Windows UEFI CA 2023 on October 19, 2026.

In parallel, Microsoft is strengthening its signing algorithms and moving to stronger cryptography, including RSA-3072 and SHA-384, by the end of 2026. In addition, a move to post-quantum signatures (Post-Quantum Cryptography, PQC) is planned for 2027.

How Secure Boot trust works Secure Boot verifies the signature of everything that runs in the early boot stage against keys embedded in the UEFI firmware. Its trust rests on four components stored in UEFI variables: • PK (Platform Key) — the platform owner's key; • KEK (Key Exchange Key) — the keys that authorize updates to DB and DBX; • DB (Signature Database) — the "allow list": a database of trusted certificates, keys and hashes; • DBX (Revoked Signatures Database) — the "deny list" (revocation): a database of revoked or forbidden certificates, keys and hashes. It is this combination that prevents a bootkit from loading: a malicious or revoked boot loader fails the DB/DBX check. For example, if a vulnerability is found in a boot loader, Microsoft can add its signature to the DBX "deny list"; after that, Secure Boot will block it while verifying the boot loader's signature, before Windows even starts.

Devices that do not receive the new certificates will keep booting and keep getting regular Windows updates, but over time they may stop receiving new protections for early-boot components, including DB/DBX updates and mitigations for new boot-chain vulnerabilities.

A few important nuances to keep in mind: 1. Without an updated KEK, devices may lose the ability to receive future DB and DBX updates, including revocation records for vulnerable boot loaders. 2. Secure Boot updates are historically deferred over the risk of a device failing to boot, so many devices end up in different trust states. 3. The root of boot trust is changed very rarely, so the rotation itself becomes an attack surface. During the transition, new keys are written to the DB and KEK UEFI variables, and the old and new chains coexist for a while. Old signatures stay valid until they are revoked, and mistakes in the rollout can open a window for attack. 4. Microsoft explicitly notes that an outdated chain weakens, over time, scenarios that rely on Secure Boot trust — in particular BitLocker hardening and trust in third-party boot loaders.