Secure boot certificates and older hardware

Introduction

I’m sure by now that we are all aware of the coming changes to Secure boot certificates as documented by Microsoft here. To cut a long story short, when Secure Boot was introduced by Microsoft back in 2011 or so, they secured it with some default certificates which are set to expire in June 2026.

Secure boot checks the bootloader and verifies it’s digital signature, if it’s trusted it allows it to run, otherwise it blocks it, which is a good way of blocking rootkits, bootkits and other low-level firmware attacks.

Historically speaking Secure boot became part of UEFI 2.0 specification in January 2006, but Microsoft started rolling it out in 2011 including distributing the first Secure Boot signing certificates in 2011. These were later released to mainstream computers with the release of Windows 8 in October, 2012 where Microsoft required OEMs (Original Equipment Manufacturers) to enable Secure boot and ship systems with UEFI mode enabled.

The original 2011 secure boot certificates were designed with a 15 year lifecycle, and in 2023 Microsoft introduced new 2023 certificate authorities. So here we are, all those years later, updating the bios (firmware) of modern laptops and desktops to ensure that they are capable of updating/supporting the new certificates prior to them expiring.

There are plenty of good blog posts out there today showing you how to best deal with the  Secure Boot certificate problem, but they are really focusing on supported, modern hardware, below are some examples.

What about older hardware ?

But where does that leave older hardware that does support UEFI and secure boot, and should they be turned off/disposed of ? Security experts would most likely say yes to the  latter question as they’d be wide open to rootkits/bootkits which is a painful reality when you consider the cost of new computers today thanks to the AI boom.

I’m actually writing this article on an old Lenovo T570, which technically is old, it was released in 2017, but has been updated with Windows 11 25H2, and 32GB ram. It’s not the snappiest but it works fine for what I need.

I looked at Microsoft Intune’s infamous secure boot report and it showed me lots of red x’s for my older hardware even though I was already pushing out remediation scripts in my Intune lab to deal with the Secure boot certificates expiry mess. The following were looking sad:

  • Lenovo T570
  • Dell Optiplex 9020
  • Microsoft Surface Pro 2

You can access this report in the Intune console by clicking on Reports, Windows Autopatch, Windows quality updates, Reports, and finally selecting the secure boot status report.

You can see the details of the report that I ran below, the green arrow shows my Lenovo T570 is not up to date for any of the 4 certificates listed in the report.

So I posted a tweet on Twitter (yeah, that’s what I call it) and got some instant feedback, which is the reason for this blog post. In the screenshot below you can see when the bios was last updated on my Lenovo (2024).

Fellow MVP, Mike Terrill responded with some great advice.

You should still be able to push the certs into the active db. However, the default db wouldn’t get the updated certs. If you did a factory restore of the bios, then the active ones would be replaced and need to be installed again.

And he included some Powershell examples from his talk at MMS.

I’m including his Powershell code below. All credit to Mike Terill and Gary Blok (I believe).

$SecureBootRegPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot'
New-ItemProperty -path $SecureBootRegPath -name "AvailableUpdates" -PropertyType dword -Value 0x1844 -Force
Start-ScheduledTask -taskname '\Microsoft\Windows\PI\Secure-Boot-Update'
#verify
get-securebootuefi -decoded -name DB | Where-Object {$_.Subject -match "2023"} | Select subject
get-securebootuefi -decoded -name KEK | Where-Object {$_.Subject -match "2023"} | Select subject

So basically I ran the code above on my Lenovo T570 (from an elevated prompt) and the results were interesting.

Below we add a reg key and trigger a scheduled task. The registry value tells Windows to deploy all available certificate updates as documented here and/or here (thanks Jon).

and reveal the certificate status after a reboot

To my joy, the following day the secure boot status report looked much much better for my Lenovo.

Success! thanks Mike!

I also got info from another Twitter user and he advised me to look here for some additional advice for patching older systems.

I did of course try the same method on some other old computers (Microsoft Surface Pro 2, Dell Optiplex 9020) and while it had some success with some of the certs, it couldn’t update the Microsoft Corporation KEK 2K CA 2023 certificate. According to Copilot this was because the firmware on the Dell and Surface, was just too old.

Perhaps, perhaps. But then why did my Surface Book 2, which has a firmware (bios) date of wait for it, 2015 update all of the 4 certificates without any issue. That remains to be seen. I’ll update this blog post as I learn more, I definitely don’t want to ‘trash’ some old computers just because their secure boot certificates can’t get updated, worst case scenario I’ll convert them to Linux.

On My Surface Pro 2 it updates 3 out of 4, the 4th being the missing KEK certificate, just like on the Dell.

Looking in the SYSTEM event viewer, Event ID 1803 is showing every time I trigger the scheduled task from the Powershell script.

That links me to this:

Understanding Secure Boot Events 1802 and 1803 – Microsoft Support

 

Learn more

Finally, if you want to learn more aboute this subject (better late than never) take a look at this Patch My PC webinar, or Johan Arwidmarks free training on the subject:

Summary

Windows Autopatch is not enough for getting these systems up-to-date with regards to the Secure boot certificate expiry. Thankfully, you can update some older hardware by using the example script above, after of course ensuring that the bios version is the latest available and that Windows is up-to-date. Thanks again to Mike, the beer is on me at MMS in October 🙂

 

This entry was posted in Secure Boot Status report. Bookmark the permalink.