Did you manually update your Secure Boot Keys ?

Edit .. please ensure that 'fast start up' in control panel > power options is disabled
the 2023 cert will not load correctly if fast start up is enable ..

if any body wishes to check the secure boot 2023 cert is enabled.

check the following Reg entry which if set to 0, the machine is not fully protected. you could manually set it to 2, but this could cause a problem if the database hasn't been updated. At this point it may of course have nothing to do with the hardware and be some other issue.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing.

• Look for the registry value named WindowsUEFICA2023Capable.
• If the key exists and is set to 1, the system has the "Windows UEFI CA 2023" certificate in the DB, and the mitigation is in place.
• If the key is set to 2, the certificate is in the DB, and the system is using the 2023 signed boot manager.
• If the key is missing or set to 0, the certificate is not in the DB, and the system is not fully protected.

if you have any problems after changing the registry key, boot into the BIOS and disable secure boot.
save settings and restart into Windows. change the registry key back to before the change.

restart the system again in to the BIOS and enable secure boot.
save settings and restart into Windows. you can now re-enable 'fast start up'.
best of luck, Steve ..

WindowsUEFICA2023Capable is set to 2, am I good then?

I also saw another key "UEFICA2023Status" that was set to "NoStarted", what does that means?

CLS said:

WindowsUEFICA2023Capable is set to 2, am I good then?

I also saw another key "UEFICA2023Status" that was set to "NoStarted", what does that means?

Click to expand...

WindowsUEFICA2023Capable set to 2 means that your system is using the 2023 cert.

'NoStarted' means its in place and the system is using the 2023 cert and has already loaded it.

the system after the 2023 cert has been loaded may also change back to WindowsUEFICA2023Capable 1.
as that is now the default cert the system is using.

you can check via the powershell as Admin

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

the result should come back as 'true'

best of luck, Steve ..

There is no doubt that Mosby was a lifesaver for me, though this was largely due to the circumstances of my PCs.
One of my PCs is from a manufacturer listed here, but the relevant PK signature was not present. (It seems that manufacturers do not necessarily submit all of their PK signatures to Microsoft, and older, unsupported PCs in particular should be treated with caution.)


On top of that, the fact that my PK was an AMI TEST PK made matters worse. Although AMI has submitted some TEST PK signatures, my PC’s specific signature was not included. These details can be checked down to the fingerprint level using an Ubuntu Live USB.


Since I had already run all of Microsoft’s BlackLotus mitigation scripts, discovering that only the KEK could not be updated came as a real shock. That was when I came across Mosby on this forum. Desperate for a solution, I used Rufus (thanks are also due here) to install Mosby onto a USB drive. At first, simply typing “Mosby” wouldn’t launch it, but adding the extension allowed me to boot it successfully.


When I was finally able to confirm, via LiveUSB, that Mosby had installed the one-time Mosby PK along with the 2K KEK, I was truly delighted. Later, I learned that applying the DBx revocations is optional, but if this is something Microsoft updates through Windows Update, then all I need to do now is wait.

@Yozaemon, I am pretty sure that your PK being the dreaded AMI TEST PK (see here) is the precise reason Microsoft will not have a KEK update for you.

KEK updates are supposed to be signed by actual private keys (or more accurately PK private keys -- it's confusing, I know), and not by a test private key that is not private at all and can actually be known by anybody who looks for it, which is the reason why some motherboards, such as the one you use, are completely broken for Secure Boot when using the default variables from the manufacturer.

The thing is, because the (default) PK private key for your platform is actually public, which it should never ever be, anybody who wants should be able to make a KEK signed package, just like Microsoft did when they contacted platform manufacturers, and publish that to be used as signed Secure Boot database updates (i.e. updates you can apply without having to disable Secure Boot and place the platform in Setup Mode).

But doing so would be pretty pointless, since (with the default PK) your platform is completely broken for Secure Boot, which means that you might as well run with Secure Boot entirely disabled, instead of trying to apply an illusory Secure Boot update that's not actually going to make you safer at all (because I'm pretty sure any UEFI malware will first be trying to see if, by "chance", your platform might be using the AMI TEST PK, and use that as a point of attack if you do, before they even try to see if they can use one of the vulnerable Windows bootloaders that the 2023 certs and the revocation of PCA 2011 is supposed to protect you against).

In short, the fact that the relevant PK signature was not present and that your PK was AMI TEST PK are 2 sides of the same coin.

And this is precisely one of the case where you do want to use Mosby indeed, as it will completely remedy the issue (whilst you should also be contacting your manufacturer who should provide you with a firmware update to fix this crap, because it puts you at risk and it doesn't matter if something is out of support when it comes to a glaring vulnerability like this).

And I will add that, if you are paranoid, there's no telling if other manufacturers' PK private keys, that aren't AMI TEST PK, might not also be publicly known by bad actors (including the one for YOUR platform ), so Mosby does add a layer of safety there that the default MS updates won't be able to provide... But here, I'm mostly trying to see if I can also scare folks into using Mosby...

@Yozaemon, I am pretty sure that your PK being the dreaded AMI TEST PK (see here) is the precise reason Microsoft will not have a KEK update for you.

Click to expand...

Normally, I believe this is something that should have been fixed by the manufacturer through a firmware update.
However, the manufacturer refused to address the issue, citing the end of the support period.


It seems that AMI anticipated such situations, which is why they submitted the four compromised PK signatures to Microsoft. But since there are so many TEST PKs, it is probably impossible to provide a complete remedy for all of them.


In the end, I am truly grateful that I discovered Mosby, which allowed me to resolve both the PK and KEK issues at once.

Ok what am i missing here?
And would a fresh clean install wipe these keys out in secure boot mode

Akeo said:

And I will add that, if you are paranoid, there's no telling if other manufacturers' PK private keys, that aren't AMI TEST PK, might not also be publicly known by bad actors (including the one for YOUR platform ), so Mosby does add a layer of safety there that the default MS updates won't be able to provide... But here, I'm mostly trying to see if I can also scare folks into using Mosby...

Click to expand...

You make good points, and it worked! I used Mosby on all four of my machines to update the keys and get secure boot working.

garlin said:

I found another Dell user who reported PCA 2010 in their DBX.

Guess it's a Dell thing??

Click to expand...

Yes, could be as I know resetting to default keys never added the PCA 2010 to the DBX after I deleted all keys so not sure how it even got there in the first place as this is a new replacement motherboard from June 10, 2025. I had only done the Windows 2023 key and delete all keys, restore all keys and none of them added the PCA 2010 to the DBX.

There should be 3 persons with the PCA 2010 in the DBX which is me, @neldog and @NetMan304 (from this thread: TPM 2.0 Devices and remediation of CVE-2023-24932 (Black Lotus) UEFI / Secure Boot Vulnerability. - Help for those with "Known Issues")
and it appears all 3 of us are on Dell systems.

FIREMEDIC2700 said:

Ok what am i missing here?
And would a fresh clean install wipe these keys out in secure boot mode View attachment 146699

Click to expand...

Per this table, the only things missing are:
1) Microsoft Corporation KEK 2K CA 2023 (KEK)
2) Microsoft Corporation UEFI CA 2023 (DB)
3) Microsoft Option ROM UEFI CA 2023 (DB)

1 and 2 and even the Windows UEFI CA 2023 (DB) can be added with Mosby. Mosby will add #3 later or you can do it manually in the UEFI Bios setup by adding to it.

ok i must be doing something wrong . i downloaded mosbey 2 a usb . turned secure boot off . then changed boot order to boot from the mosby usb drive. when it opens i get this image . does this look right or am i missing a step .

FIREMEDIC2700 said:

ok i must be doing something wrong . i downloaded mosbey 2 a usb . turned secure boot off . then changed boot order to boot from the mosby usb drive. when it opens i get this image . does this look right or am i missing a step . View attachment 146721

Click to expand...

Looks correct to me. On my Dell, I hit F12 which allows me to pick the boot device.

ok is this a automated process cause when i type mosby nothing happens when booted from the usb with mosby installed . i have let it sit idle for 10 mins and i dont think nothing is happening

still cant get them using mosby any thoughts or suggestions

Brink said:

Frequently asked questions about the Secure Boot update process - Microsoft Support

support.microsoft.com

Click to expand...

Well, in a perfect world "most" of us, (notice that I did not say everyone of us), with some caveats to be sure, "should" be okay as the very first question from your link goes like this:


General Secure Boot FAQ
Q1: When should Secure Boot certificates be updated?
It’s best to update Secure Boot certificates well before the June 2026 expiration date.

If your device is managed by Microsoft, and sharing diagnostic data with Microsoft, then Microsoft will attempt to update the Secure Boot certificates automatically in most cases. While Microsoft will do their best to update Secure Boot, there will be some situations where the update is not guaranteed to apply and will need Customer action. The customer is ultimately responsible for updating the Secure Boot Certificates.


I found this in Settings, (Yes, I am sure everyone knows this already) Just for fun, I have just turned on the Optional Data setting for the next few months.

HOLLY GIG . WOW 1 gig of hard drive space i sure hope that does not have to be on and only the first one

I see that, but right below is a delete the file option. I GB is no big deal for me. For some I see where that would be a no go, and I will not leave it set that way too very long.

well since this is the case i wonder if i should keep trying to get mosby to work to install my missing certif

FIREMEDIC2700 said:

ok is this a automated process cause when i type mosby nothing happens when booted from the usb with mosby installed . i have let it sit idle for 10 mins and i dont think nothing is happening

Click to expand...

It is supposed to start the program and you should have been greeted by Mosby within 1 second.