This guidance describes the tools and options available to help organizations update Secure Boot certificates on Windows Server before the certificates begin expiring in June 2026.
Note: This guidance does not apply to Azure Local hosts, Windows PCs or Generation 1 Hyper-V VMs. For Azure Local information, see Security updates for Azure Local. For IT-managed Windows PC information, see the Secure Boot Playbook for Windows client. Generation 1 Hyper-V VMs do not support Secure Boot.
On Windows Server, Secure Boot is a long‑standing security capability that works in conjunction with the Unified Extensible Firmware Interface (UEFI). It uses cryptographic trust anchors, referred to as certificate authorities (CAs), to confirm that firmware and boot components are trusted before they are allowed to run. This validation helps reduce the risk of malware executing early in the server startup process.
Like other cryptographic assets, Secure Boot certificates are issued with defined lifetimes. Refreshing these certificates periodically helps maintain alignment with current security requirements. For this reason, organizations will need to ensure the 2023 Secure Boot CAs are present on applicable Windows Server systems before the older 2011 CAs begin expiring in June 2026. Systems on the 2011 CAs after June 2026 are at risk of running on degraded security posture.
Windows Server 2025 certified server platforms already include the 2023 certificates in firmware. For servers that do not, IT administrators must manually update the certificates, because Windows Server does not receive them automatically. Unlike Windows PCs, which receive the 2023 Secure Boot certificates through Controlled Feature Rollout (CFR) as part of the monthly update process, Windows Server requires manual action.
Below, you can find the checklist with the recommended approach for proactively updating Secure Boot certificates on Windows Server. It outlines key preparation, deployment, and monitoring considerations to help you manage certificate updates across your device fleet.
Servers in your organization require IT administrators to validate and manually roll out the secure boot certificate updates. As the first step, we recommend conducting an inventory.
Inventory
First, verify if the servers in your organization are Secure Boot enabled. You should also check the status of the Secure Boot certificates with sample inventory PowerShell commands or by checking the value of the UEFICA2023Status registry key. Your ultimate goal for this value is to be "updated” for all applicable servers you manage.
Out of the devices that show up as not updated, build a small, representative sample to validate that the certificates update properly. We recommend that you start with servers hosting less impactful workloads. Then follow the rest of the steps outlined in this post to pilot the certificate updates and confirm that deployment is successful.
Prepare target devices
There are two options available today for managing Secure Boot certificate updates for servers. You can use registry keys or Group Policy. To plan and prepare devices for Secure Boot certificate deployment, the best practice is to start small and verify success. Then, deploy the certificates to the server instances of the same type that have been validated for the update. See Step 4 when you're ready to deploy these updates.
Important: All Secure Boot registry keys are located under these two paths:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\ServicingSee Registry key updates for Secure Boot: Windows devices with IT-managed updates for more details.
Group Policy settings are available by navigating to: Computer Configuration > Administrative Templates > Windows Components > Secure Boot. To get the updates that include the Group Policy for deploying Secure Boot certificate updates, download the latest Administrative Templates (.admx) for Windows Server.
If you have multiple servers to manage, here are the ways to keep track of the device status. If you have a mix of new and old servers in your organization, the newer servers such as those certified by Microsoft for Windows Server 2025 may not need an update. You can use registry keys or Windows Event Log events to identify which devices already have new certificates and which ones need attention.
Deployment progress
The text value of the UEFICA2023Status registry key will indicate if your certificate deployment status is not started, in progress, or updated. The value will change progressively until all new certificates and the new boot manager have been deployed successfully.
Successful deployment
- Check the Windows System Event Log events for Event ID 1808. This informational event indicates that the device has the required new Secure Boot certificates applied to the device's firmware.
- Check the UEFICA2023Error registry key for issues. This key is created only when there’s an error.
- Check that the text value of the UEFICA2023Status registry key reads as "Updated."
Errors during deployment
- Check the Windows System Event Log for Event ID 1801. This event indicates that some or all of the updated certificates and 2023 signed boot manager have not been applied to the device
- Check if the UEFICA2023Error registry key exists. If you find this key, it means there was an error in certificate deployment. Look for more details at Secure Boot DB and DBX variable update events.
The best practice is to always check and apply needed firmware updates before updating certificates. Updated firmware can help prevent compatibility problems and help ensure new Secure Boot certificates are accepted.
Microsoft is partnering with OEMs to provide platform specific information to prepare your environment before the update. Expect the list to grow as we have more partners ready to provide more information.
Note: A firmware update may be necessary if there are known issues with the firmware handling Secure Boot certificate updates. Some firmware updates also set new Secure Boot defaults to include the updated certificates.
If the firmware already handles the certificate updates correctly, a firmware update is not required. Support for firmware updates on older products is determined by the OEM.
If an OEM has ended firmware support for a specific system, firmware updates may no longer be available. For questions regarding Secure boot update support, IT administrators should consult the system manufacturer (OEM) directly.
Once you identify the servers that need to be updated, choose to do this through registry keys or Group Policy. Pilot your desired method first on a small representative set of devices to gain confidence.
In a typical enterprise deployment, Secure Boot certificates are generally applied within approximately 12 hours after the setting is applied to a device. If Windows detects that one of the updates cannot be applied without a reboot, Event 1800 is logged. In most cases, the reboot requirement is due to the Boot Manager. When a reboot is required, you can wait for the next scheduled restart or perform an unplanned reboot to complete the process. See How updates are deployed for more details. For testing scenarios, you can accelerate the experience by following the steps outlined in Device Testing Using Registry Keys.
Important: Avoid mixing deployment methods on the same device. For additional technical recommendations to help you plan and deploy your Secure Boot updates, see Deployment strategies.
Option 1: Deploy certificates with registry keys
Find the AvailableUpdates registry key located under this registry path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot.
Set its value to 0x5944 to deploy all needed certificates and update to the Windows UEFI CA 2023 signed boot manager. This key corresponds to the Group Policy setting Enable Secure Boot certificate deployment. For details, see Registry key updates for Secure Boot: Windows devices with IT-managed updates.
Option 2: Deploy certificates using Group Policy
Group Policy settings are available by navigating to:
Computer Configuration > Administrative Templates > Windows Components > Secure Boot.
To apply Secure Boot updates to devices using Group Policy, set the Enable Secure Boot certificate deployment policy to Enabled. This lets Windows automatically begin the certificate deployment process. This setting corresponds to the registry key AvailableUpdates.
Be sure to get the latest version of the .admx for Windows Server. For more details, see Group Policy Objects (GPO) method of Secure Boot for Windows devices with IT-managed updates.
Option 3: Deploy certificates via Windows Configuration System (WinCS)
New command-line tools are now available for domain-joined Windows Server instances running on Windows Server 2022. These include both a traditional executable and a PowerShell module to query and apply Secure Boot configurations locally to a device. For step-by-step guidance, see Windows Configuration System (WinCS) APIs for Secure Boot .
Deploy the Secure Boot updates via WinCS:
- Feature name: Feature_AllKeysAndBootMgrByWinCS
- WinCS key value: F33E0C8E002
- Secure Boot configuration state: Enabled
Option 4: Start a new VM using the latest version
If your Windows Server instance is running on a virtualization platform and can be migrated to the latest versions of Virtual Machines, starting new in the latest VM versions can be your best option. Reach out to your virtualization platform provider for VM versions that natively support the Secure boot 2023 certificates.
You can also use registry keys and Windows Event Log events to identify and resolve common issues:
- The UEFICA2023Error registry key doesn't exist if there are no errors. If it exists with a value other than 0, check your remediation recommendations in Secure Boot DB and DBX variable update events.
- The AvailableUpdates registry key on a device is set to 0x4104. If it doesn't clear the 0x0004 bit even after multiple restarts, the device doesn't progress past deploying the new Key Exchange Key (KEK) certificate. You will likely see an Event ID 1803 which says “A PK-signed Key Exchange Key (KEK) cannot be found for this device. Check with the device manufacturer for proper key provisioning.” If you encounter this error, check with your device manufacturer or virtual platform provider to confirm their support policy.
- If Event Viewer Windows Logs for System registers an Event ID 1795, it means that there was an error when Windows attempted to hand off the certificates to firmware. Check with your device manufacturer or platform provider to see if there is a firmware update available for the device to resolve this issue.
You can start preparing, monitoring, deploying, and troubleshooting Secure Boot certificates today, in advance of the June 2026 expiration date. To manage Secure Boot certificate updates on Windows client, see Secure Boot playbook for certificates expiring in 2026.
For the latest information, bookmark https://aka.ms/GetSecureBoot as your landing page for resources to help you with Windows Secure Boot certificate updates.
Microsoft
