Share via

Secure Boot keys wiped after KB5077181 update

Natalie 20 Reputation points
2026-03-10T16:19:32.44+00:00

Hello,

I am experiencing a critical Secure Boot issue on my ASRock Fatal1ty B450 Gaming K4 motherboard following the KB5077181 update.

During the installation of KB5077181, my system entered a critical boot loop. I was forced to perform a hard reset. After the reset, I was met with a persistent black screen.

I can only boot into my Windows 11 Pro if I set Secure Boot to disabled in BIOS. Whenever I try to enable Secure Boot, I get a black screen and the system fails to boot. In the BIOS under Key Management it shows: Authorized Timestamps: NO KEYS and OsRecovery Signatures: NO KEYS. After entering the system, I uninstalled this update.

What I have tried to fix it (without success):

  • used "Clear Secure Boot Keys"
  • enabled "Factory Key Provision"
  • used "Install Default Secure Boot Keys" then saved and exited

After restarting and re-entering BIOS, the counters are still at 0 keys, and enabling Secure Boot still leads to a black screen. I also tried "Restore DB Defaults", but the keys remain at 0. Please help! Thank you.

Windows for home | Windows 11 | Windows update
0 comments No comments

Answer accepted by question author
  1. Ivan B 107.3K Reputation points Independent Advisor
    2026-03-10T17:14:18.87+00:00

    Hi,

    Did you update the BIOS and the product keys?

    If you performed a factory reset, did you set it to reload the product keys and then revert to setup mode instead of custom mode?

    Thanks

    1 person found this answer helpful.

1 additional answer

Sort by: Most helpful
  1. Q&A Assist
    2026-03-10T16:19:54.8133333+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    The symptoms indicate that the Secure Boot databases (PK/KEK/db/dbx and related OEM-specific stores such as “Authorized Timestamps” and “OsRecovery Signatures”) on the motherboard are effectively empty or corrupted, so enabling Secure Boot leaves the firmware with nothing it trusts to boot and results in a black screen.

    Because all the in‑BIOS restore options (Clear Secure Boot Keys, Factory Key Provision, Install Default Secure Boot Keys, Restore DB Defaults) are not repopulating the key stores, this is now a firmware/OEM key‑provisioning problem, not a Windows problem. Windows and normal software cannot recreate or write the platform keys; only the firmware and OEM tooling can do that.

    Actionable steps based on the available guidance:

    1. Confirm Secure Boot is disabled before any recovery attempts
      Ensure Secure Boot is set to Disabled in BIOS so the system can boot Windows reliably while troubleshooting. Software cannot change Secure Boot state; it must be done in firmware.
    2. Try a full Secure Boot key reset to factory defaults in firmware
      On many systems there is a distinction between “Clear” and “Reset/Install default keys”. The goal is to put the Secure Boot variables back to the manufacturer’s default values, not to leave them empty:
      • In the UEFI/BIOS, locate Secure Boot → Key Management.
      • If there are both options like Clear and Reset/Install default keys/Factory Key Provision, always use the Reset/Install default/Factory option, not just Clear.
      • Save and reboot back into BIOS and check if the key counters (PK/KEK/db/dbx, Authorized Timestamps, OsRecovery Signatures) are now non‑zero.
      The context explicitly notes that using Reset (not Clear) is required to restore manufacturer defaults.
    3. If keys still show as 0 after factory reset attempts, treat it as a firmware/OEM issue
      When the firmware cannot restore its own default keys, the platform is effectively missing the required Secure Boot key set:
      • For Windows 11, the firmware must provide a valid PK, KEK, db, and dbx. Microsoft publishes recommended binaries (PK, KEK, Windows UEFI CA, dbx), but these are intended for OEMs and firmware integrators, not for end‑user manual repair.
      • The FAQ for Secure Boot certificate updates explicitly states that when KEK/db/dbx provisioning fails or is missing, the next step is to work with the OEM and follow the “Windows Secure Boot Key Creation and Management Guidance”.
      In this situation, the only supported path is to contact ASRock support and report that:
      • Secure Boot key stores (including Authorized Timestamps and OsRecovery Signatures) are empty.
      • All built‑in key restore options fail to repopulate them.
      • Secure Boot cannot be enabled without a black screen.
      ASRock may provide:
      • A BIOS update that re‑provisions the Secure Boot databases, or
      • A recovery procedure or tool to reload the OEM’s PK/KEK/db/dbx set.
    4. If ASRock provides a firmware or recovery image, apply it with Secure Boot disabled
      • Keep Secure Boot disabled while flashing or applying any OEM recovery image.
      • After the OEM procedure, re‑enter BIOS and verify that the Secure Boot key stores (PK/KEK/db/dbx and the OEM‑specific counters) now show valid entries.
    5. Re‑enable Secure Boot only after keys are restored
      Once the OEM keys are present again:
      • In BIOS, set Secure Boot to Enabled (or Standard/Windows UEFI mode as appropriate for this board).
      • Save and reboot.
      • If the PC fails to boot after enabling Secure Boot, the official guidance is to disable Secure Boot again and, if necessary, reset BIOS to factory defaults or refresh/reinstall Windows. However, in this case the primary prerequisite is that the firmware key stores are correctly populated by ASRock.
    6. If the system becomes unbootable while experimenting with keys
      If at any point the device becomes unbootable even with Secure Boot disabled, there is a documented recovery path:
      • Turn off Secure Boot in firmware.
      • If supported, reset Secure Boot keys to factory defaults.
      • Try to boot Windows and, if needed, rebuild EFI boot files from an elevated command prompt using mountvol and bcdboot.
      • As a last resort, reinstall Windows from recovery media, then re‑enable Secure Boot once firmware keys are fixed.

    Given that all local key‑reset options already failed and the key counters remain at 0, the next concrete step is to escalate to ASRock support for a firmware‑level Secure Boot key reprovisioning solution. Until that is done, Secure Boot cannot be safely re‑enabled.


    References:

    1 person found this answer helpful.

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.