Solved garlin's PowerShell scripts for updating Secure Boot CA 2023

JamesSmith said:

Can I safely ignore this message?

Considering it is deleting a file every time I boot.

Thanks again.

Click to expand...

The vast majority of Information-level Event Log messages can be safely ignored, yes. Most of them are for system auditing purposes. The only one you really care about for the purposes of this thread is the TPM-WMI 1808 at the top; that one is the success message for getting your CA 2023 keys and boot manager installed.

garlin said:

Can you provide the output of these commands?

Code:

Get-ChildItem "C:\Windows\System32\SecureBootUpdates"
Get-ChildItem "$env:SystemRoot\System32\SecureBootUpdates"
Get-ChildItem "$env:windir\System32\SecureBootUpdates"

dir env:

Click to expand...

Get-ChildItem "C:\Windows\System32\SecureBootUpdates"
Get-ChildItem : Cannot find path 'C:\Windows\System32\SecureBootUpdates' because it does not exist.
At line:1 char:1
+ Get-ChildItem "C:\Windows\System32\SecureBootUpdates"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (C:\Windows\System32\SecureBootUpdates:String) [Get-ChildItem], ItemNotF
oundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand

Get-ChildItem "$env:SystemRoot\System32\SecureBootUpdates"
Get-ChildItem : Cannot find path 'C:\WINDOWS\System32\SecureBootUpdates' because it does not exist.
At line:1 char:1
+ Get-ChildItem "$env:SystemRoot\System32\SecureBootUpdates"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (C:\WINDOWS\System32\SecureBootUpdates:String) [Get-ChildItem], ItemNotF
oundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand

Get-ChildItem "$env:windir\System32\SecureBootUpdates"
Get-ChildItem : Cannot find path 'C:\WINDOWS\System32\SecureBootUpdates' because it does not exist.
At line:1 char:1
+ Get-ChildItem "$env:windir\System32\SecureBootUpdates"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (C:\WINDOWS\System32\SecureBootUpdates:String) [Get-ChildItem], ItemNotF
oundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand

Attached txt file is the result of dir env:
Regards
SaliesBuzz

SaliesBuzz said:

Get-ChildItem "C:\Windows\System32\SecureBootUpdates"
Get-ChildItem : Cannot find path 'C:\Windows\System32\SecureBootUpdates' because it does not exist.

Click to expand...

This part stumps me, because it's an absolute path with no variable substitution. It's like there's a permission problem reading the folder, even though you can see it from File Explorer, and probably "cd" into the directory. Is PowerShell 5.0 or 7.x? (it should say when you're opening PS).

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

BIOS Firmware
-------------
ASUS System Product Name
Version: 3827
Date: 2026-02-06

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
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
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 7.0
EFI_CERT_SHA256_GUID Signatures: 437

EFI Files
---------
Disk 0: Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.
bootmgfw.efi File version: 26100.30227

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

Disk 0: SkuSiPolicy.p7b (for VBS) is CURRENT.

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

SUCCESS: NO UPDATES ARE REQUIRED.

=============================================================
This is ok I think now my next machine:
-----==========================================================

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

BIOS Firmware
-------------
Gigabyte Technology Co. B650 AORUS ELITE AX V2
Version: F39
Date: 2026-01-15

Factory Default UEFI PK Cert
----------------------------
(NONE)

UEFI PK Cert
------------
(NONE)

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

UEFI KEK Certs
--------------
Microsoft Corporation KEK CA 2011
Microsoft Corporation KEK 2K CA 2023

Factory Default UEFI DB Certs
-----------------------------
Microsoft Corporation UEFI CA 2011
Microsoft Windows Production PCA 2011
Windows UEFI CA 2023

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

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

UEFI DBX Certs
--------------
Microsoft Windows Production PCA 2011
Windows BootMgr SVN 7.0
EFI_CERT_SHA256_GUID Signatures: 487

EFI Files
---------
Disk 0: Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.
bootmgfw.efi File version: 26100.30227

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

Disk 0: SkuSiPolicy.p7b (for VBS) is CURRENT.

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

SUCCESS: NO UPDATES ARE REQUIRED.

The Gigabyte does not show any "SW Key Certificate" stuf, is that normal as I updates both systems with the latest BIOS ???
I used the [Check_UEFI-CA2023.ps1 -verbose]
Thank you for your great job !

Klaver7 said:

BIOS Firmware
-------------
ASUS System Product Name
Version: 3827
Date: 2026-02-06

Click to expand...

Klaver7 said:

SUCCESS: NO UPDATES ARE REQUIRED.

Click to expand...

ASUS is good.

Klaver7 said:

BIOS Firmware
-------------
Gigabyte Technology Co. B650 AORUS ELITE AX V2
Version: F39
Date: 2026-01-15

Factory Default UEFI PK Cert
----------------------------
(NONE)

UEFI PK Cert
------------
(NONE)

Click to expand...

I believe you have the same bug as reported by @JamesSmith, Gigabyte's PK cert is missing any labels.

That's the way Gigabyte issued it. So the script mistakenly believes it's empty, I have a pending fix to copy whatever canonical name (CN=) exists in the PK's Subject line.

Klaver7 said:

SUCCESS: NO UPDATES ARE REQUIRED.

The Gigabyte does not show any "SW Key Certificate" stuf, is that normal as I updates both systems with the latest BIOS ???
I used the [Check_UEFI-CA2023.ps1 -verbose]
Thank you for your great job !

Click to expand...

Gigabyte is otherwise good.

garlin said:

This part stumps me, because it's an absolute path with no variable substitution. It's like there's a permission problem reading the folder, even though you can see it from File Explorer, and probably "cd" into the directory. Is PowerShell 5.0 or 7.x? (it should say when you're opening PS).

Click to expand...

Powershell Version:
Name : ConsoleHost
Version : 5.1.26100.7920
InstanceId : e1fc2076-9fb4-401d-b584-2cdaec33ec58
UI : System.Management.Automation.Internal.Host.InternalHostUserInterface
CurrentCulture : en-GB
CurrentUICulture : en-GB
PrivateData : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy
DebuggerEnabled : True
IsRunspacePushed : False
Runspace : System.Management.Automation.Runspaces.LocalRunspace

PS C:\Users\Buzz> $PSVersionTable.PSVersion

Major Minor Build Revision
----- ----- ----- --------
5 1 26100 7920

This is the latest Bios update from Gigabyte

• This BIOS update addresses critical security vulnerabilities (CVE-2025-7026, CVE-2025-7027, CVE-2025-7029) identified by BRLY.
• GIGABYTE strongly recommends all users update their system BIOS immediately to protect against potential security risks.

Does this update have anything to do with these 2023 KEYS ?

man00 said:

This is the latest Bios update from Gigabyte

• This BIOS update addresses critical security vulnerabilities (CVE-2025-7026, CVE-2025-7027, CVE-2025-7029) identified by BRLY.
• GIGABYTE strongly recommends all users update their system BIOS immediately to protect against potential security risks.

Does this update have anything to do with these 2023 KEYS ?

Click to expand...

If your PC's have been getting BIOS updates for the past 2-3 years, the Secure Boot certs should have been added in earlier releases.

MS gave all the OEM's a deadline of last year to get it out the door.

SaliesBuzz said:

Powershell Version:
Name : ConsoleHost
Version : 5.1.26100.7920

Click to expand...

I normally test my scripts in both PS 5.1 & 7. Can you try running it from PS7, and see if there's a difference? Wondering if it's some Windows environment issue, and nothing to do with PS. "Doesn't exist" sometimes really means "PS can't open the folder for other reasons".

garlin said:

I normally test my scripts in both PS 5.1 & 7. Can you try running it from PS7, and see if there's a difference? Wondering if it's some Windows environment issue, and nothing to do with PS. "Doesn't exist" sometimes really means "PS can't open the folder for other reasons".

Click to expand...

Even more bizarre!
I have run the relevant commands in Powershell again and now get:

PS C:\Users\Buzz> $PSVersionTable.PSVersion
Major Minor Build Revision
----- ----- ----- --------
5 1 26100 7920

powershell -ExecutionPolicy Bypass -File "C:\Buzz\SecureBoot\SecureBoot-CA-2023-Updates\Check_DBXUpdate.bin.ps1" -verbose
SUCCESS: Matched 431/431 EFI signatures from "dbxupdate.bin"
FAILED: Missing 3/3 SVN signatures from "DBXUpdate2024.bin"
Missing [01612B139DD5598843AB1C185C3CB2EB92000002000000000000000000000000] bootmgfw.efi SVN 2.0
Missing [019D2EF8E827E15841A4884C18ABE2F284000002000000000000000000000000] cdboot.efi SVN 2.0
Missing [01C2CA99C9FE7F6F4981279E2A8A535976000002000000000000000000000000] wdsmgfw.efi SVN 2.0

FAILED: Missing 3/3 SVN signatures from "DBXUpdateSVN.bin"
Missing [01612B139DD5598843AB1C185C3CB2EB92000007000000000000000000000000] bootmgfw.efi SVN 7.0
Missing [019D2EF8E827E15841A4884C18ABE2F284000003000000000000000000000000] cdboot.efi SVN 3.0
Missing [01C2CA99C9FE7F6F4981279E2A8A535976000003000000000000000000000000] wdsmgfw.efi SVN 3.0

PS C:\Users\Buzz> Get-ChildItem "C:\Windows\System32\SecureBootUpdates"

Directory: C:\Windows\System32\SecureBootUpdates


Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 06/03/2026 14:44 82891997 BucketConfidenceData.cab
-a---- 01/04/2024 09:22 3 dbupdate.bin
-a---- 01/04/2024 09:22 4832 dbupdate2024.bin
-a---- 14/05/2025 07:51 4829 DBUpdate3P2023.bin
-a---- 14/05/2025 07:51 4840 DBUpdateOROM2023.bin
-a---- 11/01/2026 15:42 24053 dbxupdate.bin
-a---- 01/04/2024 09:22 5052 DBXUpdate2024.bin
-a---- 03/10/2025 16:18 3509 DBXUpdateSVN.bin
-a---- 01/03/2026 17:04 885128 KEKUpdateCombined.bin
-a---- 03/12/2024 06:23 45 SbatLevel.txt
-a---- 24/01/2026 13:07 6776 SKUSiPolicy.P7b

As you can see above this all under Powershell 5.

The only change from yesterday is that Windows has installed the March Monthly updates:

I don't know why this has made a difference, but it obviously has. One of these updates does refer to Security Certificates and I can see that the directory was accessed on the 12/03/2026 at 01:07, bur nothing appears to have written to any file in there!

For Reference, I have installed Powershell 7 as well, and the results under that were:
PowerShell 7.5.4
PS C:\Users\Buzz> powershell -ExecutionPolicy Bypass -File "C:\Buzz\SecureBoot\SecureBoot-CA-2023-Updates\Check_DBXUpdate.bin.ps1" -verbose
SUCCESS: Matched 431/431 EFI signatures from "dbxupdate.bin"
FAILED: Missing 3/3 SVN signatures from "DBXUpdate2024.bin"
Missing [01612B139DD5598843AB1C185C3CB2EB92000002000000000000000000000000] bootmgfw.efi SVN 2.0
Missing [019D2EF8E827E15841A4884C18ABE2F284000002000000000000000000000000] cdboot.efi SVN 2.0
Missing [01C2CA99C9FE7F6F4981279E2A8A535976000002000000000000000000000000] wdsmgfw.efi SVN 2.0

FAILED: Missing 3/3 SVN signatures from "DBXUpdateSVN.bin"
Missing [01612B139DD5598843AB1C185C3CB2EB92000007000000000000000000000000] bootmgfw.efi SVN 7.0
Missing [019D2EF8E827E15841A4884C18ABE2F284000003000000000000000000000000] cdboot.efi SVN 3.0
Missing [01C2CA99C9FE7F6F4981279E2A8A535976000003000000000000000000000000] wdsmgfw.efi SVN 3.0
So, basically the same!

Need I be concerned by the missing SVN stuff, or is this to do with Virtualization?

Regards
SaliesBuzz

I wonder if they pushed out a bug fix for PS 5, since the build number increased to .7920.

The reason you're missing the SVN's is because you haven't revoked the PCA 2011 cert. When the cert gets revoked, the SVN first goes to 2.0. Then the SVN update is applied which bumps it up to 7.0.

And it looks like Feb 2026's Preview added some PowerShell updates:

• [Secure Boot]
  • With this update, Windows quality updates include additional high confidence device targeting data, increasing coverage of devices eligible to automatically receive new Secure Boot certificates. Devices receive the new certificates only after demonstrating sufficient successful update signals, maintaining a controlled and phased rollout.
    
    
  • This update introduces two new PowerShell features to help you manage the ongoing Secure Boot key rollout. The Get-SecureBootUEFI cmdlet now supports the -Decoded option, which displays Secure Boot keys and certificates in a readable format. The Get-SecureBootSVN cmdlet lets you check the Secure Boot Security Version Number (SVN) of your device’s UEFI firmware and bootloader, and report whether the device follows the latest Secure Boot policy.

Click to expand...

garlin said:

ASUS is good.


I believe you have the same bug as reported by @JamesSmith, Gigabyte's PK cert is missing any labels.

That's the way Gigabyte issued it. So the script mistakenly believes it's empty, I have a pending fix to copy whatever canonical name (CN=) exists in the PK's Subject line.


Gigabyte is otherwise good.

Click to expand...

Could Klaver7 run the custom script that you wrote for my Gigabyte Bios?

Or will everyone's Gigabyte Bios be different?

JamesSmith said:

Could Klaver7 run the custom script that you wrote for my Gigabyte Bios?

Or will everyone's Gigabyte Bios be different?

Click to expand...

Here I ran the custom scrip:
===========
PS C:\WINDOWS\system32> powershell -nop -ep bypass -f C:\Temp\Check_UEFI-CA2023.ps1 -verbose
Windows 11 24H2 (26100.8037)

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

BIOS Firmware
-------------
Gigabyte Technology Co. B650 AORUS ELITE AX V2
Version: F39
Date: 2026-01-15

Factory Default UEFI PK Cert
----------------------------
GIGABYTE

UEFI PK Cert
------------
GIGABYTE

Factory Default UEFI KEK Certs
------------------------------
Microsoft Corporation KEK CA 2011
Microsoft Corporation KEK 2K CA 2023
GIGABYTE

UEFI KEK Certs
--------------
Microsoft Corporation KEK CA 2011
Microsoft Corporation KEK 2K CA 2023
GIGABYTE

Factory Default UEFI DB Certs
-----------------------------
Microsoft Corporation UEFI CA 2011
Microsoft Windows Production PCA 2011
Windows UEFI CA 2023
GIGABYTE
GIGABYTE

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
GIGABYTE
GIGABYTE

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

UEFI DBX Certs
--------------
Microsoft Windows Production PCA 2011
Windows BootMgr SVN 7.0
EFI_CERT_SHA256_GUID Signatures: 487

EFI Files
---------
Disk 0: Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.
bootmgfw.efi File version: 26100.30227

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

Disk 0: SkuSiPolicy.p7b version: 33284.17421.33440.335 is CURRENT.

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

SUCCESS: NO UPDATES ARE REQUIRED.

PS C:\WINDOWS\system32>
===================
--------

Same outcome as you have with Gigabyte, nothing to worry about I think. Gigabye being lazy ?

Klaver7 said:

Here I ran the custom scrip:
===========
PS C:\WINDOWS\system32> powershell -nop -ep bypass -f C:\Temp\Check_UEFI-CA2023.ps1 -verbose
Windows 11 24H2 (26100.8037)

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

BIOS Firmware
-------------
Gigabyte Technology Co. B650 AORUS ELITE AX V2
Version: F39
Date: 2026-01-15

Factory Default UEFI PK Cert
----------------------------
GIGABYTE

UEFI PK Cert
------------
GIGABYTE

Factory Default UEFI KEK Certs
------------------------------
Microsoft Corporation KEK CA 2011
Microsoft Corporation KEK 2K CA 2023
GIGABYTE

UEFI KEK Certs
--------------
Microsoft Corporation KEK CA 2011
Microsoft Corporation KEK 2K CA 2023
GIGABYTE

Factory Default UEFI DB Certs
-----------------------------
Microsoft Corporation UEFI CA 2011
Microsoft Windows Production PCA 2011
Windows UEFI CA 2023
GIGABYTE
GIGABYTE

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
GIGABYTE
GIGABYTE

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

UEFI DBX Certs
--------------
Microsoft Windows Production PCA 2011
Windows BootMgr SVN 7.0
EFI_CERT_SHA256_GUID Signatures: 487

EFI Files
---------
Disk 0: Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.
bootmgfw.efi File version: 26100.30227

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

Disk 0: SkuSiPolicy.p7b version: 33284.17421.33440.335 is CURRENT.

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

SUCCESS: NO UPDATES ARE REQUIRED.

PS C:\WINDOWS\system32>
===================
--------

Same outcome as you have with Gigabyte, nothing to worry about I think. Gigabye being lazy ?

Click to expand...

We are both fine. Garlin troubleshooted this with me for a few hours. Both of our outputs match so that's good news.

I pretty sure this applies to all of Gigabyte's motherboards.

As time goes by I am sure we will see more of this.

Quick question for @JamesSmith: have you installed the March 2026 Windows update?

There's a new PS feature just added to the Get-SecureBootUEFI command which converts the certs back into a human form. Can you run this to confirm what the actual Subject line for all those mysterious GIGABYTE certs?


My suspicion is Gigabyte is publishing "CN=GIGABYTE" and nothing else on the Subject line.

garlin said:

I wonder if they pushed out a bug fix for PS 5, since the build number increased to .7920.

The reason you're missing the SVN's is because you haven't revoked the PCA 2011 cert. When the cert gets revoked, the SVN first goes to 2.0. Then the SVN update is applied which bumps it up to 7.0.

And it looks like Feb 2026's Preview added some PowerShell updates:

Click to expand...

I presume that if:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbdefault).bytes) -match 'Windows UEFI CA 2023'
returns:
False
This is because the BIOS is non compliant and that, in the event of power failure and the CMOS battery failing, reloading the BIOS from defaults would mean having to run the Update 2023 scripts again?
In that event, I presume that Secure Boot would have to be temporarily disabled?
Regards
SaliesBuzz

Morning @garlin,

The latest Windows Update caused my system to go into reboots - after booting, WU would say my system needed to reboot due to the new Update to 8037, I would reboot and it would do the same -- after ten such reboots I decided to reformat with an older ISO (it was all I had available at the time) and then upgrade from a clean install.

I was able to complete this after disabling Secure Boot first. Once the system was fully updated to 26200.8037 I was able to turn back on Secure Boot and it is using it according to both MSINFO32 and HWInfo.

My mobo is an MSI MS-7D78 running the latest non-beta bios (1.I0 dated 03/11/2025).

Ran the System Text Encoding command line I've seen and it came back TRUE

Ran your Check-UEFI script from your GitHub using Verbose (Release v2026.01.18) and this is what it shows:


According to my Registry, the Confidence Level is listed as "Under Observation", UEFICA2023Status is "Not Started", and WindowsUEFI2023Capable is "2"

Ran the two new PS commands introduced with 8037 and here's what they say:


With all the changes you've made to your script since then and my recent system issues, I'm not sure how to proceed. There are beta bioses available for my mobo but I'm a little reluctant to run them because their listed as beta -- I would really be put out if my system stopped booting....

Any advice on how to proceed would be greatly appreciated.

SaliesBuzz said:

I presume that if:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbdefault).bytes) -match 'Windows UEFI CA 2023'
returns:
False
This is because the BIOS is non compliant and that, in the event of power failure and the CMOS battery failing, reloading the BIOS from defaults would mean having to run the Update 2023 scripts again?
In that event, I presume that Secure Boot would have to be temporarily disabled?

Click to expand...

No. All that means is the Windows UEFI CA 2023 hasn't been added to DB. You can't make any conclusions on a standalone check of just one setting. What needs to happen is all the different cert types need to be installed together.

Here's an analogy to explain the problem:

You're planning to fly overseas to another country. In order to accomplish that, you need an airline ticket and usually a visa from the other country. To get a visa, the other country needs your passport info.

It's possible to book the airline ticket without having a visa. The airline leaves that problem to the departure or arrivals staff at the different airports.
It's possible to request a visa without having an airline ticket. The other country leaves that problem to you.
It's possible you have a ticket and visa, but forget to show up with your passport.

In order to actually arrive in the other country, all the following things must be in place: booked ticket, approved visa, possession of a passport.

The Secure Boot update process is similar, all the pieces must be done. But you can skip around, and partially update some settings. If you have not revoked anything, then you're only adding new settings which don't prevent Secure Boot from booting. The main point of having a good script is most folks are not informed enough on how Secure Boot works to make good conclusions by looking at different settings.

The check script will highlight if your current boot file, as your UEFI stands right now, is ALLOWED or BANNED. If it's BANNED, then you have to fix the settings, or temporarily disable Secure Boot.

Taliseian said:

UEFI DB Certs
-------------
Microsoft Corporation UEFI CA 2011
Microsoft Windows Production PCA 2011
Microsoft UEFI CA 2023
Windows UEFI CA 2023
MSI SHIP DB

Click to expand...

You're only missing the Option ROM (which might be needed for some older graphics cards). But since you booted fine, it can be added later.

Taliseian said:

UEFI DBX Certs
--------------
(NONE)
Windows BootMgr SVN is MISSING.
EFI_CERT_SHA256_GUID Signatures: 371

EFI Files
---------
Disk 0: Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.
bootmgfw.efi File version: 26100.30227

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

Disk 0: SkuSiPolicy.p7b (for VBS) is NOT PRESENT.

Click to expand...

Right now, PCA 2011 is not revoked. You have the option to use either old or new boot files, and your Windows is using the new file.

Taliseian said:

According to my Registry, the Confidence Level is listed as "Under Observation", UEFICA2023Status is "Not Started", and WindowsUEFI2023Capable is "2"

Click to expand...

MS is grouping everyone's PC into different confidence buckets based on your exact motherboard and BIOS version. They're gathering telemetry data to figure out how often Windows is successful in updating the certs. For a popular PC model, those statistics are easier to collect. Based on the success/failure rate, they get a confidence level in pushing the updates to everyone who owns the same PC/BIOS.

Less popular PC's will take longer to decide if it's safe for MS to force an update. "Under Observation" means they don't have enough examples to know. Doesn't mean updates won't work, it's just the automated push doesn't want to make a stupid mistake at this point. (Maybe your BIOS has a fatal flaw and it bricks the PC).

Taliseian said:

With all the changes you've made to your script since then and my recent system issues, I'm not sure how to proceed. There are beta bioses available for my mobo but I'm a little reluctant to run them because their listed as beta -- I would really be put out if my system stopped booting....

Any advice on how to proceed would be greatly appreciated.

Click to expand...

I would say MSI's done a fairly good job on their firmwares, compared to how it's gone for ASUS or some HP models. Since my script suggested you could "DO NOTHING" means it checked the MS KEK database, and your MSI's PK on the supported list.

Most of the Secure Boot updates would have been added to firmware in the past 2 years. MS gave the OEM's a deadline of last year to get the changes added to their BIOS'es.

The core of the script hasn't changed much since it's October release. Most of the tweaks are to handle weird differences in PC models, since I only have the PC's that I own in front of me.

Thanks @garlin for the response.

Until MSI releases a non-beta bios and it's been clear for at least a week or so, I'll just do nothing and wait.