How to renew Secure Boot certificates in Windows and avoid security problems

Informatec Digital » Resources » How to renew Secure Boot certificates in Windows and avoid security problems

If you use Windows 10 or Windows 11 and have Secure Boot enabled , you are directly affected by the certificate changes that Microsoft and PC manufacturers will be making between now and June 2026. This isn't a theoretical issue: we're talking about the component that validates what can run on your machine from the moment you press the power button, and whose original certificates are about to expire.

For years we've assumed the system was protected from the moment it starts up, but now it's time to check that everything is ready for Secure Boot certificate renewal . Microsoft, OEMs (like Acer), and system administrators have already started working on it, and it's important to understand what's happening, the consequences of inaction, and the practical steps you can take whether you're a home user or managing a fleet of devices in a company.

Why Secure Boot certificates expire and what does it mean?

The UEFI-based Secure Boot mechanism relies on digital certificates stored in the firmware to determine which code is trustworthy during boot: boot loaders, firmware drivers, critical pre-operating system components, etc. This model was designed around a key hierarchy that establishes a chain of trust from the firmware to Windows.

Within this hierarchy, we find, for example, the Platform Key (PK) , which is usually from the OEM (such as Acer), the Key Exchange Keys (KEK) from Microsoft and the manufacturer, and two essential databases: the DB (permitted signatures) and the DBX (revoked signatures). The DB includes certificates and signatures considered trustworthy, while the DBX is updated with elements that must be blocked because they are insecure or have been compromised.

The first Secure Boot certificates issued jointly by Acer and Microsoft date back to 2011 and were designed with an approximate lifespan of 15 years. This means that these initial certificates will reach their expiration date in June 2026. If your computer's firmware still relies on them and hasn't been updated to the new 2023 certificates, the boot protection will become obsolete.

With expired certificates, the computer may still boot and run Windows normally, but the critical issue is that Microsoft will be unable to properly apply new mitigations to the boot environment. This includes protections against malware that loads before the system, attempts to bypass BitLocker, and other attacks against the initial chain of trust.

On older machines, or on systems that are no longer supported (such as Windows 10 installations without ESU), the risk is ending up with a boot environment that works, but whose attack surface increases because it does not receive the same security updates or can take advantage of modern DBX revocations.

Context: end of support for Windows 10, rise of Windows 11, and dependence on Secure Boot

The announcement of Windows 10's end of life prompted millions of users to upgrade to Windows 11 to avoid losing security patches. Today, the market share has clearly shifted towards Windows 11, with around 63% compared to 35% for Windows 10, largely due to that end-of-support pressure.

Although some Windows 10 installations still use special channels like LTSC or Extended Security Updates (ESU) programs , the reality is that most users will have to coexist with Windows 11 or, at the very least, with Linux distributions if they want to remain well protected. But that doesn't mean Windows 11 is impenetrable: the validity of Secure Boot certificates now comes into play very directly.

For Windows 11, Secure Boot isn't a luxury, but a requirement for installation in most supported scenarios. Microsoft insists on keeping it enabled not only for general security, but also because many mitigations rely on this chain of trust. Even in the gaming world, it's increasingly common for modern titles (like the Battlefield series and other AAA games) to require Secure Boot to be enabled in order to run.

The latest batch of security updates for Windows 11 includes the rotation of Secure Boot certificates that expire in June 2026. Many users will receive these certificates automatically through Windows Update, without having to manually search for files or packages.

For desktop or laptop computers purchased from 2024-2025 onwards, OEM manufacturers have already incorporated the UEFI CA 2023 certificates directly into their firmware, so these computers come from the factory ready, and all you have to do is keep Windows up to date and not disable Secure Boot unnecessarily.

What happens if you don't renew your Secure Boot certificates?

A very common question is whether the PC will stop booting when it reaches its expiration date. The answer, for most users, is that the computer will continue to turn on and function normally. You'll be able to open your applications, browse the internet, and use the operating system just as you do now.

The real problem is more subtle: a computer with expired Secure Boot certificates may stop receiving or correctly applying certain updates that require this new chain of trust. Some critical boot-level security improvements might not be installed, creating vulnerabilities that attackers could exploit.

Furthermore, these certificate renewals are designed to address modern vulnerabilities in the pre-operating system environment. If the certificate base is not updated, the PC can become an easier target for bootkit malware, persistent rootkits, or tools designed to bypass mechanisms like BitLocker in the very early stages of booting.

There's another scenario to consider: some applications, especially in corporate or high-security environments, may require Secure Boot to be operational and up-to-date . If internal checks detect expired certificates, they might refuse to run or have limited functionality, impacting productivity.

Therefore, Microsoft's recommendation is clear: always keep Secure Boot enabled and updated , install the latest Windows 11 updates or, in the case of Windows 10 with ESU, apply all security patches, and make sure you have the latest firmware/BIOS version available for each computer.

How to check the status of Secure Boot certificates in Windows

To find out if your machine has already adopted the new Secure Boot certificates , you can perform a quick check using PowerShell. Microsoft offers a command that inspects the contents of the Secure Boot signature database (db) and specifically looks for the presence of Windows UEFI CA 2023.

With PowerShell open with administrator privileges, you can run something equivalent to:

([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')

If the command returns True , it means the computer is already using the new 2023 UEFI certificate and is protected against the expiration of the original 2011 certificates. In that case, you don't need to worry beyond continuing to apply normal Windows and firmware updates when they become available.

Conversely, if the expression returns False , the machine still relies on certificates that expire in June 2026. In that scenario, it's advisable to first check if Secure Boot is actually enabled in the BIOS/UEFI, and then force or facilitate the arrival of the necessary updates through Windows Update or through the appropriate configuration in managed environments.

To confirm that Secure Boot is enabled, you can use the System Information tool with the command msinfo32 . In the window that opens, check the field corresponding to "Secure Boot Status": if it says "Enabled," the feature is working; if it says "Disabled" or "Not Supported," you will need to access the UEFI settings of the motherboard or laptop to enable it, provided the hardware allows it.

If, after checking msinfo32 and the PowerShell command, you still don't see the 2023 certificate, the next logical step is Windows Update . Check for pending updates, especially those classified as security or firmware updates. On many machines, simply installing these packages and restarting will automatically apply the certificate renewal.

Manual update of Secure Boot certificates on individual computers

There are cases where, despite having Secure Boot enabled and Windows Update running, the certificate database update is not applied automatically. For these situations, Microsoft describes a way to force the update signaling through the Windows Registry.

The standard procedure involves creating or modifying the AvailableUpdates value in the registry branch dedicated to Secure Boot. In PowerShell with administrator privileges, a command like the following can be used:

reg add HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f

It's important to note that when pasting this command into PowerShell, you must replace the forward slashes "/" in the registry path with standard Windows backslashes for the command to work correctly. Once this value is created or adjusted, Windows should detect that certificate updates are available and apply them after the next Windows Update cycle and restart.

Before modifying the Registry, it's advisable to ensure your system meets the basic requirements: Secure Boot enabled in the BIOS, a supported version of Windows (primarily Windows 11 or Windows 10 with ESU), and the Windows Update service running. Any incorrect changes to the Registry can cause problems, so it's a good idea to have a backup or a system restore point.

Once the process is complete and after one or more restarts, you can run the PowerShell command again that searches for “Windows UEFI CA 2023” in the Secure Boot database. If the response is True this time, the machine is now working with the renewed certificates , and future boot mitigations can be applied without issue.

Advanced monitoring: events, logging, and WMI for administrators

In enterprise environments, Microsoft recommends going far beyond manual verification with a couple of commands. To understand where each team stands regarding Secure Boot certificate updates , it's crucial to review system events and gather detailed information using PowerShell, the registry, and WMI/CIM queries.

A first step is to inspect the most recent Secure Boot events , especially identifiers 1801 and 1808. These events are documented as part of the logs associated with the Secure Boot database (db) and the revocation database (DBX) updates. Analyzing the most recent events helps determine if there are any pending updates, application errors, or success states.

Additionally, it is recommended to conduct a detailed inventory of devices across the entire organization. PowerShell scripts can be used to gather parameters such as the machine name (HostName, for example, $env:COMPUTERNAME) and the date and time of collection (Get-Date), providing a clear picture of the equipment fleet at a specific point in time.

From the Registry, there are several particularly relevant keys. One is the main Secure Boot key located at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot , where values ​​such as SecureBootEnabled, HighConfidenceOptOut, and AvailableUpdates can be evaluated. This data indicates whether Secure Boot is active, whether the device has opted into certain trust policies, and whether certificate updates are available.

On the other hand, there's the maintenance branch at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing , which contains parameters such as UEFICA2023Status, WindowsUEFICA2023Capable, and UEFICA2023Error. These values ​​indicate whether the device is capable of adopting the new UEFI CA 2023 certificates, whether it has applied them, and if any errors occurred during the process.

The device attributes section, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\DeviceAttributes , is also useful. This section stores data such as OEMManufacturerName, OEMModelSystemFamily, OEMModelNumber, FirmwareVersion, FirmwareReleaseDate, OSArchitecture, and CanAttemptUpdateAfter. This information helps cross-reference firmware compatibility with the status of Secure Boot updates.

Regarding event logs, it's advisable to collect indicators such as the LatestEventId associated with Secure Boot, the BucketID, and the trust level extracted from events 1801/1808, as well as the Event1801Count and Event1808Count counters. With this telemetry, IT teams can detect patterns, recurring errors, or devices that never successfully complete certificate updates.

Finally, additional system details are obtained using WMI/CIM queries : Windows version (Get-CimInstance Win32_OperatingSystem for OSVersion and LastBootTime), motherboard manufacturer and product (Get-CimInstance Win32_BaseBoard), computer manufacturer and model (Get-CIMInstance Win32_ComputerSystem).Manufacturer and .Model), and BIOS data (Get-CIMInstance Win32_BIOS for description and release date). All of this allows for the correlation of firmware versions, hardware, and Secure Boot status within a single inventory.

Intune-managed environments and IT-managed devices

For organizations that use Intune or other MDM solutions to manage their Windows devices, the key question is whether it's enough to simply let Windows Update do its job or if additional steps need to be taken leading up to 2026. Microsoft has indicated that, in managed environments, as long as diagnostic data is enabled at least at the "Required" level, necessary updates will be delivered automatically.

In practice, this means that if your Intune policies already allow telemetry and your update options are properly configured, you can rest easy. Even so, many administrators wonder whether they should manually create certain registry keys, such as MicrosoftUpdateManagedOptIn, or if these are configured automatically when the device meets the requirements.

Microsoft has published specific documentation indicating that the MicrosoftUpdateManagedOptIn key , located in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot, must be set to 1 on devices with IT-managed updates for automatic certificate renewal to function correctly. In some cases, this key can be configured automatically, but in others, it may be necessary to enforce it through policies.

The recommendation, therefore, is to review Intune policies related to diagnostics and updates, verify the actual status of machines using inventory scripts, and, if necessary, deploy a configuration policy that ensures MicrosoftUpdateManagedOptIn is at the appropriate value and that Servicing branches reflect compatibility with UEFI CA 2023.

It's equally important not to blindly assume that "nothing will need to be done in 2026." While Microsoft automates much of the process, every organization has its own unique characteristics: devices with outdated firmware, computers that don't connect regularly, restrictive network policies, or machines with deferred updates. A proactive validation plan prevents last-minute surprises.

Role of OEMs and BIOS/firmware updates

Computer and motherboard manufacturers, such as Acer, play a crucial role in this entire process. They control the Platform Key (PK) and some of the KEKs that reside in the firmware, as well as the BIOS/UEFI versions that determine how the Secure Boot DB and DBX databases are loaded and managed.

According to Acer, the company plans to release BIOS updates specifically for affected laptops and desktops in the first quarter of 2026. These versions include the PK, KEK, and DB updated with the 2023 certifications, so that after applying the BIOS, the computer will be aligned with the new Secure Boot chain of trust.

Other OEMs will likely follow similar strategies, so IT administrators and advanced users should pay close attention to their manufacturers' support notes . In many cases, the process will involve downloading a new BIOS from the OEM's website or receiving it via proprietary tools (such as automatic update utilities) and applying the update following standard instructions.

For computers released in 2024 or 2025, the BIOS typically comes with 2023 BIOS keys from the factory, or receives that update shortly after purchase. If you bought your PC during those years, you probably already have the updated certificates ; even so, a PowerShell check is always a good idea to confirm.

In the case of distributed infrastructures, data centers, or large laptop fleets, it may be necessary to coordinate a phased firmware deployment plan with OEMs , avoiding applying critical BIOS updates to all devices simultaneously without prior testing. This is integrated into the cryptographic and firmware lifecycle management that many companies already implement.

Cybersecurity best practices around Secure Boot

Renewing Secure Boot certificates is not an isolated event, but rather part of managing the organization's cryptographic lifecycle . Planning key and certificate rotations, auditing what is actually being used in the environment, and maintaining integrity controls in firmware and TPM reduces the likelihood of someone tampering with the system during the initial boot stages.

In this regard, it's advisable to combine boot controls with other layers of protection: disk encryption using BitLocker , detection and response systems (EDR/XDR), monitoring of firmware and configuration changes, and regular reviews of Windows security policies and hardware. All of this helps prevent a single failure in one layer from compromising the entire system.

Companies specializing in cybersecurity and penetration testing can add value by performing boot chain assessments , simulating attacks against the firmware, UEFI, and Secure Boot itself, and verifying that the defenses behave as expected. These services often also include recommendations for automating and orchestrating updates.

In organizations with highly distributed infrastructures, leveraging cloud services like Azure or AWS to set up distribution channels and centralized update management can simplify the control of patches, certificates, and firmware. Furthermore, using dashboards in Power BI and telemetry analytics helps prioritize which devices require urgent attention.

The use of artificial intelligence tools and anomaly detection focused on boot events and firmware behavior is becoming increasingly common. These systems can detect unusual patterns in Secure Boot logs, anomalous reboots, or modifications to UEFI configurations that could indicate an attempted attack or misconfiguration.

On an operational level, some basic recommendations include: periodically checking Windows Update and security statuses in the Windows Security Center, requesting official firmware from manufacturers for machines that do not update automatically, testing updates in labs before mass deployment, and maintaining up-to- date inventories and well-configured patch management systems.

Combining these practices with the proper renewal of Secure Boot certificates helps maintain a strong security posture, reducing windows of exposure and facilitating future audits, whether internal or external.

In short, the expiration of Secure Boot certificates in June 2026 makes it essential to review how our systems are configured and updated, both at home and in large organizations: ensuring that Secure Boot is active , confirming the presence of the Windows UEFI CA 2023 from PowerShell, validating registry keys and events, coordinating with OEMs to apply recent firmware, and leveraging the capabilities of Intune, WSUS, SCCM, or MDM solutions to automate deployments makes all the difference between an environment that remains protected against modern boot threats and one that, while seemingly normal, accumulates silent risks that are difficult to detect at first glance.