Blog Post

Hardware Dev Center
4 MIN READ

Signing with the new 2023 Microsoft UEFI certificates: what submitters need to know

Pratishtha's avatar
Pratishtha
Icon for Microsoft rankMicrosoft
Sep 22, 2025

The original Microsoft UEFI certificates are expiring in 2026. This impacts Windows and Linux customers alike. Starting October 20, 2025, Hardware Developer Center (HDC) will return two signed binaries for each approved submission—one signed with the existing 2011 certificate and one with one of the new 2023 certificates, depending on the submission type. Submitters must separate Option ROM and UEFI applications into unique submissions. A submission must not contain an Option ROM and UEFI application. Submitters must ensure their installers can detect whether the 2023 certificates are present in the Secure Boot DB. This requirement applies to partners distributing UEFI applications or Option ROMs—not to enterprise IT admins deploying standard Windows updates. If present, use the 2023-signed file; if not, use the 2011-signed file. Microsoft will not issue dual signed packages given concerns around comprehensive testing and support in the ecosystem. Submitters—such as OEMs, IHVs, and ISVs—should expect to continue releasing their 2011-signed binaries alongside 2023-signed binaries for the foreseeable future.

Note: This blog is intended for Microsoft partners who submit UEFI binaries for signing—such as OEMs, IHVs, ISVs, and other device builders. If you are a Windows IT administrator or enterprise customer, please refer to Act now: Secure Boot certificates expire in June 2026.

Certificate expirations and continuity 

Microsoft Corporation UEFI CA 2011 (Expiration: June 2026) → replaced by: 

  • Microsoft UEFI CA 2023 for UEFI application submissions
  • Microsoft Option ROM UEFI CA 2023 introduced for Option ROM submissions 

Important: Expiration does not invalidate binaries already signed with the 2011 cert. Those remain trusted on devices that still have the 2011 CA in their DB. 

Why the rollout is careful 

Microsoft began introducing the new Secure Boot certificates in 2023, and while many newer devices already include them, a significant number of existing systems still need to be updated. To ensure a smooth and safe transition, Microsoft is taking a phased and measured approach to deploying these updates. Past internal testing revealed that some devices had firmware compatibility issues, which have since been resolved in collaboration with OEMs. This experience informed our decision to proceed cautiously, validating updates across diverse hardware configurations before broader deployment.

For organizations managing Windows updates, Microsoft offers different paths to receive these certificate updates—either by allowing Microsoft to manage the rollout automatically or by handling the update process independently. These options, along with detailed guidance for IT-managed environments, are outlined in the blog post Act now: Secure Boot certificates expire in June 2026.

Transition timeline: October 2025 → June 2026 

From October 20, 2025, each approved submission will return two signed files instead of the usual one: 

  • One binary signed with the existing 2011 UEFI CA
  • One binary signed with a 2023 UEFI CA:
    • UEFI application submissions: Microsoft UEFI CA 2023 
    • Option ROM submissions: Microsoft Option ROM UEFI CA 2023 

This will happen through June 2026, when the existing 2011 CA expires and signing ceases with the 2011 CA. 

Install-time detection logic 

Your installer must check the Secure Boot DB for the 2023 certs: 

  • If present → install/use the 2023-signed binary
  • If absent → install/use the 2011-signed binary 

Windows helper script (PowerShell) 

# Requires: UEFIv2 PowerShell module 
# Install-Module -Name UEFIv2 -Force 

Import-Module UEFIv2 
$db = Get-UEFISecureBootCerts db 
      
  function Test-CertPresent([string]$thumbprint) { 
      $db | Where-Object { $_.SignatureThumbprint -eq $thumbprint } | 
          ForEach-Object { return $true } 
      return $false 
  } 
      
$UEFI2023Thumb = "B5EEB4A6706048073F0ED296E7F580A790B59EAA" 
$OptionROM2023Thumb = "3FB39E2B8BD183BF9E4594E72183CA60AFCD4277" 
      
$hasUEFI2023 = Test-CertPresent $UEFI2023Thumb 
$hasOptionROM2023 = Test-CertPresent $OptionROM2023Thumb 
      
if ($hasUEFI2023 -and $hasOptionROM2023) { 
     Write-Host "Install 2023-signed binaries" 
     exit 0 
 } else { 
    Write-Host "Install 2011-signed binaries" 
    exit 1 
 } 

✅ Linux helper script (Bash) 

#!/bin/bash 
UEFI2023 = "B5EEB4A6706048073F0ED296E7F580A790B59EAA" 
OPTIONROM2023 = "3FB39E2B8BD183BF9E4594E72183CA60AFCD4277" 
      
 db=$(mokutil --list-db 2>/dev/null) 
     
 if echo "$db" | grep -q "$UEFI2023" && echo "$db" | grep -q "$OPTIONROM2023"; then 
     echo "Install 2023-signed binaries" 
     exit 0 
 else 
     echo "Install 2011-signed binaries" 
     exit 1 
 fi 

(Replace mokutil with efi-readvar if preferred.) 

✅ Windows C APIs 

The Windows win32 API, GetFirmwareEnvironmentVariableExw, can be used to retrieve the values of the Secure Boot DB database to determine which signed binary to use.  

Some devices may not trust all 3P CAs 

Some devices manufactured for specific use case configurations (e.g., Secured-Core PCs) may not trust the Option ROM CA or the other third-party CAs by default. Test your target platforms and coordinate with OEMs if your product depends on these certs. Most OEMs’ firmware has a UEFI menu option to switch Secure Boot configurations.

Quick reference: certificate names and SHA-1 thumbprints 

Certificate 

Subject String 

SHA-1 Thumbprint 

UEFI CA (2011) 

Microsoft Corporation UEFI CA 2011 

46DEF63B5CE61CF8BA0DE2E6639C1019D0ED14F3 

UEFI CA (2023) 

Microsoft UEFI CA 2023 

B5EEB4A6706048073F0ED296E7F580A790B59EAA 

Option ROM CA 2023 

Microsoft Option ROM UEFI CA 2023 

3FB39E2B8BD183BF9E4594E72183CA60AFCD4277 

Coming soon: changes to signing requirements 

Beginning in October 2025, Microsoft partners submitting binaries for signing with the third-party UEFI CA must undergo an annual security audit conducted by a Microsoft-approved independent partner specializing in security code reviews. For SHIM submissions, the SHIM Review Board process is sufficiently rigorous and meets this requirement. However, when the Review Board flags risks they can't cover, such as proprietary, non-SHIM code that is included with the submission, then you must also complete the independent security code audit.  

Stay tuned for further announcements on this blog, including how to identify a qualifying partner to conduct the audit. 

Submitter checklist 

  • Prepare your submission process to handle two returned files (2011 and 2023 signed).
  • Update your installers to detect the 2023 certs and select the correct binary.
  • Keep shipping the 2011-signed binary along with the 2023-signed binary until most devices have updated their UEFI trust anchors – Microsoft will provide an update when this happens. 
  • If you try dual-signing, test comprehensively across your target fleet.
  • Engineer for crypto agility (avoid hard-coded assumptions about key sizes or algorithms). 

 FAQs 

Q: Will my existing 2011-signed binary stop working when the cert expires? 
A: No. Existing signatures remain valid on devices that still trust the CA in DB. 

Q: What about Post-Quantum Cryptography (PQC)? 
A:Microsoft and the UEFI Forum are working together to ensure the ecosystem is ready. Guidance will be published in stages—focus now on crypto agility and update mechanisms. Microsoft’s PQC roadmap is published here: Microsoft Quantum | Quantum Roadmap 

Additional information  

  1. Secure Boot CA update website: Windows Secure Boot certificate expiration and CA updates - Microsoft Support
  2. Article for OEMs and ODMs: Windows Secure Boot Key Creation and Management Guidance - Microsoft Support
  3. Blog post announcement: Act now: Secure Boot certificates expire in June 2026 - Windows IT Pro Blog 
Updated Sep 24, 2025
Version 3.0

3 Comments

  • Keep shipping the 2011-signed binary along with the 2023-signed binary until most devices have updated their UEFI trust anchors – Microsoft will provide an update when this happens.

    Dear Pratishtha has Microsoft given any guidance to OEMs and more generally mainboard vendors (Asrock, Asus, MSI, Gigabyte etc.), when and how to update their UEFI firmware, so that customers will have trust that the certificate DB will see these updates required on the firmware level?

    I am still seeing a lot of Mainboard vendors that do not offer firmware updates through Windows Update, let alone Autopatch. Especially for custom built and consumer devices. 

    Could you share some insights on the firmware upgrade process and how it relates to this change in terms of timelines? 

    Thank you! 

     

     

     

    • Jordan_Geurten's avatar
      Jordan_Geurten
      Icon for Microsoft rankMicrosoft

      Hi Karl-WE​, we have given explicit guidance to partners that they should not ship DB updates via UEFI updates. This action causes PCR7 mismatches leading to possible BitLocker and VSM recoveries which is a bad experience for Windows users. The goal is to have the OS (Windows, Linux, others) update the DB.