Prepared for the expiration of the Secure Boot Windows UEFI 2011 CA? 

Many system administrators may not yet be aware that the Certificate Authority (CA) used to sign the Windows Secure Boot Loader and the Secure Boot databases is set to expire shortly and must be replaced with a new one. There is a lot of information circulating online about this topic, but most of it is incomplete. Therefore, we would like to take a comprehensive look at this issue from a system administrator’s perspective. 

– KEK (Key Enrollment Key): The CA stored here is used to sign updates to the Active DB and DBX. The Microsoft CA from 2011 stored here expires in June 2026. Once the CA expires, no further changes can be signed in the DB and DBX. 
– Default DB: Many OEMs update the CA contained within with the Microsoft 2023 CA. However, this Default DB is not used during boot unless you reset the BIOS to factory defaults. 
– Active DB (Secure Boot Signature Database): This is where the CA used for Secure Boot is located. The Microsoft 2011 CA for the Windows bootloader expires in October 2026, while the one for third-party bootloaders expires in June 2026.  
– DBX (Secure Boot Revoked Signature Database): Revoked certificates/bootloaders 

According to Microsoft, Secure Boot continues to function on existing Windows installations. However, changes cannot be made to the Secure Boot configuration, and the store for revoked bootloaders is no longer updated. This poses a security risk. 

For system administrators, this also means that deployment tools that use PXE boot or USB boot, for example, no longer work because the old CA has expired and the new CA is not accepted. 

In principle, it can happen automatically, but in reality, you still have to intervene. The Default DB is updated via BIOS updates, provided the manufacturer still provides BIOS updates for the model. However, the Active DB is the decisive factor. This is supposed to receive the new UEFI 2023 CA via Windows Update, but this is disabled by default. A task is configured in the Windows Task Scheduler to run every 12 hours and write the UEFI 2023 CA to the KEK and Active DB. However, it usually cannot do this because a setting in the registry blocks it. This is why error messages 1801 from TPM-WMI appear in the Windows System Log. 

According to our information, Secure Boot must be enabled for this. 

Microsoft has provided an administrative template for this in the Group Policy Templates for Windows 11 25H2 (v2). However, the names of the three existing templates for Secure Boot are misleading, so you should carefully check which one you are enabling. In most cases, you will enable “Enable Secure Boot Certificate Deployment.” 

Once applied, the background job in Task Scheduler can write the certificate to KEK and Active DB, and after two reboots, the process is complete.  

However, it is recommended to monitor the process and its status. Using two simple inventory rules in KACE or Action1, you will be able to determine whether the deployment is actually enabled and what the status of the UEFI2023CA is (NotStarted, InProgress, or Updated). 

While the group policy does allow for the CA update, it is only through the inventory rules and associated reports that you can get an overview of which devices are secure and where manual intervention is required. 

If you’re unsure whether your environment is already prepared for the upcoming Secure Boot CA expiration, or you want to avoid operational disruptions and security gaps, we’re here to help. We can support you in planning and executing the UEFI 2023 CA rollout, configuring the necessary Group Policies, and validating that the deployment is successfully applied across your endpoints. In addition, we can help you set up proper monitoring and reporting so you always have a clear overview of which devices are compliant and where manual action is still required. Get in touch with us for a consultation and make sure your infrastructure stays secure and future-ready without unnecessary risks or last-minute issues.