Guidance for the Microsoft 2023 Secure Boot CA Transition (original) (raw)

Installing the Microsoft 2023 Secure Boot CA and KEK Updates

Audience: Distro Maintainers

This document is intended for distributions that support UEFI
Secure Boot using Microsoft UEFI CA-signed boot components. End users
of such distributions should generally expect their distribution vendor
to manage these updates, but may reference this document when
discussing Secure Boot update behavior or compatibility concerns with
their support channels.

Overview

Systems with UEFI Secure Boot enabled and enrolled are expected to
receive these updates as authenticated runtime variable (authvar)
updates from the operating system.

A firmware update should not retroactively change the enrolled trust
state of an already deployed UEFI Secure Boot system. Once Platform
Key (PK), KEK, and signature databases (db, dbx) are enrolled, the
firmware enforces authenticated variable semantics. From that point
onward, updates to those databases must be signed appropriately and
delivered as runtime Secure Boot variable updates.

For Linux distributions, this means the Microsoft 2023 Secure Boot CA
transition must be handled by the OS, not via firmware / BIOS updates.

The canonical update artifacts are published at:

Distributions should strongly consider integrating these updates into
their Secure Boot maintenance and lifecycle tooling.

Why These Updates Are Required

Microsoft will be unable to sign any artifacts with the 2011
third-party CA once it expires. Existing artifacts signed with the
2011 CA will continue to boot on systems that trust the 2011
CA. However if there is a need for a revocation of such an artifact
after the June 2026 deadline, it will only be possible to sign a
replacement artifact with one of the 2023 CAs.

Systems that do not install the new certificates may eventually fail
to boot newer signed components, including:

The update consists of several independent trust anchors.

db Updates

The Secure Boot db variable contains certificates and hashes trusted
for execution. The secureboot_objects repository publishes several
distinct db update payloads:

Windows Production CA Update

This updates the trust used for Microsoft Windows boot components.

Certificate name: Windows UEFI CA 2023

This is required for future Windows bootloader compatibility.

Third Party UEFI CA Update

This is the most important update for Linux distributions.

Certificate name: Microsoft UEFI CA 2023

This CA signs:

Distributions should ensure that systems trust the required Microsoft
2023 Secure Boot CAs before deploying components signed only by the
2023 trust chain. Failure to do so may render systems unable to boot
under Secure Boot.

Option ROM CA Update

Certificate name: Microsoft Option ROM UEFI CA 2023

This signs:

Without this update, future Option ROMs will fail Secure Boot
validation, preventing dependent devices from functioning during boot.
While most commonly associated with plug-in cards, integrated platform
components may also deliver firmware through Option ROMs.

Firmware update systems should verify that a platform trusts the
required Microsoft 2023 Option ROM Secure Boot CAs before deploying
Option ROM firmware signed only by the 2023 Option ROM CA. Failure to
do so may prevent affected devices from functioning during boot.

On systems where the Option ROM provides the only available graphics
console, failure to validate the Option ROM may leave the system
without functional display output during boot, making recovery or
troubleshooting difficult. Such systems may still be recoverable by
temporarily installing a graphics adapter whose Option ROM is signed
by the 2011 UEFI CA.

KEK Update

Certificate name: Microsoft Corporation KEK 2K CA 2023

The KEK (Key Exchange Key) database authorizes updates to Secure Boot
variables.

The KEK update is necessary so that future Microsoft-signed Secure
Boot database updates can themselves be authenticated and installed.

Without the updated KEK, systems may fail to accept future
authenticated db or dbx updates.

The correct KEK update depends on the currently enrolled Platform Key
(PK) vendor chain.

Once the Microsoft Corporation KEK CA 2011 expires on June 24, 2026,
it can no longer be used to sign authenticated db or dbx
updates. As a result, systems that do not trust the 2023 KEK may be
unable to receive future dbx revocations for vulnerable artifacts
signed by either the 2011 or 2023 UEFI CAs.

Which CAs to apply

Since the 2011 UEFI CA functionality has been split into separate
third-party and option ROM CAs in the 2023 hierarchy, any OS extending
trust from the 2011 CA should install both corresponding 2023
certificates to preserve equivalent Secure Boot behavior and
compatibility.

Non-Windows systems that already trust the Microsoft Windows Production
PCA 2011 should generally also install and trust the corresponding Windows
UEFI CA 2023, although this is not strictly required unless compatibility
with future Windows releases under Secure Boot must be preserved.

The 2023 KEK should generally always be installed when possible, even
for systems that remain on the 2011 CAs.

Verifying 2023 CA Enrollment

Distributions must verify that the Microsoft 2023 Third Party UEFI CA
is enrolled in an automated pre-installation step before installing
boot components signed only by that CA. Installations or updates of
2023-only signed components should fail without updating the affected
components if the required CA is not present. Failure to do so will
render systems unable to boot under Secure Boot.

The Microsoft 2011 UEFI CA is expected to remain trusted for the near
term, and distributions are not required to proactively enroll the 2023
Third Party UEFI CA until a system requires it. Enrollment may reasonably
be deferred until immediately before installing or updating components
signed only by the 2023 trust chain.

TPM Measurement Considerations

Secure Boot database updates, including updates to PK, KEK, db, or
dbx, will generally change TPM PCR 7 measurements. Systems using
TPM-bound disk unlock, measured boot attestation, or other PCR 7
dependent policies may require resealing or policy updates after these
updates are applied.

Dual-Signed Shim Considerations

Microsoft is currently returning shim binaries signed by both the 2011
and 2023 UEFI CAs. It is also possible to create a dual-signed shim by
extracting the secondary signature and applying it to another shim
binary.

This configuration is not widely exercised across the full range of
firmware implementations and Secure Boot validation behaviors. Due to
the large variety of deployed firmware implementations, distributions should
exercise caution before relying on dual-signed shims as a compatibility
strategy.

When constructing a dual-signed shim, the signature using the 2011 UEFI
CA should be applied first to maximize compatibility with existing
firmware implementations.

Strong Recommendation: Integrate fwupd

Distributions that have not yet adopted fwupd should strongly
consider doing so:

Advantages include:

Distributions may either:

Even distributions that do not wish to use LVFS should consider
shipping fwupd configured for local or offline metadata sources.

Manual Verification and Installation

The following sections provide commands suitable for:

Checking Installed Certificates

Using mokutil

mokutil is generally the easiest inspection tool.

Note that newly installed updates will not appear until after reboot.

List enrolled db certificates:

Look for entries such as:

Microsoft UEFI CA 2023
Microsoft Windows Production PCA 2023
Microsoft Option ROM UEFI CA 2023

List KEKs:

List Platform Keys:

Installing db Updates

The Microsoft repository provides authenticated update payloads.

Installing db Updates Using efivar

sudo efivar
--name d719b2cb-3d3a-4596-a3bc-dad00e67656f-db
--append
--datafile DBUpdate3P2023.bin
--attributes 0x67

Where:

This appends the authenticated update payload to the existing Secure Boot db
without replacing currently enrolled certificates.

After applying the update:

reboot the system and verify enrollment using:

Determining Which KEK Update Is Required

The correct KEK update depends on the currently enrolled Platform Key
chain. The KEK update payload must be signed by a key already
authorized by the current PK/KEK chain.

The PK can be inspected by:

In practice this means distributions or administrators must:

  1. identify the currently trusted PK
  2. assemble the signed KEK update from the secureboot_objects repo
  3. apply the KEK update before future db updates depend on it

Here is an example shell script that does this:

create-kek-update-from-secureboot-objects.sh

The resulting authvar update can then be applied the same way as the
db update shown above.

The safest rollout order is:

  1. install updated db entries
  2. reboot
  3. verify updated certificates
  4. if available install updated KEK
    - reboot
    - verify KEK enrollment

Installing the updated db certificates is the most time-sensitive
requirement for continued deployment of new Secure Boot components. The
KEK update remains important for future revocation support and
authenticated Secure Boot updates. Failure to install the KEK update
should result in an auditable event visible to administrators,
management systems, or compliance tools, particularly after the June 2026
deadline.

Handling Update Failures

Tools such as fwupd implement additional compatibility handling,
reboot sequencing and validation logic for systems that require special
handling during Secure Boot updates.

If repeated attempts to install the 2023 CA or KEK updates fail,
distributions should avoid deploying components that depend on the new
trust chain until the issue is resolved. Systems that cannot
successfully enroll the required updates may need to remain on
components signed by the older trust chain, and may ultimately require
firmware updates or platform replacement in order to support future
UEFI CA Secure Boot updates.

Distribution Recommendations

Distributions should ideally:

Revocation of the 2011 CAs

Due to the behavior of current UEFI implementations, revocation of the
Microsoft Corporation UEFI CA 2011 through dbx is not generally a
practical mechanism for selectively blocking older trust chains.
Organizations wishing to fully eliminate trust in the 2011 UEFI CA
should consider removing the certificate from db entirely rather than
relying on dbx revocation behavior.

The Microsoft Corporation UEFI CA 2011 is unlikely to be broadly
revoked in the foreseeable future due to the large number of deployed
systems and Option ROMs that continue to depend on it for Secure Boot
compatibility.

In the majority of current UEFI implementations, a dbx update that
revokes the Microsoft Corporation UEFI CA 2011 will also revoke
dual-signed artifacts that contain both a signature from that CA and a
signature from another otherwise trusted CA, preventing such artifacts
from booting under Secure Boot.

Organizations considering revocation of the Microsoft Corporation UEFI
CA 2011 using their own KEK must carefully evaluate the impact on older
OS distributions, third-party EFI applications and utilities, and
Option ROMs that continue to depend on the 2011 trust chain. Systems
that cannot boot or be serviced without such components may require
significant recovery procedures. This approach is strongly discouraged.

New platforms that are not qualified for compatibility with older
operating systems, legacy Option ROMs, or older plug-in cards may
elect to omit pre-installation of the 2011 UEFI CAs entirely. OS
distributions should ensure that they can support such systems with the
required installation media and installer changes needed to deploy
2023-signed artifacts.

The Microsoft Windows Production PCA 2011 has been revoked by
DBXUpdate2024.bin, published in https://github.com/microsoft/secureboot_objects

Non UEFI CA distributions

If you are a Windows customer and somehow ended up here, you may be
looking for this:

https://support.microsoft.com/en-us/topic/registry-key-updates-for-secure-boot-windows-devices-with-it-managed-updates-a7be69c9-4634-42e1-9ca1-df06f43f360d