A Secure Boot violation means your PC's UEFI firmware has detected a boot component it doesn't trust and has refused to continue. The fix is almost always one of three things: restoring the Secure Boot keys, repairing the EFI boot files, or sorting out a UEFI/Legacy mode mismatch. Most cases take 20 to 30 minutes. We fix this remotely at Vivid Repairs on a near-daily basis.

TL;DR

A Secure Boot violation is caused by mismatched or missing UEFI Secure Boot keys, corrupted EFI boot files, or a Legacy/CSM mode conflict. Disable Secure Boot temporarily, restore factory keys, run Startup Repair or rebuild EFI boot files with bcdboot, then re-enable Secure Boot. If the disk is MBR, convert it with MBR2GPT first.

⏱️ 13 min read ✅ 85% success rate 📅 Updated July 2026

Key Takeaways

A Secure Boot violation blocks your PC from booting when UEFI detects an invalid or unexpected signature on a boot component.
Disabling Secure Boot temporarily is safe as a troubleshooting step, but you should re-enable it once the root cause is fixed.
Restoring Secure Boot keys to factory defaults (not clearing them) fixes the majority of cases after firmware updates or Windows reinstalls.
If your disk is MBR and the firmware expects GPT, you must convert with MBR2GPT before Secure Boot will work.
Have your BitLocker recovery key ready before touching any firmware or boot settings.

At a Glance

Difficulty: Intermediate
Time Required: 20 to 30 mins
Success Rate: 85% of users

What Causes a Secure Boot Violation?

UEFI Secure Boot works by checking every boot component against a database of trusted cryptographic signatures before allowing it to run. If anything in that chain doesn't match, the system stops and throws a Secure Boot violation. It's a security feature doing exactly what it's supposed to do. The problem is that several completely normal things can break that chain of trust without you doing anything obviously wrong.

The most common trigger is a Windows reinstall or repair that writes new EFI boot files without updating the Secure Boot key database. The firmware still has its old expectations, the new boot files don't match, and you get a violation on the next startup. A close second is a BIOS/UEFI firmware update that resets Secure Boot settings or clears stored keys entirely. You didn't change anything, but the firmware did, and now nothing matches.

Then there's the boot mode mismatch. Secure Boot requires UEFI mode and a GPT-partitioned disk. If someone has switched the firmware to Legacy or CSM mode (sometimes this happens automatically when you boot from older USB media), Secure Boot simply cannot function. The violation you see is a symptom of that deeper conflict. Similarly, if the disk itself is MBR-partitioned rather than GPT, Secure Boot won't play nicely no matter what you do in the firmware settings.

Less commonly, third-party tools or non-standard OS loaders introduce unsigned bootloaders. Linux dual-boot setups, older recovery tools, and some disk cloning utilities are all capable of dropping an unsigned component into the EFI partition. The moment Secure Boot checks it, the violation fires. If you've recently installed anything that touches the boot process, that's worth considering as a cause.

Here's a quick summary of what we see most often at Vivid Repairs:

Secure Boot keys cleared or mismatched after a firmware update
Corrupted or replaced EFI boot files after a Windows reinstall or repair
Legacy/CSM mode enabled when the firmware expects UEFI/GPT
MBR disk on a system that needs GPT for Secure Boot to work
Unsigned bootloaders from third-party tools or dual-boot setups

Understanding which one applies to you determines which fix you need. Start with the quick fix below and work down if it doesn't stick.

Secure Boot Violation Quick Fix

This is the first thing to try. It works for the majority of cases where the issue is a key mismatch or a firmware update that reset Secure Boot state. No command line needed.

Disable Secure Boot, Restore Keys, Re-enable Easy

Power off completely.
Don't restart. Hold the power button until the machine is fully off.
Enter BIOS/UEFI setup.
Power back on and immediately press the setup key. This is usually Del, F2, F10, or Esc depending on your motherboard manufacturer. It'll be shown briefly on the POST screen. If you miss it, power off and try again.
Find and disable Secure Boot.
Look under Security, Boot, or Authentication tabs depending on your firmware. Set Secure Boot to Disabled. Save changes (usually F10) and reboot. If Windows starts, great. If not, come back to BIOS and check Boot Mode is set to UEFI, not Legacy.
Re-enter BIOS and restore factory Secure Boot keys.
Once you've confirmed Windows boots with Secure Boot off, go back into BIOS. Find the Secure Boot section and look for an option labelled Restore Factory Keys, Install Default Keys, or Reset to Setup Mode. Choose that. Do NOT choose Clear Keys or Delete Keys, that makes things worse.
Re-enable Secure Boot and save.
With factory keys restored, turn Secure Boot back on. Save and reboot. Windows should now start normally with Secure Boot active.

If Windows boots with Secure Boot enabled after this, you're sorted. No further steps needed.

ASUS notebook? If you have a file called SecureBootRecovery.efi on your system, ASUS has a specific recovery path. Copy it to a FAT32 USB drive, rename it to bootx64.efi, and boot from the USB. This restores the boot path before you re-enable Secure Boot in firmware.

More Secure Boot Violation Fixes

If the quick fix didn't hold, or if Windows still won't start even with Secure Boot disabled, the problem is likely in the EFI boot files themselves or a boot mode conflict. These intermediate fixes cover both.

Run Windows Startup Repair from WinRE Intermediate

Trigger Automatic Repair.
With Secure Boot disabled (from Fix 1), power on and interrupt the boot process three times in a row by holding the power button as soon as you see the Windows logo. On the third attempt, Windows will enter Automatic Repair mode automatically.
Open Startup Repair.
From the Automatic Repair screen, click Advanced Options. Then go to Troubleshoot, Advanced Options, and select Startup Repair. Let it run. It'll scan the boot configuration and EFI partition and attempt to fix what it finds. This takes 5 to 10 minutes.
Reboot and test.
Once Startup Repair finishes, reboot. If Windows loads, go back into BIOS and re-enable Secure Boot with factory keys restored (see Fix 1, steps 4 and 5).
Check UEFI mode in firmware.
If Startup Repair ran but the Secure Boot violation comes back when you re-enable Secure Boot, go into BIOS and confirm Boot Mode is set to UEFI, not Legacy or CSM. CSM (Compatibility Support Module) and Secure Boot are mutually exclusive. Disable CSM if it's on.

Startup Repair fixes corrupted boot configuration data in most cases. If it reports it couldn't fix anything, move to Fix 3.

If you're also dealing with driver issues that appeared around the same time, our Windows driver error troubleshooting guide covers how to roll back or reinstall drivers that can sometimes conflict with boot integrity checks.

If BitLocker is enabled on this machine, have your recovery key ready before proceeding. You'll almost certainly be prompted for it during repair. Find it at your Microsoft account page under Devices. Without it, you risk being locked out of your data.

Advanced Secure Boot Violation Fixes

These are the fixes for when Startup Repair has run and shrugged, or when the underlying issue is a structural problem like an MBR disk on a system that needs GPT. You'll need either Windows installation media on a USB drive or access to WinRE. If you don't have installation media, download the Windows Media Creation Tool from Microsoft on another PC and create a bootable USB.

Rebuild EFI Boot Files with bcdboot Advanced

Boot from Windows installation media or WinRE.
Insert your USB, power on, and boot from it. At the Windows Setup screen, click Repair your computer rather than Install. Go to Troubleshoot, Advanced Options, Command Prompt.
Mount the EFI system partition.
Type mountvol X: /s and press Enter. This mounts the EFI system partition to drive letter X. If X is already in use, pick a different letter like Y or Z.
Rebuild the EFI boot files.
Run the following command: bcdboot C:\Windows /s X: /f UEFI. This copies fresh, correctly signed boot files from your Windows installation into the EFI partition and rebuilds the boot configuration. If Windows is on a different drive letter in your recovery environment, replace C: with the correct letter. You can check by running dir C:\Windows first.
Verify and reboot.
Type exit to close Command Prompt, remove the USB, and reboot. Go into BIOS, re-enable Secure Boot with factory keys (Fix 1, steps 4 and 5), and test. This is the fix that Microsoft's own support documentation points to for EFI boot file corruption, as confirmed in the Microsoft Secure Boot documentation.

If bcdboot runs without errors and reports boot files created successfully, reboot and test with Secure Boot enabled.

Convert MBR to GPT with MBR2GPT Advanced

Confirm the disk is MBR.
In WinRE Command Prompt, run diskpart, then list disk. If the disk shows no asterisk in the GPT column, it's MBR. That's the problem. Exit diskpart with exit.
Run MBR2GPT.
In Command Prompt, run mbr2gpt /convert /disk:0 /allowFullOS. Replace /disk:0 with the correct disk number if your system drive isn't disk 0. MBR2GPT converts the partition table without deleting your data. It takes a minute or two. Microsoft's MBR2GPT documentation covers the full syntax and requirements.
Switch firmware to UEFI mode.
After conversion, reboot into BIOS. Change Boot Mode from Legacy/CSM to UEFI. Disable CSM if it's listed separately. Save and reboot.
Restore Secure Boot keys and re-enable.
Back in BIOS, restore factory Secure Boot keys and enable Secure Boot. Save and reboot. Windows should now start cleanly in UEFI/GPT mode with Secure Boot active.

MBR2GPT is non-destructive but take a backup first if you can. If the conversion fails with an error, do not try to force it. Post the error code and we can advise further.

Reinstall Windows in UEFI/GPT Mode Advanced

Back up your data first.
If you can boot at all with Secure Boot disabled, back up everything important before going further. This step wipes the disk.
Boot from Windows installation media.
Insert your USB and boot from it. At the partition selection screen, delete all existing partitions on the target disk. Windows Setup will create fresh GPT partitions automatically when you install to unallocated space.
Complete the installation.
Install Windows normally. Once complete, go into BIOS, restore Secure Boot factory keys, and enable Secure Boot. A clean UEFI/GPT install will have properly signed boot files and Secure Boot will be happy.

A fresh UEFI/GPT install resolves every structural boot issue. It's a last resort, but it's a proper fix.

If you're not sure whether a recent Windows Update caused the Secure Boot violation, our Windows Update problems guide covers how to identify and roll back problematic updates before they affect boot integrity.

Preventing a Secure Boot Violation

Most Secure Boot violations are avoidable. Here's what actually matters, in order of importance.

1. Keep Secure Boot keys intact. Never clear Secure Boot keys unless you have a very specific reason and a documented recovery path. Restoring to factory defaults is almost always the right move, not clearing. Cleared keys mean no trusted signatures, which means nothing boots.

2. Note your firmware settings before any BIOS update. Firmware updates can reset Secure Boot state silently. Take a photo of your BIOS settings before updating. Takes 30 seconds and saves a lot of grief afterwards.

3. Only boot from trusted, signed media. Unsigned or modified bootloaders are a common trigger. If you're using a USB for recovery or installation, use official media from Microsoft or your device manufacturer. Dodgy third-party recovery tools that haven't been updated in years are a frequent culprit.

4. Install Windows in the right mode. If Secure Boot is enabled, install Windows in UEFI/GPT mode. Don't mix modes. If you're reinstalling and you're not sure, check the firmware first, confirm it's in UEFI mode with CSM disabled, then install.

5. BitLocker users: get your recovery key now. Before you ever touch firmware settings, make sure you have your BitLocker recovery key saved somewhere accessible. Your Microsoft account at account.microsoft.com is the easiest place to check. The Microsoft BitLocker recovery key guide explains exactly where to find it.

And if you're running a dual-boot setup with Linux, make sure your Linux bootloader is signed for Secure Boot. Most modern distros support this, but older setups or custom kernels often don't. That's a common source of Secure Boot violations that people don't immediately connect to Linux.

If you've had repeated boot issues and suspect something deeper is going on with your Windows installation, our Windows boot problems guide covers a wider range of startup failures beyond Secure Boot specifically.

Secure Boot Violation: Summary

A Secure Boot violation is your firmware doing its job, but something in the boot chain has changed and broken the trust relationship. In most cases, disabling Secure Boot temporarily, restoring factory keys, and re-enabling it is enough. If that doesn't work, Startup Repair or a manual EFI rebuild with bcdboot will sort it. If the disk is MBR when it should be GPT, MBR2GPT converts it without data loss. And if everything else fails, a clean UEFI/GPT reinstall is a proper, permanent fix. The key thing is not to panic and not to clear your Secure Boot keys when restore is the right option. Work through the fixes in order and you'll get there.