Serious Discussion [SOLVED] Maxsun Z790M D5: Secure Boot Violation after enabling Secure Boot / restoring factory keys

[Dovahindota]

System: Maxsun MS-Terminator Z790M D5, BIOS H7.8G (06/29/2025), i5-14600K, Windows 11 Pro 25H2 on an NVMe drive (UEFI/GPT, CSM disabled).

I tried to enable Secure Boot to play some games, but I encountered an error I couldn't identify. Since I don't have any IT background, I asked Claude for help, knowing it was developed with expertise in this field. After some trial and error, I found a solution, and I’m posting it here in case it helps others who run into the same issue.

Symptoms

- After enabling Secure Boot and selecting the “Install Default Secure Boot Keys” option, the PC displayed a “Secure Boot Violation” message (appearing twice, extremely quickly, I captured it using time-lapse recording) and returned to the BIOS.
- Disabling Secure Boot, clearing the keys, and selecting “Load Optimized Defaults” had no effect.
- Attempting to use the “Enroll EFI Image” option for the `bootmgfw.efi` file resulted in a failure.
- The “Key Management” section showed: PK = Test (AMI), KEK = 1 key, DB = 2 keys (containing only 2011-era certificates).

Diagnosis
- Windows had already updated its boot manager (`bootmgfw.efi`) to a version signed by the “Windows UEFI CA 2023” certificate authority, as part of Microsoft’s implementation of Secure Boot certificates for 2026. Restoring the factory default keys reset the signature database (DB) to include only the 2011 certificates; consequently, the firmware rejected the newer boot loader. The presence of the `SecureBootRecovery.efi` file in the `EFI\Microsoft\Boot` folder confirmed that the migration had taken place.

Solution (Microsoft Secure Boot Recovery Tool)
On another PC running Windows 11 with recent updates:

- Format a USB drive using the FAT32 file system.
Create an `EFI\BOOT` folder.
- Copy the file `C:\Windows\Boot\EFI\SecureBootRecovery.efi` into this folder and rename it to `bootx64.efi`.
(Optional) Verify that the file is signed by the 2011 CA, which is recognized by the default database (DB):
`Get-PfxCertificate -FilePath "E:\EFI\BOOT\bootx64.efi" | Format-List Subject, Issuer`
The "Issuer" should be "Microsoft Windows Production PCA 2011."

On the affected PC:
5. With Secure Boot enabled (standard mode), boot the system from the USB drive.
6. The tool will display the message “Secure Boot Certificate database successfully updated,” and the system will restart.
7. Remove the USB drive; Windows will boot normally. The `msinfo32` command will show the Secure Boot status as "On."

Notes

There is no need to replace the motherboard or flash the BIOS.
Avoid using the “Restore Factory Keys” or “Install Default Keys” options later, as this will remove the 2023 certificate again. Keep the USB drive as a recovery tool.
The "AMI Test PK" is still present (a known firmware issue referred to as “PKfail”). This does not prevent the system from booting, but a definitive fix would require a BIOS update provided by Maxsun.

Credit: procedure based on the WOSHub guide titled “Invalid Signature Detected: Check Secure Boot Policy [Fix]”

 

[Bot]

System: Maxsun MS-Terminator Z790M D5, BIOS H7.8G (06/29/2025), i5-14600K, Windows 11 Pro 25H2 on an NVMe drive (UEFI/GPT, CSM disabled). I tried to enable Secure Boot to play some games, but I encountered an error I couldn't identify. Since I don't have any IT background, I asked Claude for help, k […]

Hi Dovahindota — the central diagnosis and recovery procedure are correct. Microsoft now documents this exact failure: after Windows switches to a boot manager signed by Windows UEFI CA 2023, restoring firmware defaults on a machine whose factory db contains only the 2011 certificates removes the required trust anchor. The firmware then blocks bootmgfw.efi before Windows starts. Microsoft’s prescribed recovery is the same FAT32 USB procedure using SecureBootRecovery.efi renamed to \EFI\BOOT\bootx64.efi; it adds the needed 2023 certificate back to db (Microsoft’s troubleshooting guide).

A few refinements would make the write-up even more precise:

• The presence of SecureBootRecovery.efi does not, by itself, prove that migration occurred. Microsoft deliberately installs that utility on updated Windows systems so it can be used for recovery. Better evidence is the signature chain of the actual EFI System Partition copy of bootmgfw.efi, the firmware’s db contents, or Microsoft’s Secure Boot servicing status/events.
• msinfo32 showing Secure Boot State: On confirms that enforcement is active, but not that every new KEK, db and dbx update has been applied. Microsoft notes that the recovery utility restores only one of the new certificates, so Windows Update should subsequently be allowed to finish the remaining certificate updates. The relevant TPM-WMI events are documented here.
• “Avoid restoring factory keys” is correct for H7.8G while its factory set remains 2011-only. It need not be a permanent rule if Maxsun eventually releases firmware whose defaults include the 2023 trust anchors. Microsoft’s requirements for newer Windows 11 devices now explicitly include Windows UEFI CA 2023 in db (key-management guidance).
• Using Enroll EFI Image would not be a good durable substitute even if it worked. It may trust only that particular binary or hash, leaving the next boot-manager update to break boot again. Installing the issuing CA is the proper fix.

For checking the recovery file, Get-PfxCertificate displays its signer certificate but does not clearly report whether the file’s signature still validates. This is a stronger check:

$sig = Get-AuthenticodeSignature "E:\EFI\BOOT\bootx64.efi"
$sig.Status
$sig.SignerCertificate | Format-List Subject,Issuer,Thumbprint

The file should be copied only from a fully updated, trusted Windows installation—not downloaded as a loose EFI file from a guide or file-hosting site.

Finally, the AMI Test PK deserves more than a footnote. It does not stop the computer booting, but if that certificate matches one of the leaked AMI test keys involved in PKfail, Secure Boot can report “On” while its root of trust is materially weakened. Binarly explains how possession of the leaked private key can be used to authorize changes to KEK and db (PKfail research). The label alone is suggestive rather than conclusive; the certificate subject and thumbprint should be compared with the published affected keys. The proper remedy is updated Maxsun firmware, not improvised manual key replacement. Maxsun’s page currently still lists H7.8G dated 29 June 2025, with only a microcode change noted and no listed Secure Boot fix (Maxsun support page).

So: no motherboard replacement or BIOS flash was needed to recover this incident, but a future vendor firmware update remains desirable for both the stale factory certificate set and any confirmed test-PK issue.

Sources

• Secure Boot troubleshooting guide | Microsoft Support
• Secure Boot DB and DBX variable update events | Microsoft Support
• learn.microsoft.com
• PKfail/BRLY-2024-005.md at main · binarly-io/Vulnerability-REsearch