Secure boot certificates expire in june 2026

[MYK-IT]

15 minutes ago, gaz350b said:

Just to add you can brick a device if you apply the reg key to a device that hasn’t got a compatible bios. It will boot but would lock up within 5 minutes when it tries to update the cert.

(this was on a dell 3040)

 

@gaz350b Thankfully all our desktops are all compliant, just some models of laptops that are not...

 

@itskdog  @DavR As you have both started to migrate etc, are either of you using MDT/MECM/SCCM for image (re)deployment? As interested to know if you have updated the Boot WIM images (for PXE or USB boot) etc? Especially @DavR as appears from your comments that Intune ones are, but AD devices are not.

 

Thanks,

[DavR]

23 minutes ago, gaz350b said:

Just to add you can brick a device if you apply the reg key to a device that hasn’t got a compatible bios. It will boot but would lock up within 5 minutes when it tries to update the cert.

(this was on a dell 3040)

 

Yikes, that's a worry. We've loads of 3040s and I wasn't planning on targeting the release. 

 

In my testing, I've found you just get an error message saying it can't update the certificate (Event ID 1795 and 1801) when you release the cert update to a device without compatible BIOS, I haven't seen it brick anything yet. 

 

Have you revoked the older 2011 certificates early or anything like that? 

[DavR]

17 minutes ago, MYK-IT said:

@itskdog  @DavR As you have both started to migrate etc, are either of you using MDT/MECM/SCCM for image (re)deployment? As interested to know if you have updated the Boot WIM images (for PXE or USB boot) etc?

 

We're using MDT for builds, and I haven't updated the boot images yet. Updated Default and Active DBs still have the 2011 cert in, so I'm guessing will be matching on that, as I have done test rebuilds since. I guess when the 2011 cert expires or is revoked, or we take delivery of new devices with only 2023 certs, we'll need updated boot images with the 2023 certs. 

 

I'm told that expired certificates will still work, though, to prevent devices that couldn't get the new certs from bricking. So I guess for us we'll want to keep boot images with both sets of certs in (not sure how this will be managed yet).

 

[itskdog]

50 minutes ago, MYK-IT said:

As you have both started to migrate etc, are either of you using MDT/MECM/SCCM for image (re)deployment?

 

We just redeployed in the summer as part of a move to Intune from AD (hopefully retiring our on-site server either in the summer hols or at the end of the year when our Impero support ends and we see if Senso Network Cloud has improved by then to add onto our free Safeguard Cloud through LGfL, as I've always been nervous of the complaints here around reliability), initially just using USB sticks with vanilla Windows + Drivers per RM's standard practices (they managed the project for us and configured baseline policies), but I'm looking into OSDCloud for future deployments to clear out HP's bloat without paying the extra fees to get Corporate-Ready images.

 

I think devices (especially business-grade ones) will be coming with both the old and new certs for a little bit yet, and it would probably just need an ADK/WinPE update to get the new bootmgr once that changes.

[MYK-IT]

2 hours ago, DavR said:

 

We're using MDT for builds, and I haven't updated the boot images yet. Updated Default and Active DBs still have the 2011 cert in, so I'm guessing will be matching on that, as I have done test rebuilds since. I guess when the 2011 cert expires or is revoked, or we take delivery of new devices with only 2023 certs, we'll need updated boot images with the 2023 certs. 

 

I'm told that expired certificates will still work, though, to prevent devices that couldn't get the new certs from bricking. So I guess for us we'll want to keep boot images with both sets of certs in (not sure how this will be managed yet).

 

 

On a test computer (ensuring i have Jan 2026 update applied and latest BIOS with 2023 Certificates), I've followed:

 

 

Quote

 

Device testing using registry keys 

When testing individual devices to ensure that the devices will process the updates correctly, the registry keys can be a straightforward way to test. 

 

To test, run each of the following commands separately from an administrator PowerShell prompt: 

 

• reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
• Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
• Manually reboot the system when the AvailableUpdates becomes 0x4100
• Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

The first command initiates the certificate and boot manager deployment on the device. The second command causes the task that processes the AvailableUpdates registry key to run right away. Normally the task runs every 12 hours. The registry key should quickly change to 0x4100. Rebooting and running task again will cause the boot manager to be updated and the AvailableUpdates to become 0x4000.

 

 

and it has completed fine.

 

As @DavR mentioned existing PXE (and other media) will still work (for now) as Microsoft are not revoking the 2011 Certificates -  but they'll expire in June 2026 etc.  So that's the deadline to get USB, ISO, WIM, & PXE images updated with the 2023 Certificates - or create separate version.

 

Edited January 29 by MYK-IT

[MYK-IT]

Just an update, especially for those using the Intune Secure Boot Certificate Update (via Settings Catalog) and OEM-based Images, and to monitor the certificate upgrade in general!

 

Secure Boot Status Report: Secure Boot Readiness in Intune

 

Even Pro Editions! (Microsoft Intune method of Secure Boot for Windows devices with IT-managed updates - Microsoft Support)

 

Quote

 

Known Issues
Microsoft Intune Error Code 65000 on Pro editions of Windows 

Symptoms

Secure Boot configuration settings deployed through Microsoft Intune Mobile Device Management (MDM) are currently blocked on Pro editions of Windows 10 and Windows 11.

 

• Attempts to apply these policies result in Microsoft Intune Error Code 65000.
• Event logs might record POLICYMANAGER_E_AREAPOLICY_NOTAPPLICABLEINEDITION, indicating the feature is unavailable on this edition.

 

Workaround

The issue is under investigation, and additional information will be shared as soon as it becomes available.

 

 

Looks like will have to use the Registry Method instead (for now).

Edited February 3 by MYK-IT

[DavR]

On 05/01/2026 at 22:17, DavR said:

Just gonna throw this on here, because I haven't seen it widely reported anywhere else yet and it was driving me nuts.... Hyper-V guests do NOT support the certificate upgrade yet.

 

For the certificate upgrade to complete, you need to upgrade the virtual device firmware first, but the ability to update this firmware hasn't been released yet.

 

It IS possible to create a brand new Hyper-V 2nd Gen guest, and as long as you've updated the host first, this should be created with the new certificates. But upgrading the certs on existing Hyper-V VMs doesn't seem to be available yet.

 

For those of us who are manually deploying the new secure boot certificates, the March 2026 Cumulative Update seems to have "fixed" the Hyper-V problem. I have successfully updated the certs on two Hyper-V guest servers this afternoon, and will leave the rest to group policy. 

 

Interestingly, if you test for the certs using the Powershell commands, it succeeds on db, but still fails on dbdefault. I presume because these VMs are still looking at the host for dbdefault, whereas newly created guests have their own dbdefault. 

 

Either way, it's showing as successful in both registry and event viewer, so that's good enough for me. 

[TwistedHelixis]

Quote

manually deploying the new secure boot certificates

So far, I have been running round updating the BIOS on older laptops. Not even looked at the servers yet. What is the manual way?

[DavR]

30 minutes ago, TwistedHelixis said:

So far, I have been running round updating the BIOS on older laptops. Not even looked at the servers yet. What is the manual way?

 

When I say manual, I mean using the group policy / Intune / registry settings to force the certificate update.

Rather than the hands off way of updating BIOSes and hoping Windows Update take it's course.

[Jaan]

Hey everyone,

I’ve been working on identifying machines in our environment that still need the Windows UEFI CA 2023 certificate update. I'm using a PowerShell scanner and a collection filter for PDQ Inventory that others might find useful, so i thought i's share just incase.

 

I created a new scan profile in PDQ that runs the powershell script below on every heartbeat

I’m using the script below to check for the certificate presence in the Active DB and verify Secure Boot status:

 

# Checks if the Windows UEFI CA 2023 certificate is present in the Active DB
try {
    $db = Get-SecureBootUEFI db
    $isUpdated = ([System.Text.Encoding]::ASCII.GetString($db.bytes) -match 'Windows UEFI CA 2023')
    $sbStatus = Confirm-SecureBootUEFI
} catch {
    $isUpdated = "Error/Not Supported"
    $sbStatus = $false
}

[PSCustomObject]@{
    UEFI_2023_Cert_Present = $isUpdated
    SecureBoot_Enabled     = $sbStatus
}

 

Once the scan completes, to find the machines that need attention, create a dynamic PDQ collection group with this logic:

 

Group: All

Table: PowerShell (UEFI Certificate Check) ---- Or whatever you namesd your UEFI scan profile

Column: UEFI_2023_Cert_Present

Comparison: Is False

 

I have about 140 machines (including a 3-node cluster using Cluster aware updating) flagging as missing the cert.

 

I typically deploy Cumulative Updates via PDQ Deploy and avoid WuFB. My understanding was that MS was handling this via CUs, but even fully patched machines are flagging.

 

Is there a specific "Out of Band" update I should be targeting instead of the standard CU?

Does anyone have a proven workflow for applying the second and third stages of these revocations (the registry keys/manual policy applications) via PDQ?

 

AI says the below in my setup, anybody else used this approach and does it ring true? i just assumed MS would fix this ia windows updates and i wouldn't have to do much!  LOL Are the certs included in the Cumulative updates but just not enabled?

 

AI:

 

---

the reason your machines show as "missing" the cert despite having Cumulative Updates installed is that Microsoft did not automate the actual deployment of the DBX (revocation list) to the UEFI firmware. Installing the Windows Update only provides the capability to update the firmware; it doesn't actually pull the trigger. Microsoft did this to avoid "bricking" older machines with incompatible BIOS.

 

How it works:

To actually move a machine from "False" to "True" in your script, you generally have to perform these steps (after the CU is installed):

 

Stage 1: Apply the standard Cumulative Update (which i've done).

Stage 2 (The Manual Bit): You must apply specific registry keys to the machine. Once the keys are set and the machine is rebooted, the OS will attempt to write the new certificate to the UEFI variables.

---

 

Any input at all would be great

[MYK-IT]

if you want to manually enforce the update, as opposed to Microsoft 'managing' you need to update the following registry entry. (Even the Intune Device Configuration method> Settings Catalog > Secure Boot > Enable Secureboot Certificate Updates > Enabled does not enforce either.) 

 

Registry Key: HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\AvailableUpdates

Type: DWord

Value: 0x5944

 

This will force start the 2023 certificate update process (and will only complete if all conditions are correct). This is opposed to Microsoft initiating the process as, and when etc. (including using the Intune Device Configuration).

 

You can monitor progress (using PDQ Inventry) based on following:

 

Stage 1:

Registry Key: HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\AvailableUpdates

Type: DWord

Value: 0x5944

 

Registry Key: HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\UEFICA2023

Type: Reg_SZ

Value: NotStarted

 

Stage 2: In Progress

Registry Key: HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\AvailableUpdates

Type: DWord

Value: 0x400 or 0x4100

 

Registry Key: HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\UEFICA2023

Type: Reg_SZ

Value: In Progess

 

Stage 3: Completed

Registry Key: HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\AvailableUpdates

Type: DWord

Value: 0x4000

 

Registry Key: HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\UEFICA2023

Type: Reg_SZ

Value: Updated

 

Task Scheduler

The Secure-Boot-Update Task is scheduled to run automatically every 12-hours, so you will need to manually (or automate) the initiation if you don't want to wait that long (e.g. testing etc).

 

Task Scheduler > Microsoft > Windows > PI > Secure-Boot-Update

 

BIOS

And goes without saying, that you need to ensure latest (support) BIOS is applied!

 

 

Edited April 28 by MYK-IT

[DavR]

I would add that, as far as I can tell, the automatic update of certificates only happens on home or unmanaged systems. Most if not all corporate systems will need intervention to make it happen.

 

We had more success with the Group Policy and Intune Device Config methods than @MYK-IT, in testing at least they worked on every device I tried. But whether you use the reg setting, GP or Intune configs, the outcome should be the same. As mentioned though, you do need to ensure the BIOS is up to date first though, no upgrades will work unless this is done.

 

You can deploy the enablement keys to all devices, and it shouldn't cause any bother if they're unsupported, it should just fail silently. However, to avoid unnecessary errors, we used a hardware filter in our policies/configs to only target compatible hardware models that I knew had had the BIOS updates.

[ITGuyNW]

Has anyone had an uptick in bitlocker triggers? Seems to be affecting a few of ours after the latest updates

 

Microsoft have released a guide 

Secure Boot troubleshooting guide - Microsoft Support

[DavR]

Haven't noticed anything here for the certificate enablement, but any BIOS updates you/updates do beforehand could well trigger a Bitlocker warning. 

 

Unless certain BIOSes are reporting the cert change as a configuration change? 

[itskdog]

2 hours ago, DavR said:

Haven't noticed anything here for the certificate enablement, but any BIOS updates you/updates do beforehand could well trigger a Bitlocker warning. 

 

Unless certain BIOSes are reporting the cert change as a configuration change? 

 

Did have one today now I'm starting to manually deploy to certain machines (one or two of each model if the Microsoft Managed Opt-in didn't already show it already worked on that model), the reason given on the recovery screen was specifically "because Secure Boot policy has unexpectedly changed.", which suggests to me that the certificates changing caused a change to the Secure Boot variables, or BitLocker wasn't paused correctly during the certificate install.

 

BIOS updates should usually pause BitLocker during the reboot for the update, but there's a chance, especially on laptops (where it might postpone the update when on battery), that the update isn't applied on the first reboot, and so BitLocker gets enabled again by Windows before the update is applied.

[TwistedHelixis]

Quote

BIOS updates should usually pause BitLocker during the reboot for the update, but there's a chance, especially on laptops (where it might postpone the update when on battery), that the update isn't applied on the first reboot, and so BitLocker gets enabled again by Windows before the update is applied.

 

I normally use this code

Suspend-BitLocker -MountPoint "C:" -RebootCount 4

 

Lets the device reboot 4 times before enabling bitlocker again.

Edited May 6 by TwistedHelixis

[DavR]

11 minutes ago, itskdog said:

BIOS updates should usually pause BitLocker during the reboot for the update, but there's a chance, especially on laptops (where it might postpone the update when on battery), that the update isn't applied on the first reboot, and so BitLocker gets enabled again by Windows before the update is applied.

 

Depends on how you're doing the BIOS updates, I guess. When I've done manual updates, I've always had to specify "suspend Bitlocker" as a parameter of the command (eg Dell installers), or use a variation on @TwistedHelixis's code above in a script to run the update (eg HP installers).

 

I've never let Windows Update run a BIOS update, so not sure whether that automatically takes this into account.

[DavR]

14 minutes ago, itskdog said:

Did have one today now I'm starting to manually deploy to certain machines (one or two of each model if the Microsoft Managed Opt-in didn't already show it already worked on that model), the reason given on the recovery screen was specifically "because Secure Boot policy has unexpectedly changed.", which suggests to me that the certificates changing caused a change to the Secure Boot variables, or BitLocker wasn't paused correctly during the certificate install.

 

Hmmm. What makes/models are you seeing that on? 

I've not had to pause Bitlocker for the certificate update on any of the Dell or HP devices I've done it on here. Only for the BIOS version updates.

[6Foot3]

5 hours ago, ITGuyNW said:

Has anyone had an uptick in bitlocker triggers? Seems to be affecting a few of ours after the latest updates

 

Microsoft have released a guide 

Secure Boot troubleshooting guide - Microsoft Support

I've had two in recent months.

[itskdog]

1 hour ago, DavR said:

 

Hmmm. What makes/models are you seeing that on? 

I've not had to pause Bitlocker for the certificate update on any of the Dell or HP devices I've done it on here. Only for the BIOS version updates.

 

It was an HP ProOne 440 G6, so a little bit older now. I think Windows is meant to suspend automatically, but I'm sure there's the occasional glitch as @ITGuyNW pointed to in Microsoft's own documentation.

 

1 hour ago, DavR said:

I've always had to specify "suspend Bitlocker" as a parameter of the command (eg Dell installers), or use a variation on @TwistedHelixis's code above in a script to run the update (eg HP installers).

 

We mainly go through Windows Update, but whenever I've used an HP Softpaq or HPIA it usually suspends itself as well. The Insyde UEFI updater even prompts for confirmation when run interactively, not sure about HP's own UEFI as I haven't had to do those interactively for a while as those devices also have HPIA & WUfB support.

[DGrice]

Just read this on the official Microsoft support page:

"Microsoft is updating the Secure Boot certificates originally issued in 2011 to ensure Windows devices continue to verify trusted boot software. These older certificates begin expiring in June 2026. Devices that haven’t received the newer 2023 certificates will continue to start and operate normally, and standard Windows updates will continue to install. However, these devices will no longer be able to receive new security protections for the early boot process, including updates to Windows Boot Manager, Secure Boot databases, revocation lists, or mitigations for newly discovered boot level vulnerabilities. "

 

I shouldn't think this would cause any immediate concern, but definitely something to check!

[ZeroHour]

Just to say you can check a machine directly in Windows in Windows Security Centre -> Device Security. I think it should read like below if you have the updated certs (this pc seems to have updated without needing a bios update)

 

[psydii]

Anyone got any tips on persuading Thinkpad/ThinkCenter machines to auto update their BIOS's?

We're mostly ok on staff machines, as most teachers do click OK on the bios update nag screen at least once a year, but for the rest they just wont take, and almost none have reported to intune/wufb/autopatch that they need bios updates! (lots of random drivers recommended though). 

 

We've got Lenovo system update on most machines, prior to that we used the Lenovo's 3rd Party Catalog for WSUS/SCCM (which would do bios updates), but we moved from that a couple of years ago.

 

LSU seems to hold off forcing a bios update, requiring user interaction to confirm, even when all other updates just install silently.

Delivery via Intune/WUFB/AutoPatch would be preferred.. but incantations to get LSU to work would be welcomed too!

[Jaan]

I've just discovered MS V3 ADMX templates for 25h2 that has a "secureboot.admx" gpo

 

https://www.microsoft.com/en-us/download/details.aspx?id=108542

[DavR]

Yep, not sure quite how long that's been available, but we updated our templates a few months ago and have been using the new Secure Boot GP settings to force the enablement for the new certificates 🙂