How to Fix a Secure Boot Violation Error on Your PC
Your computer displays a Secure Boot Violation error at startup and refuses to boot normally. This error means the system firmware detected software that has not been signed with a trusted security key, and Secure Boot is blocking it from loading. The error most commonly appears after installing a new operating system, updating drivers or firmware, changing BIOS settings, or after a failed update corrupts the boot configuration. Understanding what Secure Boot is and why the violation occurred helps you fix the problem correctly rather than just disabling the security feature.
What Secure Boot does
- Secure Boot is a UEFI firmware feature that verifies the digital signature of every piece of software that loads during the boot process — the bootloader, the operating system kernel, and boot-time drivers
- If any boot component has been modified, corrupted, or is not signed with a key that the firmware trusts, Secure Boot blocks it from loading and displays an error. This prevents rootkits and boot-sector malware from running before the operating system starts
- Secure Boot is required for Windows 11 and was optional but enabled by default on most Windows 10 systems sold since 2012
- The security keys are stored in the firmware. Microsoft provides keys that most hardware trusts by default, and Linux distributions use their own signed bootloaders (typically through a Microsoft-signed shim) to work with Secure Boot
Common causes of Secure Boot violations
Dual-booting with Linux
- Installing Linux alongside Windows can trigger Secure Boot violations if the Linux bootloader is not signed with a trusted key. Most major Linux distributions (Ubuntu, Fedora, openSUSE) ship signed bootloaders that work with Secure Boot, but some smaller distributions do not
- If you installed a Linux distribution that does not support Secure Boot, or if GRUB (the Linux bootloader) was updated and the new version is not properly signed, Secure Boot will block it
Modified or corrupted bootloader
- A failed Windows Update, a power loss during a boot configuration change, or disk corruption can modify the Windows bootloader in a way that invalidates its signature
- Third-party disk encryption software, boot managers, or system optimization tools that modify the boot process can also invalidate the signature
Firmware or BIOS update
- A BIOS or UEFI firmware update can reset the Secure Boot key database, changing which keys are trusted. If the update removes or changes a key that your bootloader depends on, a violation occurs
- Some firmware updates change the Secure Boot mode or reset it to default settings, which may not match your previous configuration
Hardware changes
- Replacing the motherboard or moving a boot drive to a different computer can trigger Secure Boot violations because the new hardware has a different set of trusted keys
- Adding certain expansion cards (particularly older cards with option ROMs that are not signed) can trigger violations during POST
How to fix the error
Option 1: Reset Secure Boot keys to default
- Enter BIOS or UEFI settings (press the key shown at startup — typically Del, F2, F10, or F12 depending on your motherboard manufacturer)
- Navigate to the Security or Boot section and find the Secure Boot settings
- Look for an option to Restore Factory Keys, Reset to Setup Mode, or Install Default Secure Boot Keys. This resets the key database to the manufacturer default, which includes the Microsoft keys needed for Windows
- Save and exit BIOS. If the bootloader is a standard Microsoft-signed bootloader, this resolves the violation
Option 2: Repair the Windows bootloader
- If the Windows bootloader is corrupted, you need to rebuild it from a Windows installation or recovery USB drive
- Boot from a Windows installation USB (create one with the Media Creation Tool from Microsoft if you do not have one). Select Repair Your Computer instead of Install
- Navigate to Troubleshoot, then Advanced Options, then Command Prompt
- Run the following commands: bootrec /fixmbr, then bootrec /fixboot, then bootrec /rebuildbcd. These commands repair the Master Boot Record, fix the boot sector, and rebuild the Boot Configuration Data
- If bootrec /fixboot returns Access Denied, run bootsect /nt60 sys first, then retry
- After running the repair commands, restart the computer and check if the Secure Boot violation is resolved
Option 3: Disable Secure Boot (use with caution)
- Disabling Secure Boot removes the signature verification requirement entirely. This resolves the violation but also removes a layer of boot security
- Enter BIOS or UEFI settings. Navigate to the Security or Boot section. Find the Secure Boot option and set it to Disabled
- Save and exit. The system should now boot without checking signatures
- This is appropriate if you are running an unsigned Linux distribution, using legacy hardware with unsigned option ROMs, or if no other fix resolves the issue. However, be aware that Windows 11 requires Secure Boot to be enabled, and disabling it may trigger a watermark or limit certain features
- Some organizations and enterprise environments require Secure Boot to be enabled as part of their security policy. Disabling it may violate compliance requirements
Option 4: Enroll the missing key
- If the violation is caused by a specific signed bootloader whose key is not in the firmware database, you can manually add (enroll) the key
- This is most common with Linux distributions that use a custom signing key. The distribution documentation typically provides the key file and instructions for enrollment
- In the UEFI Secure Boot key management section, you can add keys to the db (authorized signatures database) or the MOK (Machine Owner Key) list
- For MOK enrollment, many Linux distributions use the mokutil tool or the MokManager interface that appears during boot to add the distribution signing key to the trusted key list
Secure Boot and TPM
- Secure Boot and TPM (Trusted Platform Module) are separate but related security features. TPM stores encryption keys and performs hardware-based security operations. Secure Boot verifies boot software signatures
- Windows 11 requires both Secure Boot and TPM 2.0. If you disable Secure Boot to resolve a violation, you may also see Windows activation or feature issues
- BitLocker drive encryption can be affected by Secure Boot changes. If BitLocker is enabled and you modify Secure Boot settings, BitLocker may trigger recovery mode and require your recovery key. Ensure you have your BitLocker recovery key before making Secure Boot changes
Preventing future violations
- When dual-booting, choose Linux distributions that support Secure Boot natively. Ubuntu, Fedora, and openSUSE all support Secure Boot without additional configuration
- Before BIOS updates, document your current Secure Boot settings. After updating, verify the settings are preserved
- Keep a Windows recovery USB drive available. Boot repair from a recovery environment resolves most bootloader corruption issues
- If using BitLocker, always keep your recovery key accessible (printed, saved to a file on another drive, or stored in your Microsoft account) before making any BIOS or boot configuration changes
Need help with Secure Boot errors?
If your computer will not boot due to a Secure Boot violation and you are not comfortable making BIOS changes, or if the error persists after trying the fixes above, LuxuriousComputers Repair can diagnose boot problems, repair the bootloader, configure Secure Boot correctly, and ensure your system boots reliably.