Did you manually update your Secure Boot Keys ?

There are many users who dual-boot, or want to continue using old Windows (even W7)...

Just because W11 will enforce it, doesn't mean you can block enforcement. Knowing MS's previous history, it will be a hidden scheduled task. Just like CompatAppraiser running every night. I'm willing to bet it on.

garlin​

ok can u explain this please when changing the convertconfig on a iso . which i did and saved it. but i dont know what this means can u explain
5. Run the Windows cmd script likely you normally would do.

FIREMEDIC2700 said:

garlin​

ok can u explain this please when changing the convertconfig on a iso . which i did and saved it. but i dont know what this means can u explain
5. Run the Windows cmd script likely you normally would do.

Click to expand...

If you already know how to use UUP dump, then edit the ConvertConfig.ini from the extracted ZIP file and change "UpdtBootFiles=1".

If you don't know what I'm talking about (that's fine, not everyone dives that far into building their own ISO's), just wait for the official 25H2 ISO and Rufus will offer you the option to use new boot files.

i now how to use it. i just have never used the windows command script. i was asking what u ment by that sir i did edit the convert config

There's information about multiboot on the Microsoft page:

"My device uses multiple operating systems. How do I update my system?​

Update all Windows operating systems with updates released on or after July 9, 2024 before you apply the revocations. You might be unable to start any version of Windows that has not been updated to at least updates released on July 9, 2024 after you apply the revocations. Follow the guidance in the Troubleshooting Boot Issues section."



There will likely be workarounds for multiboot when an operating system has the 2023 certificate.

itsme1 said:

...

It won't be possible to disable it on Windows:

...

Click to expand...

By that do you mean no future build of Windows will allow a 2011 bootfile... so even if it's removed from DBX it still won't work?

My concern is how it can get the 2023 keys back into the UEFI secure boot variables if someone executes a "Restore Default Keys" in BIOS. I doubt many machines more than a couple years old will get BIOS updates, and most won't be updated even if they do have one available.

I know people who don't know what they're doing shouldn't futz around in BIOS, but we do. There's lots of ways to screw up the system, make it unbootable and seem like it's bricked. But usually, someone can help get it back running by doing a few simple things, like a CMOS reset for instance. But that won't help after default keys are restored if there's no way to boot with 2011 keys.

Buddywh said:

By that do you mean no future build of Windows will allow a 2011 bootfile... so even if it's removed from DBX it still won't work?

My concern is how it can get the 2023 keys back into the UEFI secure boot variables if someone executes a "Restore Default Keys" in BIOS. I doubt many machines more than a couple years old will get BIOS updates, and most won't be updated even if they do have one available.

I know people who don't know what they're doing shouldn't futz around in BIOS, but we do. There's lots of ways to screw up the system, make it unbootable and seem like it's bricked. But usually, someone can help get it back running by doing a few simple things, like a CMOS reset for instance. But that won't help after default keys are restored if there's no way to boot with 2011 keys.

Click to expand...

One way to get the keys sorted out is Mosby if you reset to defaults.

gunrunnerjohn said:

One way to get the keys sorted out is Mosby if you reset to defaults.

Click to expand...

That is exactly why I decided to spend the time and get myself comfortable with using it!

But that's also not something I could talk someone with even less computer tech skills than myself through. I'd hope Microsoft comes up with a solution, but that may be an ask too much. Maybe something like booting with secure boot disabled, it sees the situation and repopulates the keys then asks for a couple reboots with the last preceded by an instruction to re-enable secure boot if needed.

Buddywh said:

That is exactly why I decided to spend the time and get myself comfortable with using it!

But that's also not something I could talk someone with even less computer tech skills than myself through. I'd hope Microsoft comes up with a solution, but that may be an ask too much. Maybe something like booting with secure boot disabled, it sees the situation and repopulates the keys then asks for a couple reboots with the last preceded by an instruction to re-enable secure boot if needed.

Click to expand...

Hard to predict what MSC might do, I prefer to know what to do when they stumble.

Buddywh said:

By that do you mean no future build of Windows will allow a 2011 bootfile... so even if it's removed from DBX it still won't work?

My concern is how it can get the 2023 keys back into the UEFI secure boot variables if someone executes a "Restore Default Keys" in BIOS. I doubt many machines more than a couple years old will get BIOS updates, and most won't be updated even if they do have one available.

I know people who don't know what they're doing shouldn't futz around in BIOS, but we do. There's lots of ways to screw up the system, make it unbootable and seem like it's bricked. But usually, someone can help get it back running by doing a few simple things, like a CMOS reset for instance. But that won't help after default keys are restored if there's no way to boot with 2011 keys.

Click to expand...

Yes, it's obvious we're in a transition phase, and since Microsoft wants to revoke PCA 2011 during this transition phase, future builds will no longer contain the PCA 2011 certificate and will no longer be able to be installed(or work/boot) on computers with the 2011 certificate. This was also mentioned in this thread by the creator of mosby, Akeo. This will be around the 2027 builds.

I mentioned in another thread how to restore 2023 keys when a BIOS/firmware/security key has been reset. This comes from Microsoft on its KB ID: 5025885 page:

I saw one of your previous posts here, and I believe you've already used this procedure.

itsme1 said:

...
I saw one of your previous posts here, and I believe you've already used this procedure.

Click to expand...

Yes I have used the Recovery Procedure.

And based on that experience I know it relies on the BIOS to restore it's default keys, which are 2011 keys in my case and this was what I would have done to get in this pickle in the first place. It also repopulates EFI folders (which I was instructed to delete from the EFI partition) from Windows. I assume that once in that "enforcement" period it will mean also putting another 2023 bootfile in place, meaning it won't be effective then.

If by some stroke of good luck I get a BIOS update for my older motherboards that update the SB keys I'm fixed... and wouldn't likely get in this situation in the first place. But many of us won't be so lucky .

But if you're referring to the process related to creating a bootable recovery USB drive and copying the securebootrecovery.efi file to it I did not do that.

Curiously, I cannot create a bootable recovery USB now, it tells me that "some system files are missing". I wonder if that's because I used MOSBY to populate the secure boot variables and install a 2023 bootfile. I'm not that worried because the MOSBY USB serves the exact same purpose (it was created using RUFUS UEFI Shell2.2), I'll just have to remember that was my chosen solution. But I think I'd have to remember the same with the solution Microsoft laid out in your links... assuming that's what it is to be in the 'enforcement' phase.

Buddywh said:

By that do you mean no future build of Windows will allow a 2011 bootfile... so even if it's removed from DBX it still won't work?

My concern is how it can get the 2023 keys back into the UEFI secure boot variables if someone executes a "Restore Default Keys" in BIOS. I doubt many machines more than a couple years old will get BIOS updates, and most won't be updated even if they do have one available.

I know people who don't know what they're doing shouldn't futz around in BIOS, but we do. There's lots of ways to screw up the system, make it unbootable and seem like it's bricked. But usually, someone can help get it back running by doing a few simple things, like a CMOS reset for instance. But that won't help after default keys are restored if there's no way to boot with 2011 keys.

Click to expand...

I actually did that a few weeks ago, Mosby is one way to do it and the other way is what Microsoft said which you don't have to turn Secure Boot off first, both which I have tested and work.

Buddywh said:

That is exactly why I decided to spend the time and get myself comfortable with using it!

But that's also not something I could talk someone with even less computer tech skills than myself through. I'd hope Microsoft comes up with a solution, but that may be an ask too much. Maybe something like booting with secure boot disabled, it sees the situation and repopulates the keys then asks for a couple reboots with the last preceded by an instruction to re-enable secure boot if needed.

Click to expand...

The Secure Keys cannot be added with Secure Boot off from personal experience even with the Microsoft Method and this is not just now but even since about a year ago when I and everyone else tried it.

itsme1 said:

Yes, it's obvious we're in a transition phase, and since Microsoft wants to revoke PCA 2011 during this transition phase, future builds will no longer contain the PCA 2011 certificate and will no longer be able to be installed(or work/boot) on computers with the 2011 certificate. This was also mentioned in this thread by the creator of mosby, Akeo. This will be around the 2027 builds.

I mentioned in another thread how to restore 2023 keys when a BIOS/firmware/security key has been reset. This comes from Microsoft on its KB ID: 5025885 page:

Updating Microsoft Secure Boot keys before expiration in June 2026

https://techcommunity.microsoft.com/event/windowsevents/ask-microsoft-anything-secure-boot---may-2026/4513524 UPDATE 4/02: https://support.microsoft.com/en-us/topic/secure-boot-certificate-update-status-in-the-windows-security-app-5ce39986-7dd2-4852-8c21-ef30dd04f046 UPDATE 2/10...

www.elevenforum.com

I saw one of your previous posts here, and I believe you've already used this procedure.

Click to expand...

Yes, this was what I did as last year as in 2024, I did delete and reset the keys and Windows will only boot with Secure Boot disabled but not enabled. The fix was using EaseUS Partition Master's Boot Tools which was in the Sirec WinPE but that WinPE even newer versions will only BSOD with Kernel Check failure so About 10+ days ago when I originally used Mosby and then deleted the keys and reset to defaults, I ran into the same problem and booted with secure boot off to create the USB stick with those instructions and booted using the USB Stick with Secure Boot enabled and it worked fine as all it did was added the Windows 2023 UEFI CA key. It's found in the comment here.

Thanks for putting it into text though since I am sure it will make it easier for others.

Ofcourse now that I think about it, I wonder what did EaseUS Partition Master actually do as they did something to the HDD and it's not related to the secure keys.

Akeo said:

Mosby tells you explicitly that you should keep and copy the MosbyKey files if you want to use the same credentials to sign bootloaders for other machines. So, if you recreate a new Mosby drive, and want your existing signed bootloaders, or sign new ones that work on machines were you already ran Mosby, you should copy the .crt there (only the .crt is actually needed. The .pem and .pfx are used for the actual process of signing the files, but not for the installation of the cert in the DB).

Once you know that SVN stands for Secure Version Number, your screenshot gives you the answer to that.

Code:

Installing DBX:  'Microsoft's 'Secure Version Number' DBX entries [2025.01]'

Mosby always install the most recent elements related to Secure Boot, as they were defined at the time Mosby was compiled. That includes the SVN (and as an asside, that includes SBAT too). Note however that there has been SVN updates since 2025.01, but, if you run Windows of you have a Linux system that takes security seriously and applies DBX updates as they appear, the OS will take care of updating the SVN for you, as SVN is part of regular DBX updates (except Microsoft is once again treating security for people who don't use Windows as a joke, which means that they did not push the public DBX SVN update to their secureboot_ojbjects repo as they should have done the minute they pushed that update in Windows, and I had to, yet again, report that they are doing a lousy job with that (which they still haven't fixed even though I opened that issue 3 weeks ago).

Currently, the SVN installed by Mosby would be 3.0.
The SVN that should be updated by Linux and third party OSes that are Secure Boot aware, and that rely on the Secure Boot objects published by Microsoft would be 5.0.
And the SVN that gets updated by Windows 11is currently 7.0.

But again, if you have a competent OS, it shouldn't matter that the SVN installed by Mosby is a little behind, as the OS should detect and fix that automatically (since it's a run of the mill standard DBX updates, that modern OSes perform for you all the time... provided Microsoft does publish up to date DBX signed packages, which they currently don't).

Oh, and I thought it would become clear at this point that the 2023 certs that get installed as part as running Mobsy are to handle the new 2023 boot managers...

Click to expand...

Thanks for the detailed answer like usual. The reason I was asking is because before even using Mosby, I tried the method from Microsoft so step 1 was the Windows 2023 UEFI Certificate which obviously is gone when the keys were deleted to get into Setup Mode for Mosby.

Step 2 was updating the Boot Manager that is signed with Windows UEFI 2023 CA except in my case, my \EFI\Microsoft\Boot\bootmgfw.efi appears to have the same August 27, 2025 date/timestamp and size as the one from C:\Windows\System32\SecureBootFiles since I am using Windows Beta Insiders Builds and Mosby was last updated in June 2025 so there would be no way the ISO could contain files dated in August 27, 2025 that are signed with a July 25, 2025 signature. So at least in my case, Mosby did not install the boot manager. I did a in-place repair upgrade install after building the latest Beta 26120.6690 ISO and also did step 2 again but the source files are now dated September 27, 2025 but the \EFI\Microsoft\Boot\bootmgfw.efi never changed and still had the August 27, 2025 probably because it was the exact same version.

Yes, lots of acronyms to learn as I just learned what SBAT meant yesterday.

Step 3 is basically adding PCA 2011 to the DBX which is what Mosby -x does.

So then there is Step 4 which says:
"
Apply the SVN update to the firmware.

The Boot Manager deployed in Step 2 has a new self-revocation feature built-in. When the Boot Manager starts to run, it performs a self-check by comparing the Secure Version Number (SVN) that is stored in the firmware, with the SVN built into the Boot Manager. If the Boot Manager SVN is lower than the SVN stored in the firmware, the Boot Manager will refuse to run. This feature prevents an attacker from rolling back the Boot Manager to an older, non-updated version.

In future updates, when a significant security issue is fixed in the Boot Manager, the SVN number will be incremented in both the Boot Manager and the update to the firmware. Both updates will be released in the same cumulative update to make sure that patched devices are protected. Each time the SVN is updated, any bootable media will need to be updated.

Starting with the July 9, 2024, updates, the SVN is being incremented in the Boot Manager and the update to the firmware. The firmware update is optional and can be applied by following this step:

Apply the SVN update to the firmware. To do this, open a Command Prompt window as an Administrator, type each of the following commands separately, and then press Enter:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x200 /f

Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

so it seems Microsoft is saying this is supposed to some kind of SVN update and not just SVN number itself unless they didn't work things correctly since Microsoft's instructions are flawed as while the reg add will work in a Command Prompt, the Start-Scheduled Task does not and will only work in PowerShell. So at least it seems that if what Microsoft said is correct, the Mosby SVN 3.0 because I did step 4 manually would cause a failure since it would be expecting 7.0. From what #4 says, it seems like with SecureBoot enabled, the boot_x64.efi will need to get updated on all media everytime the SVN gets updated.

Microsoft instructions mentions that the systems needs to be July 8, 2025 or later which would be a month after Mosby or UEFI Shell had already been released and since Mosby does not use the internet when it works, it won't be pulling anything after that version of Mosby/UEFI Shell was released either.

What Microsoft never said was if the boot manager and SVN both will automatically get updated in the EFI partition or does one have to do those two steps manually. So even if Mosby was not the most up to date for Step 2 and 4, it's really something that takes less than a minute of copy and pasting to get done manually.

Can someone answer this question. Garlin, would you, please. If for some reason the status of the certificates in my Windows 11 don't change between now and June 2026, will the computer still boot after June 2026? Below is the current status of the certificates in my W11. Thanks.



Bo

FIREMEDIC2700 said:

the question here is can a windows 10 iso be moded to get the 2023 signature like a 11 iso can ?

Click to expand...

Yes, use PowerISO and replace the /efi/boot/bootmgfw.efi with the latest 2023 verstion.

Almighty1 said:

The Secure Keys cannot be added with Secure Boot off from personal experience even with the Microsoft Method and this is not just now but even since about a year ago when I and everyone else tried it.

Click to expand...

MOSBY has you first put UEFI in SETUP mode... or delete all the secure boot keys which does the same thing in my BIOS'. That forces it to boot with Secure Boot off, and boot to the MOSBY USB recovery, whereupon you run MOSBY to repopulate all the keys including the 2023 keys. It may have to either be in SETUP mode or booting with Secure Boot if doing it in the OS (pure speculation on my part).

I haven't tried the Microsoft Method. Can't now because Windows won't create a recovery USB for me. I can create a MOSBY recovery USB at any time using RUFUS.

bo elam said:

Can someone answer this question. Garlin, would you, please. If for some reason the status of the certificates in my Windows 11 don't change between now and June 2026, will the computer still boot after June 2026? Below is the current status of the certificates in my W11. Thanks.

View attachment 147061

Bo

Click to expand...

Please read this answer written by @Akeo :

Almighty, I read it and felt after reading it the answer was YES, but then later I read something else and get confused. So, I would like a simple yes or no. Yes or no.

Thank you

Bo