Platform Key never enrolls, Secure Boot stuck off

[srimel]

Problem: Secure Boot cannot be enabled because the Platform Key never enrolls. In BIOS, Secure Boot shows as toggled on but greyed out, and Platform Key reads "Not Enrolled". Clicking Load HP Factory Default Keys sets Pending Action to "Load HP Factory Default Keys in Next Boot". I then exit via Save Changes and Exit → Yes. On the next entry into BIOS, Pending Action is back to None and Platform Key is still Not Enrolled. This repeats every time.

System:

• OMEN 30L Desktop GT13-1xxx
• Product 328S4AA#ABA
• System board 8876
• BIOS F.24 (AMI)
• Ryzen 7 5800X
• Windows 11 Home 24H2
• AMD fTPM 3.94.2.5

Already tried, with no change:

• Load HP Factory Default Keys, repeatedly — exiting via both the F10 key and Exit → Save Changes and Exit
• Clear All Secure Boot Keys followed by Load HP Factory Default Keys
• The TPM workaround reported to work for others on this board: TPM State Disabled + Clear TPM Yes → full shutdown → Load HP Factory Default Keys + Secure Boot Enabled → full shutdown → TPM State Enabled → full shutdown. Completed in full with a cold boot between each step. TPM came back healthy and enabled; PK still did not enroll.
• Verified Legacy/CSM is not enabled; disk is GPT and the system boots UEFI.

This is blocking me from playing some games that require secure boot in their anti-cheats 😢 
Any help is much appreciated!

Extra context

Read back from Windows in an elevated PowerShell:

Confirm-SecureBootUEFI → False
Get-SecureBootUEFI -Name PK → 0xC0000100, variable is currently undefined
Get-SecureBootUEFI -Name KEK → present, 1506 bytes
Get-SecureBootUEFI -Name db → present, 8868 bytes
Get-SecureBootUEFI -Name dbx → present, 23960 bytes
HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\State → UEFISecureBootEnabled = 0

So KEK, db and dbx all enroll and read back correctly. Only the PK fails to write. The system is effectively stuck in Setup Mode.

[Bill_To]

Greetings @srimel 

Many HP PCs using the 8876 MB are having similar Secure Boot problems.

Check out this HP Forum Thread.

@NonSequitur777 and @BeemerBiker cover this topic in great detail.

Regards

[srimel · Accepted solution]

SOLVED — not a BIOS problem.

Thanks @Bill_To for pointing me to the other 8876 threads. The cause turned out to be elsewhere.

What I found

Microsoft has been migrating Windows to a newer boot manager signing certificate, Windows UEFI CA 2023, as part of the CVE-2023-24932 fix. When Windows makes that switch, it also writes the matching certificate into the BIOS Secure Boot database (db) so the firmware continues to trust Windows.

If the BIOS is reset or re-flashed, the Secure Boot keys revert to HP factory defaults, which contain only the older 2011 certificates. The boot manager is still 2023-signed, but the certificate that validates it is gone.

Enabling Secure Boot then produces "Secure Boot Violation — Invalid signature detected", usually followed by "Boot Device Not Found". The firmware is behaving correctly: it no longer trusts the bootloader.

In my case an HP Support Assistant BIOS package staged in Nov 2025 ran on 2 Sept 2026 and re-flashed F.24 over the F.24 already installed. Same version, and it wiped the certificate.

Why "Load HP Factory Default Keys" makes it worse

That button restores the 2011-only certificate set — the set missing the certificate you need. Each use rebuilds the broken state.

THE FIX

Microsoft ships a recovery tool for this, already present at C:\Windows\Boot\EFI\SecureBootRecovery.efi. Running it once restores the certificate.

All commands are PowerShell, run as Administrator.

Step 1 — Suspend BitLocker (skip if unused)

Save your recovery key off the machine first, from account.microsoft.com/devices/recoverykey:

manage-bde -protectors -disable C: -RebootCount 3

Step 2 — Run the recovery tool. Pick one option.

Option A — USB stick. Microsoft's documented method:
Secure Boot troubleshooting guide

1. Format a USB stick as FAT32
2. Create the folders \EFI\BOOT\ on it
3. Copy C:\Windows\Boot\EFI\SecureBootRecovery.efi into that folder
4. Rename the copy to bootx64.efi
5. Restart, press F9, boot from the USB stick

Option B — no USB. This is the method I used:

bcdedit /copy '{bootmgr}' /d "Secure Boot Recovery"

It prints The entry was successfully copied to {abc12345-...}. Copy that GUID including the curly braces, then run these with your GUID in place of the example:

bcdedit /set '{abc12345-...}' path \EFI\Microsoft\Boot\SecureBootRecovery.efi
bcdedit /set '{fwbootmgr}' bootsequence '{abc12345-...}'

💡Keep the single quotes — PowerShell otherwise treats curly braces as code and the command fails.

Either option: restart normally. The tool runs on its own — a black screen or brief message — then restarts into Windows. Leave Secure Boot off at this stage.

Step 3 — Confirm the certificate is back

[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI -Name db).Bytes).Contains('Windows UEFI CA 2023')

This must return True. My db went from 4375 to 5873 bytes.

If it returns False, the tool did not run — try the other option in Step 2.

Step 4 — Enable Secure Boot

Restart, press F10 for BIOS → Boot Options → Secure Boot → Enabled → F10 → Save Changes and Exit.

⚠️Do not use "Load HP Factory Default Keys" — it deletes the certificate you just restored.

Windows should boot normally. Confirm with:

Confirm-SecureBootUEFI

True means it's done.

Step 5 — Clean up

Resume-BitLocker -MountPoint C:

If you used Option B, remove the temporary boot entry:

bcdedit /delete '{abc12345-...}' /f

Hope this saves someone else the night I just had.

[Bill_To]

Greetings @srimel 

Very nice!

I was aware of the option you used to fix the 2023 security certificate/firmware (PK) mismatch.

Check out this 08-28-26 Forum Thread.

I think your solution is valid. Plus the workaround could help many other Forum members having this problem.

But the Forum had prematurely locked the above thread.

HP Forum Admins quickly lock threads if they believe the thread contains inappropriate content.

So I figured something was amiss. I did not provide a link to the above thread in this thread.

@NonSequitur777 and @Riddle_Decipher would be interested in this workaround.

Regards