Fix “Secure Boot Violation — Invalid Signature Detected”

The fast answer. “Secure Boot Violation — Invalid Signature Detected” means UEFI firmware rejected the bootloader or a boot-time binary because its digital signature doesn’t match any key in the Secure Boot database. The most common fix is to reset the Secure Boot keys to factory defaults in BIOS/UEFI setup (use Reset, not Clear), then rebuild the EFI boot files so they carry valid signatures:

diskpart
list vol
sel vol <EFI-FAT32-vol#>
assign letter=S
exit
bcdboot C:\Windows /s S: /f UEFI

Then re-enable Secure Boot and reboot.

Why this happens

Corrupted or stale Secure Boot keys — a BIOS update, CMOS reset, or a Windows Secure Boot DBX revocation update (e.g. KB5012170) changed the key database so the existing bootloader signature is no longer trusted. This is the most common cause.
Corrupted EFI boot files — bootmgfw.efi or other boot binaries on the EFI System Partition were damaged by an unclean shutdown, failed update, or disk error, and the signature no longer validates.
Outdated BIOS/UEFI firmware — the firmware doesn’t recognize newer Microsoft signing certificates (such as the Windows UEFI CA 2023 certificate), so freshly signed boot files look “invalid” to old firmware.
Third-party or unsigned bootloader — a Linux dual-boot shim, a custom bootloader, or an unsigned driver was added to the boot path without a key enrolled in the Secure Boot database.

Step-by-step fix

Step 1 — Disable Secure Boot temporarily

Power on and press the BIOS/UEFI setup key immediately — F2 on most ASUS, Dell, Acer, and Lenovo machines; Del on many desktops; F10 on HP. Navigate to the Security or Boot tab, find Secure Boot, and set it to Disabled. Save (F10) and reboot. If Windows starts normally, the boot files themselves are intact and the problem is a key mismatch — proceed to Step 2. If Windows still won’t boot, skip to Step 3.

Step 2 — Reset Secure Boot keys to factory defaults

Back in BIOS/UEFI setup, go to the Secure Boot section and look for Key Management (or Secure Boot Keys). Choose Reset to factory defaults or Restore factory keys. Use Reset, not Clear — Reset restores the OEM default keys that match Microsoft’s signing certificates; Clear removes all keys and leaves the database empty, which makes everything unsigned. After the reset, re-enable Secure Boot, save, and reboot. This resolves most cases where a BIOS update or DBX revocation update broke the key/signature pairing.

Step 3 — Rebuild the EFI boot files from WinRE

If Windows won’t boot even with Secure Boot off, the EFI boot files are damaged. Force three failed boots to enter Automatic Repair (power on, hold the power button as the logo appears, repeat three times), or boot from a Windows 10/11 install USB and choose Repair your computer. Go to Troubleshoot → Advanced options → Command Prompt.

First, assign a drive letter to the EFI System Partition (a small FAT32 volume, typically 100–500 MB). Confirm all volume letters — the Windows drive is often not C: inside WinRE:

diskpart
list vol
sel vol <EFI-FAT32-vol#>
assign letter=S
exit

Then rebuild the boot files (replace C: with the actual Windows drive letter shown by list vol):

bcdboot C:\Windows /s S: /f UEFI

You should see “Boot files successfully created.” Reboot and test. If Windows starts, go back into BIOS/UEFI, reset the Secure Boot keys to factory defaults (Step 2), re-enable Secure Boot, and reboot again to confirm the error is gone.

Step 4 — Update the BIOS/UEFI firmware

If the error returns after re-enabling Secure Boot, the firmware may be too old to recognize current Microsoft signing certificates. Go to your motherboard or laptop manufacturer’s support site, download the latest BIOS/UEFI update for your exact model, and follow their update instructions. Keep Secure Boot disabled and the machine plugged into power during the update. After flashing, reset Secure Boot keys to factory defaults again and re-enable Secure Boot.

Step 5 — Run Startup Repair

If the bcdboot rebuild didn’t fix the boot, try Startup Repair from WinRE: Troubleshoot → Advanced options → Startup Repair. This lets Windows detect and fix additional boot-path issues automatically.

Step 6 — Check disk health

If the EFI partition was corrupted, the rest of the disk may have damage too. In WinRE Command Prompt (replace C: with the Windows drive letter):

chkdsk C: /f /r

Then repair system files offline:

sfc /scannow /offbootdir=S:\ /offwindir=C:\Windows

A growing count of bad sectors means the drive is physically failing — back up immediately and replace it.

Data safety: Steps 1–2 change only BIOS settings and don’t touch data. Step 3 (bcdboot) writes only boot files to the EFI partition — it does not modify the Windows or data partitions. Step 4 (BIOS update) carries a small risk of bricking the board if power is lost mid-flash — keep the machine plugged in and do not interrupt the process. chkdsk /r stresses weak sectors, so if the drive is already failing, image it to a known-good external disk first. Never run repairs on the only copy of irreplaceable data.

GRAM tip: The Secure Boot key reset and bcdboot rebuild run from BIOS setup and WinRE, which are already on the broken PC. Once the machine boots again, plug in GRAM — a free portable repair toolkit that runs from a USB inside Windows — to read the event logs for prior boot failures, check the disk’s SMART health, and let its AI agent confirm whether the root cause was stale keys, corrupted boot files, or outdated firmware so the error doesn’t come back.

Download GRAM free See AI pricing →

FAQ

Can I fix this without a second working computer?

Yes. The most common fix — resetting Secure Boot keys to factory defaults — happens entirely inside BIOS/UEFI setup with no media at all. If the boot files also need rebuilding, WinRE lives on the broken PC itself (force three failed boots to trigger Automatic Repair) or you can boot from any Windows install USB. No second computer is required for the repair. (GRAM runs inside Windows rather than from boot media — use it once the machine boots to verify disk health and confirm the root cause.)

Should I use “Reset” or “Clear” for Secure Boot keys?

Always use Reset (also labeled “Restore factory keys” or “Reset to factory defaults”). Reset restores the manufacturer’s default key set, which includes the Microsoft signing certificates Windows needs. Clear removes all keys entirely, leaving the Secure Boot database empty — that makes every bootloader unsigned and can prevent booting altogether.

Will rebuilding the EFI boot files erase my data?

No. bcdboot writes only boot configuration files to the small EFI System Partition (typically 100–500 MB). It does not touch the Windows partition, user files, or any other data. If the data is irreplaceable and the drive is suspect, image it before running any repairs anyway.

Why did this start after a Windows Update?

Microsoft periodically releases Secure Boot DBX (revocation database) updates that blacklist older, vulnerable bootloader signatures. If your EFI boot files were signed with a now-revoked certificate, Secure Boot rejects them. Resetting Secure Boot keys to factory defaults and then rebuilding the EFI boot files with bcdboot replaces the old binaries with freshly signed copies from the current Windows installation.