On Manually updating UEFI CA2023 security keys

jumanji · Friday at 8:31 AM

My Dell Inspiron 3280 AIO running Windows Home 25H2 Build 8437 (the latest preview) will not be getting the automatic update of CA 2023 keys.

Has any one manually updated such End of Service Life (EoSL) desktops/Laptops successfully with the following recommended PowerShell commands run as administrator? Is there any risk involved?

Copy and paste in Powershell admin
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -Name "AvailableUpdates" -Value 0x40
Trigger the update next
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

Restart your PC twice to apply the keys to your motherboard firmware.

NormanF · Friday at 9:55 AM

No risk. Once you add them, you leave the old secure boot certificates alone. Microsoft will revoke them when secure boot is ready to boot from the new secure boot certificates.

garlin · Friday at 10:12 AM

1. Your last BIOS update for the Inspiron 3280 AIO was August 2023, so it won't be factory supported. It may be possible that Dell submitted a signed KEK CA 2023 to MS, but it's more unlikely given the BIOS's age.

2. Window's Secure Boot update task cannot do anything to harm your PC. But it'solimited when there is no matching KEK CA 2023 cert available for your PC. This blocks the entire rest of the update process, as the chain of trust is established from having a valid KEK CA 2023.

If using AvailableUpdates=0x40 doesn't do anything, then manual help is required.

3. My experience is on most Dell PC's, they don't support manual enrollment of the KEK cert file because they're expecting a different signing format. Unfortunately, only Dell can provide a file signed this way.

To update this PC, you will have to temporarily disable Secure Boot, change the UEFI mode from Standard to Custom mode, and Delete All Keys. This allows a replacement set of certs (Windows OEM Devices) to be installed. With this new set of certs, your UEFI will be compliant and Windows can finish the rest of the Secure Boot migration steps.

After you have deleted all the Secure Boot keys, you can run an update script to install the Windows OEM Devices bundle of certs:
garlin's PowerShell scripts for updating Secure Boot CA 2023

This solution has worked for a good number of Dell owners of different PC models.

gunrunnerjohn · Friday at 10:58 AM

I used the @garlin scripts to update Secure Boot for an old HP-ENVY desktop with a BIOS date in 2014.

It actually went way easier than I had anticipated when I decided to revive this old computer!

jumanji · Saturday at 12:37 AM

garlin said:
''''''''''''To update this PC, you will have to temporarily disable Secure Boot, change the UEFI mode from Standard to Custom mode, and Delete All Keys. This allows a replacement set of certs (Windows OEM Devices) to be installed. With this new set of certs, your UEFI will be compliant and Windows can finish the rest of the Secure Boot migration steps. .............

Thanks for chipping in.

At the moment I am not inclined to meddle with the BIOS in anyway.

In the meanwhile, I would request you to kindly review the following youtube video - Secure Boot Warning? Fix Older Boot Trust Configuration (Easy Guide) - for your expert opinion, if you please.

@gunrunnerjohn

I doubt what is applicable to your 2014 HP -Envy would be applicable to my 2019 Dell Inspiron 3280. ( Only birds of the same feather flock together

.) In any case I will keep it in mind.

garlin · Saturday at 1:01 AM

The CA 2023 certs don't have to be downloaded. They're included in the \Windows\System32\SecureBootUpdates folder as "post-signed" binary files, which are appended to your existing Secure Boot variables.

The Secure Boot update task proceeds on the concept of a "chain of trust" where it must first install the underlying certs in sequence. While you can request the task to install certs out of sequence, none of that matters unless you have all the certs aligned.

1. Your PC has a Platform Key (PK) provided by the OEM.

2. To validate the CA 2023 certs, a KEK CA 2023 cert must be installed. This KEK is signed by the PC's PK (which is controlled by the OEM) to validate the trust. Once the MS KEK is added, then all the CA 2023 DB or DBX certs provided by MS are now trusted.

3. You don't need a KEK in order to install the DB or DBX certs, but those certs cannot be validated (trusted) without the presence of the KEK CA 2023. Without it, your trust chain is not valid and CA 2023-signed files are not authenticated.

If you're fortunate, then KEK CA 2023 is provided in a factory BIOS or submitted to MS. MS collects submitted KEK files from OEM's, whenever a BIOS update will not be provided to users. Sometimes you're unlucky, and no KEK file is available because the OEM never bothered to sign one.

PC's which are marked in the "High Confidence" bucket will have a BIOS update, or a signed KEK given to MS.
PC's which are marked "Need More Data", are more likely to need manual updating of the BIOS.

4. Certs stored in the UEFI are entirely unrelated to certs imported to the Windows certificate store. This does nothing to fix your Secure Boot problems. When the BIOS boots an operating system, there is no OS that exists yet. Therefore it cannot read the Windows cert store, the only certs it can read before the OS loads are from the UEFI's stored keys.

Importing the Secure Boot certs to the cert store doesn't do anything for the UEFI.

5. Bottom line: The Secure Boot update task should have run by now on everyone's W11 system. If it hasn't installed the CA 2023 certs by itself, then the chances of requiring manual intervention are high. The holdup for the migration process has always been the OEM's providing the KEK file.

jumanji · Saturday at 2:26 AM

Thanks @garlin for your review and importance of KEK.

From what I read under "Device Security" ( screenshot below) it is obvious that Dell has not done anything mitigate the problem and have simply washed off their hands.

So may be a BIOS level intervention to eliminate the existing keys is necessary as you opine. If by any mistake, the system becomes unbootable I can always restore the factory keys.

XxXxX · Saturday at 2:51 AM

@jumanji
i used that method in the video, post#5, to update 3 chuwa laptops with the 2023 certs
then used this HowTo to finish off updating the certs. yes i know that they are not dells

Secure boot update HowTo

i have put this together as i had problems updating 2 desktops and 3 laptops. which have now all had their Secure Boot Certs updated to the new 2023 secure boot cert also the other post about this were getting very long and confusing. this is in two parts. part A and part B. edit by me. please...

www.elevenforum.com

but chuwa have little or no support so it was a D.I.Y job or nothing.
best of luck Steve ..

suatcini54 · Saturday at 5:32 AM

jumanji said:
Thanks for chipping in.

At the moment I am not inclined to meddle with the BIOS in anyway.

In the meanwhile, I would request you to kindly review the following youtube video - Secure Boot Warning? Fix Older Boot Trust Configuration (Easy Guide) - for your expert opinion, if you please.

@gunrunnerjohn

I doubt what is applicable to your 2014 HP -Envy would be applicable to my 2019 Dell Inspiron 3280. ( Only birds of the same feather flock together .) In any case I will keep it in mind.

Thanks for the video.

I updated my Secure Boot certificates about a year ago. Then I watched the video and looked for Windows UEFI CA 2023 certificate in certlm.msc console.

I couldn't find Windows UEFI CA 2023 certificate in there.

Then just out of sheer curiosity, I asked AI why I could not see the said certificate in the certlm.msc console (in the certificate store). The following is the answer from the AI:

So what is the point in installing the Windows UEFI CA 2023 certificate in the certificates store ?

jumanji · Saturday at 7:22 AM

@garlin , @XxXxX and @suatcini54

I ran the following Powershell Admin commands
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')

confirm-SecureBootUEFI
and both returned TRUE as shown in the following screenshot

Does that mean my system has been updated to UEFI CA2023?

XxXxX · Saturday at 7:27 AM

jumanji said:
@garlin , @XxXxX and @suatcini54

I ran the following Powershell Admin commands
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')

confirm-SecureBootUEFI
and both returned TRUE as shown in the following screenshot

View attachment 172954

Does that mean the my system has been updated to UEFI CA2023?

yes.
best of luck Steve ..

garlin · Saturday at 10:12 AM

jumanji said:
Does that mean my system has been updated to UEFI CA2023?

Please run my check script. Trying to read the individual certs, one by one, doesn't offer a complete report on where you are in the migration process.
garlin's PowerShell scripts for updating Secure Boot CA 2023

Code:

Check-UEFI.bat -Verbose

garlin · Saturday at 10:18 AM

suatcini54 said:
So what is the point in installing the Windows UEFI CA 2023 certificate in the certificates store ?

None. Anyone who provides this advice doesn't understand how Secure Boot works. It's a BIOS-based security measure. The same cert can be imported from the BIOS menu (on some PC's).

If it was as simple as in the video, there would be no unsupported PC's and MS wouldn't have to constantly remind you to update Secure Boot.

XxXxX · Saturday at 11:06 AM

garlin said:
None. Anyone who provides this advice doesn't understand how Secure Boot works. It's a BIOS-based security measure. The same cert can be imported from the BIOS menu (on some PC's).

If it was as simple as in the video, there would be no unsupported PC's and MS wouldn't have to constantly remind you to update Secure Boot.

3 chuwa laptops my grandchildren use wouldn't update secure boot.
it was only after i added the certs to the data base did the TPM/BIOS secure boot update
i have no explanation why or why not but that was the only way they would update.

the 2 HP all in ones in use updated their secure boot certs without the need to update the data base
again i can give no explanation why or why not, that was just the way it happened.

needless to say this whole affair to update systems has been time consuming.
best of luck Steve ..

FIREMEDIC2700 · Saturday at 11:10 AM

i am not on a dell but a older hp from like 2014 . and with garlin's scripts and this
How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932 - Microsoft Support.
i was able to get this machine current . the only reason is used the link is because i could not get power shell to work .

garlin · Saturday at 11:26 AM

XxXxX said:
3 chuwa laptops my grandchildren use wouldn't update secure boot.
it was only after i added the certs to the data base did the TPM/BIOS secure boot update
i have no explanation why or why not but that was the only way they would update.

the 2 HP all in ones in use updated their secure boot certs without the need to update the data base
again i can give no explanation why or why not, that was just the way it happened.

needless to say this whole affair to update systems has been time consuming.
best of luck Steve ..

What matters is whether a KEK CA 2023 was provided via a previous or recent BIOS update, or a submitted KEK file. Everyone who ends up in the "High Confidence" bucket falls into those categories. Everyone who's stuck in "More Data Needed" is unsupported, until the OEM does something.

The longer you wait, there's a slightly larger chance that a lagging OEM finally submits the KEK file to MS. After receiving a KEK, MS can move your PC from "More Data Needed" to "High Confidence" and the Secure Boot task does it's thing. Every month, Windows pushes a revised set of JSON files which indicate whether your PC will be updated or not.

There's a lot of smoke & mirrors in this process, IMO to protect the OEM's reputations. MS isn't going to publicly shame the vendors for abandoning certain PC models. Everyone hides behind the "waiting for telemetry data" story even though all the parties know which PC's won't get automatic updates.

Many PC's could be supported by manual key enrollment, but all parties don't want the tech support headache that entails. If the vendor hasn't stepped by the end of this summer, they probably won't ever for your individual PC.

gunrunnerjohn · Saturday at 11:38 AM

FIREMEDIC2700 said:
i am not on a dell but a older hp from like 2014 . and with garlin's scripts and this
How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932 - Microsoft Support.
i was able to get this machine current . the only reason is used the link is because i could not get power shell to work .

I recently updated an old HP-ENVY desktop with a 2014 AMI BIOS using the @garlin scripts. It went slick and quick and MSC is happy with my configuration. garlin's check script also says I'm in good shape. The most time consuming part was just finding and setting the BIOS Secure Boot initialization to get the ball rolling.

Scott · Saturday at 2:52 PM

garlin said:
What matters is whether a KEK CA 2023 was provided via a previous or recent BIOS update

It was.

garlin said:
Everyone who's stuck in "More Data Needed" is unsupported, until the OEM does something.

But I'm stuck in "More Data Needed".

Although my system 2 is fully updated.

Code:

PS D:\Scripts\SecureBoot-CA-2023-Updates.v2026.05.27> .\Check_UEFI-CA2023.ps1 -verbose
Windows 11 25H2 (26200.8524)

Secure Boot: ON
Virtualization Based Security: ON
BitLocker on (C:) OFF

BIOS Firmware
-------------
    ASUS System Product Name
    Version: 2803
    Date: 2025-12-08

Factory Default UEFI PK Cert
----------------------------
    ASUSTeK MotherBoard PK Certificate

UEFI PK Cert
------------
    ASUSTeK MotherBoard PK Certificate

Factory Default UEFI KEK Certs
------------------------------
    Microsoft Corporation KEK CA 2011
    Microsoft Corporation KEK 2K CA 2023
    ASUSTeK MotherBoard KEK Certificate

UEFI KEK Certs
--------------
    Microsoft Corporation KEK CA 2011
    Microsoft Corporation KEK 2K CA 2023
    Canonical Ltd. Master Certificate Authority
    ASUSTeK MotherBoard KEK Certificate

Factory Default UEFI DB Certs
-----------------------------
    Microsoft Corporation UEFI CA 2011
    Microsoft Windows Production PCA 2011
    Microsoft Option ROM UEFI CA 2023
    Microsoft UEFI CA 2023
    Windows UEFI CA 2023
    ASUSTeK MotherBoard SW Key Certificate
    ASUSTeK Notebook SW Key Certificate

UEFI DB Certs
-------------
    Microsoft Corporation UEFI CA 2011
    Microsoft Windows Production PCA 2011
    Microsoft Option ROM UEFI CA 2023
    Microsoft UEFI CA 2023
    Windows UEFI CA 2023
    Canonical Ltd. Master Certificate Authority
    ASUSTeK MotherBoard SW Key Certificate
    ASUSTeK Notebook SW Key Certificate

Factory Default UEFI DBX Certs
------------------------------
    (NONE)
    EFI_CERT_SHA256_GUID Signatures: 430

UEFI DBX Certs
--------------
    Microsoft Windows Production PCA 2011
    Windows BootMgr SVN 8.0
    EFI_CERT_SHA256_GUID Signatures: 489

UEFI Variables
--------------
    DeviceGuard (VBS): ON
    Credential Guard: ON
    SBAT (Linux only): sbat,1,2024010900 / shim,4 / grub,3 / grub.debian,4

EFI Files
---------
    Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.
        \\.\HarddiskVolume1\EFI\Microsoft\Boot\bootmgfw.efi
        File Version: 28000.327, SVN 8.0

    Registry: "WindowsUEFICA2023Capable" = 2
        [Windows UEFI CA 2023] in UEFI DB, and Windows starting from CA 2023 Boot Manager.

    SkuSiPolicy.p7b is CURRENT.
        \\.\HarddiskVolume1\EFI\Microsoft\Boot\SkuSiPolicy.p7b
        Version: 3.0.0.14
    NOT RECOMMENDED for dual-boot setups.


STATUS REPORT
-------------
    Registry: "UEFICA2023Status" = Updated

    SUCCESS: UPDATES ARE FINISHED.
    UEFI CA 2023 certs are present, PCA 2011 cert is revoked.

PS D:\Scripts\SecureBoot-CA-2023-Updates.v2026.05.27>

garlin · Saturday at 3:31 PM

Scott said:
But I'm stuck in "More Data Needed".

Although my system 2 is fully updated.

Your case is a typical example, of why you don't put too much credibility into the Confidence Bucket reporting.

1. If your OEM has a BIOS update, they could share those details with MS (motherboard model + minimum BIOS version). Windows can cross-index your motherboard + BIOS version against the OEM's list of supported PC's. It might be only a BIOS version above a certain date is needed, and older BIOS'es cannot be updated.

2. With a signed KEK file (see the MS Secure Boot Objects repo on GitHub), MS collects a known thumbprint from the OEM. By matching the thumbprint against your PC, they have a good guess that a submitted KEK can be written to your BIOS. Everyone in the supported side is marked "High Confidence".

3. There's a 3rd bucket, in which MS blocks all updates because there's a confirmed BIOS defect that needs to be addressed by the OEM. Everyone who is not "High Confidence" or the "blocked" bucket belongs in "More Data Needed".

The different pools can be summarized as Supported / Bad Update / "I don't know".

"More Data Needed" is the commonly misunderstood category. It doesn't imply whether an update is possible or not, but MS hasn't gathered definitive proof that your PC has an available BIOS or still doesn't have a signed KEK that matches your BIOS's thumbprint. It doesn't know. If you're in "More Data Needed" you will spend at least one more month (until the next Monthly Update) before possibly getting moved to "High Confidence".

A live system where all the Secure Boot changes have been applied, can still be reported as "More Data Needed". The category is only defined by what group your bucket ID has been assigned to (updated once a month). This status doesn't reflect whether you already finished with updates or not. To be a member of the "High Confidence" or "More Data Needed" buckets is determined solely by matching your generated Bucket ID against a list every month.

Success or failure of applying the updates (which show up as TPM-WMI events) will not change the Confidence level. It represents a "best guess" of what MS expects to happen with your specific PC.

This is why my tools completely ignore the Bucket indicators. And performs directing checking of each cert in the KEK, DB and DBX variables by name. No harm can be done by trying to append new certs to the existing variables. If you don't have the right KEK file, the KEK append will fail with an authentication error. Then you know it's time to try so manual intervention.

DarkShadowMD · Monday at 2:26 AM

If it helps, for me the process was as simple as:

Update BIOS (Means, check if there's an update for you, so you get the certs in BIOS, you need them, especially if the manufacturere updated or sent their KEK to MS for Cert updates.)
Run @garlin 's script to check status
Run the Update script from him wih the revoke option to update the certs and reboot
Profit.

Hear the man, he knows his business, thanks to him my 3 systems are up to date without issues. I was really scared because I hate messing with BIOS and I ignored everything about the process. He has even talked with Microsoft people to get fixes for commands that Microsoft broke for certs, or to get info about files like DBX databases so we know we are updated.

He's basically your salvation, follow his advice.

On Manually updating UEFI CA2023 security keys

Well-known member

My Computers

Well-known member

My Computers

Well-known member

My Computer

Well-known member

My Computers

Well-known member

My Computers

Well-known member

My Computer

Well-known member

My Computers

Just a Computer User

My Computers

Well-known member

My Computers

Well-known member

My Computers

Just a Computer User

My Computers

Well-known member

My Computer

Well-known member

My Computer

Just a Computer User

My Computers

Well-known member

Attachments

My Computer

Well-known member

My Computer

Well-known member

My Computers

Well-known member

My Computers

Well-known member

My Computer

Peaceful Citizen

My Computers

Similar threads