Microsoft UEFI CA 2023 transition, how was it for you?

[thesandwichman]

First of all just to say thanks very much to the admins for allowing back to Edugeek. For many years I was blackballed (presumably for upsetting someone) so it's lovely to be back here again.

 

The transition to the Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023 certificates requires Windows to update UEFI Secure Boot variables stored in the motherboard's NVRAM. Some older or buggy firmware implementations do not correctly support these runtime updates, causing the certificate update to fail until the BIOS/UEFI firmware is updated. Despite diligently searching for and installing the latest UEFI BIOS  firmware (mostly Lenovo) this has been a considerable nuisance.

 

I have been using this detect script on InTune to find the problems. If anyone can suggest improvements would be interested to know

 

 

$RegPath = "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing"
$ValueName = "UEFICA2023Status"

# Helper function
function Write-Result {
    param(
        [string]$Assessment,
        [string]$Reason
    )

    Write-Output "Assessment : $Assessment"
    Write-Output "Reason     : $Reason"

    try {
        $bios = Get-CimInstance Win32_BIOS
        Write-Output "BIOS        : $($bios.SMBIOSBIOSVersion)"
    }
    catch {}

    exit $(if ($Assessment -eq "Compliant") {0} else {1})
}

# Secure Boot enabled?
try {
    if (-not (Confirm-SecureBootUEFI)) {
        Write-Result "Not Compliant" "Secure Boot is disabled."
    }

    Write-Output "Secure Boot : Enabled"
}
catch {
    Write-Result "Not Compliant" "Unable to determine Secure Boot status."
}

# Read servicing status
try {
    $status = (Get-ItemProperty -Path $RegPath -Name $ValueName -ErrorAction Stop).$ValueName
}
catch {
    Write-Result "Not Compliant" "UEFICA2023Status registry value not found."
}

Write-Output "UEFICA2023Status : $status"

switch ($status) {

    "Updated" {
        Write-Result "Compliant" "UEFI CA 2023 servicing completed."
    }

    "InProgress" {
        Write-Result "Not Compliant" "UEFI CA 2023 servicing is still in progress."
    }

    "NotStarted" {
        Write-Result "Not Compliant" "UEFI CA 2023 servicing has not started."
    }

    default {
        Write-Result "Not Compliant" "Unexpected servicing state: $status"
    }
}
 

 

[itskdog]

I've been using the official Microsoft detection script: Monitoring Secure Boot certificate status with Microsoft Intune remediations | Microsoft Support

 

Gives a JSON response with the full status of the device - can be found on your C:\ drive under %systemroot%\SecureBoot\ExampleRolloutScripts (when run locally, also gives a user-friendly version before the JSON output)

 

There's also the Secure Boot Status report in Intune https://intune.microsoft.com/?ref=AdminCenter#view/Microsoft_EMM_ModernWorkplace/SecureBootReport.ReactView

 

Just need to do a manual install on some of our older HP machines using a script they've provided for devices that aren't getting the BIOS update, which I'll go around with a USB installing that over the summer.

[psydii]

Its gone (going?) pretty well for us. Much like covid lockdown forced the migration from file shares to SharePoint/Teams,  this pushed us to move to co-management  for updates. Everything that has been switched on in the last two months is now updated, almost entirely automatically with no scripts needed. Just got a handful of devices out with long term absences that might be a problem, but they are all due to be retired (the computers not the people)  as soon as they get back.  We pushed the update now key/value into the registry for a lot of devices, becuase the first deadline was looming and we were barely at 10%  But after June patch Tuesday things accelerated and almost everything is now done. 

 

Most of our problems were things that surfaced as part of the migration to co-managemnt: windows update health, stale/broken group  policy cache, or damaged windows installs. dsim sfc and deleting system32\grouppolicy and system32\groupolicyusers fixed almost everything. *VERY* occasionally we'd also need to delete softwaredistribution.

 

That said we do have some older covid era / dfe-class devices that will never update because their last firmware release was three years ago.

 

A couple of devices came back from repair yesterday, and they migrated to co-management and then spent the afternoon rebooting (automatically?!) until they appeared (as per the report this morning) to complete the certificate update process. So anecdotally, a machine that is behind on that updates right  now, will install update and reboot until it  has updated its secure boot certs and boot chain completely. Maybe they had pre-staged things, or maybe the June deadline wasn't the deadline that some made it out to be.  But either way, we're in a much better place because of it. (92% for comanaged, and 75% for Intune etc.- with 20% of the 'missing' devices being accounted for due to network isolation during the exam period(s))

 

[psydii]

Windows Secure Boot certificate expiration

Important

Secure Boot certificates used by most Windows devices were set to expire starting in June 2026. Microsoft has been updating these certificates on PCs and non-managed business devices for the past months. Devices that haven’t received the newer certificates will continue to start, and standard Windows updates will continue to install. We will continue to install the newer certificates via Windows updates in the coming months.

 

So officially, machines not yet up to date remain updatable for now.

[DavR]

We updated all of our devices that would take the certificate updates, but it has to be said a lot of our desktops didn't receive the necessary BIOS / firmware updates due to their age, so a lot of our devices will just never get these.

 

We'll soon be about to embark on the summer round of rebuilding workstations, so will be interesting to see if anything tries to stop us due to expired certificates. My test VM with the new certs in place works OK so far, and I've not had to update the boot images or anything, so fingers crossed.

[itskdog]

2 hours ago, DavR said:

We updated all of our devices that would take the certificate updates, but it has to be said a lot of our desktops didn't receive the necessary BIOS / firmware updates due to their age, so a lot of our devices will just never get these.

 

We'll soon be about to embark on the summer round of rebuilding workstations, so will be interesting to see if anything tries to stop us due to expired certificates. My test VM with the new certs in place works OK so far, and I've not had to update the boot images or anything, so fingers crossed.

 

As long as the image and boot media are on the 2011 boot loader, you should be fine, even on machines that are no longer supported by the OEM.

 

They'll then pick up the policies from before and update to 2023 again.

[DavR]

2 hours ago, itskdog said:

 

As long as the image and boot media are on the 2011 boot loader, you should be fine, even on machines that are no longer supported by the OEM.

 

They'll then pick up the policies from before and update to 2023 again.

 

Yes, so it would appear. I spun up a test VM with our new 25H2 build, and that seemed to be compliant straight out of the box.

 

Having investigated some of our other devices, which I didn't roll out the update policies to (I thought there'd be no point, given they weren't OEM supported for the cert update), I can see that these have also been miraculously updated (active db only, not dbdefault) by I assume June 2026 CU. 

 

Edge cases such as OP and their buggy firmware aside, as long as you've got June 2026 CU it seems you're likely to be compliant. Makes me wonder why I spent so long setting up the group policy deployment for, really 😂

[FN-GM]

For us, it was smooth. All machines auto update their BIOS so no work required. We turned on the InTune policy and let it roll out. 

 

We found around 5 machines wanted their bitlocker key for some reaosn.

[itskdog]

2 hours ago, FN-GM said:

For us, it was smooth. All machines auto update their BIOS so no work required. We turned on the InTune policy and let it roll out. 

 

We found around 5 machines wanted their bitlocker key for some reaosn.

 

If they were laptops, it was likely that they were plugged in when Windows Update installed it as a driver update, but when it came time to reboot (during which BitLocker gets paused to avoid triggering a recovery scenario due to the update), they were on battery, so the UEFI didn't install the update and held it off until the next time it was booted while plugged in to the wall (by which time BitLocker had unpaused)

[thesandwichman]

I suspect the ease (or otherwise) of this transition is heavily dependent on the hardware manufacturer and firmware quality rather than the Windows side of things.

We're an almost exclusively Lenovo estate and our experience has been much more mixed than some of the "turn on the Intune policy and forget about it" reports above. The Windows updates themselves have generally behaved as expected, but we've found BIOS/UEFI support to be quite patchy across different Lenovo generations and models.

 

On some devices the Secure Boot certificate updates went through automatically with no intervention. On others, even with the latest available BIOS installed, the certificates either refused to update or remained stuck in an incomplete state. In quite a few cases the limiting factor wasn't Windows, Intune or policy configuration - it was simply that the firmware wasn't correctly handling the Secure Boot variable updates.

 

Looking at the new Intune Secure Boot Status report and Microsoft's detection scripts, most of our remaining non-compliant devices correlate strongly with specific Lenovo models rather than any particular Windows build or management method.

 

Reading through the replies here, it sounds like HP and some other vendors may have had a smoother path, whereas older Lenovo hardware seems to be a bit more hit-and-miss. I'd be interested to know whether others are seeing the same pattern, or whether we've just been unlucky with our device mix.

 

The good news is that Microsoft now appears to be continuing to deploy the new certificates through Windows Update, so the situation feels much less urgent than it did a few months ago. We've gone from worrying about a hard deadline to mostly monitoring the stragglers and identifying the handful of devices that are genuinely limited by firmware support.

[DavR]

13 hours ago, DavR said:

Having investigated some of our other devices, which I didn't roll out the update policies to (I thought there'd be no point, given they weren't OEM supported for the cert update), I can see that these have also been miraculously updated (active db only, not dbdefault) by I assume June 2026 CU. 

 

Edge cases such as OP and their buggy firmware aside, as long as you've got June 2026 CU it seems you're likely to be compliant. Makes me wonder why I spent so long setting up the group policy deployment for, really 😂

 

Update - actually no, I tested, and June 2026 CU doesn't deploy the certs, although I understand it does up the "confidence" level to put the updates through the Windows Update channel. Still not quite sure how those devices I didn't roll out the update setting to, using our WSUS not public updates, have picked up the certs, but they have.

 

I've found the whole thing incredibly confusing to be honest. So many different routes to update the certs, so much conflicting information, different variations on what updates are possible, and what updates are strictly necessary to keep Windows going and protected. I think I'm on top of it now, but that may change again in the next few days 😂

 

I still can't find a clear answer to the question, for instance, is it OK to have your active Secure Boot db running the new certs, when the firmware defaults in dbdefault are not updated. Surely this risks losing access to Windows if the BIOS gets reset to default for whatever reason, eg, a faulty CMOS battery. But Windows update seems to think it's OK to do....

[psydii]

Yes, having it mismatched is a risk if you need to reset boot keys to factory defaults. But when did anyone ever have to do that? (…ok yeah I have, once, and only because I was playing around as part of my research for this project and badly broke a machine). Resetting the bios or a faulty cmos battery will (should) not reset the boot keys.

 

For what it’s worth HP had many problems(they have in articles about getting out of the mess, and articles on how to avoid it), Lenovo’s were relatively few and far between (a handful of one model would fail, behave as though bricked, but magically recover three days later, coming up fully updated). 
 

if you’ve got firmware etc updating automatically already, and devices reporting as high confidence (or you’ve tested a few of each model manually), enabling the “let Microsoft do it” reg key, or setting the “just do it regardless” key (at your own risk) should work pretty well.  Honestly most of my time was spent migrating to intune and troubleshooting all the things that can go wrong in that transition. 

[DavR]

20 minutes ago, psydii said:

Yes, having it mismatched is a risk if you need to reset boot keys to factory defaults. But when did anyone ever have to do that? (…ok yeah I have, once, and only because I was playing around as part of my research for this project and badly broke a machine). Resetting the bios or a faulty cmos battery will (should) not reset the boot keys.

 

Can I quote you on that one.....  

[psydii]

Sure.  But its not my fault if, as a result, people downweigh the risk. If you  come unstuck , the root cause lies with competency of device oem/system integrators firmware engineering team(s)*, not me.

 

 

*Assuming the the IT tech  understood the difference between "reset boot keys" and "reset bios settings", and didn't press the wrong button.

[DavR]

Well, new developments in that sphere.

 

Turns out if you enable the cert updates on a Dell Optiplex 3040, it will brick the device next time it tries to run the cert update task. Sigh. Luckily we've only got a few, but WTF. No firmware updates available of course. So I guess I won't roll out the cert changes on those, then 😂