Verification Failed (0x1A) Security Violation
Fix the Secure Boot shim error on a Ventoy or multiboot USB - what Shim UEFI key management means, how to enroll the MOK, and how to build a plain FAT32 installer stick instead.
If a bootable USB stops at "Verification failed: (0x1A) Security Violation", then offers Shim UEFI key management and Perform MOK management, the stick is running a third-party boot loader whose signing key your firmware does not yet trust. This is not a Windows error, not a bluescreen, and nothing to do with how the image was built - the failure happens before Windows setup is ever reached. The fix is a one-time key enrollment, and this guide covers it along with the two ways to avoid the loader entirely.
What the Screens Mean
Three screens appear in sequence, all on a blue background, which is why they get mistaken for a bluescreen:
- "ERROR - Verification failed: (0x1A) Security Violation" -
0x1AisEFI_SECURITY_VIOLATION(status 26). - "Shim UEFI key management - Press any key to perform MOK management" - the fallback interface for enrolling trust.
- "Perform MOK management" with Continue boot, Enroll key from disk, and Enroll hash from disk.
shim.efi is a small Microsoft-signed loader used by Linux distributions and by multiboot USB tools such as Ventoy. Its job is to load the next stage and verify it against three sources of trust: the firmware db, shim's own built-in vendor certificate, and any Machine Owner Key enrolled on that machine. When none of the three match, shim refuses and hands control to MOK management.
Reaching the MOK screen is itself useful information: it proves shim loaded and that Secure Boot accepted its signer, normally the Microsoft 3rd-party UEFI CA. Only the next stage in the chain is untrusted, which narrows the problem to a missing key enrollment.
Why It Happens
A Machine Owner Key lives in the motherboard's firmware NVRAM, not on the USB stick. The stick only carries the certificate file you enroll from. So the enrollment is per-machine and one-time, and it goes missing in the ordinary ways:
- The drive has never been booted on this machine before
- Secure Boot was previously disabled, so shim never enforced anything and every image booted; enabling Secure Boot starts the enforcement
- Firmware was updated, reset to defaults, or had its Secure Boot keys restored
- The loader was reinstalled onto the drive with a newly generated key
Because the failure is in the loader rather than the image, every ISO on that drive fails the same way, including ones that booted fine before. A working image is not evidence that the image is at fault when it later stops booting.
Fix It: Enroll the Key
You are already on the right screen when the error appears. For Ventoy:
- Press a key at the Shim UEFI key management screen.
- Choose Enroll key from disk.
- Select the VTOYEFI partition, then
ENROLL_THIS_KEY_IN_MOKMANAGER.cer. - Choose Continue, then Yes at "Enroll the key(s)?".
- Reboot. The drive boots normally from then on, with Secure Boot left enabled.
Other shim-based loaders follow the same flow with their own certificate file. Enroll key is preferable to Enroll hash: a hash trusts one exact binary and has to be redone after the loader updates, while a key survives updates.
Ventoy ships the same certificate to every install rather than generating one per drive, so a machine that trusts it will boot anyone else's Ventoy stick too. On machines where physical access matters, use one of the alternatives below instead of enrolling.
Alternative: Disable Secure Boot For the Install
Turn Secure Boot off in firmware setup, install, then turn it back on. Nothing is enrolled and nothing is left trusted afterwards, which makes this the least invasive option for a one-off install. It is a stopgap rather than a destination if you use the drive regularly.
Alternative: A Plain FAT32 Installer Stick
Dropping the third-party loader removes the problem at the root. A USB stick formatted FAT32 with the ISO contents copied onto it is booted directly by firmware through Microsoft-signed bootmgfw.efi: no shim, no MOK, no enrollment, Secure Boot left on throughout.
Keep Every File Under 4 GB
FAT32 cannot hold a file of 4 GB or larger, and a modern install.wim often exceeds that. In NTLite, pick Spanned, split (SWM) in the image format group before applying - see Apply for where that option sits. The default part size is 4000 MB, already FAT32-safe, so there is no number to work out. The result is install.swm plus install2.swm, which Windows Setup reads natively with no extra steps.
Prepare the Stick With No Extra Tools
Microsoft documents the procedure in Create a Bootable USB Flash Drive. In an administrative Command Prompt, run diskpart, then list disk, select disk X, clean, create part pri, select part 1, format fs=fat32 quick, active, exit. Then copy the ISO contents to the root of the stick.
The main step list in that article formats NTFS. For UEFI you want the FAT32 variant called out in the note underneath it, format fs=fat32 quick, which is what the sequence above uses.
If the MOK Screen Never Appears
Seeing only the error, with no Shim UEFI key management screen behind it, means shim itself was rejected rather than its next stage. The usual cause is firmware that trusts only the Windows UEFI CA with the Microsoft 3rd-party UEFI CA disabled, since shim is signed by that third-party CA. Enable it in firmware setup if the option exists. If it does not, disable Secure Boot, boot the drive, run MokManager.efi from the loader's EFI partition to enroll the key, then re-enable Secure Boot.
Not This Error?
If the message names Windows Boot Manager rather than shim, mentions a security validation or internal error, or the machine bugchecks with 0xC0430001, you are looking at the Secure Boot 2011-to-2023 certificate migration instead. That is firmware refusing Windows' own boot manager, and it has a different fix. See Windows Boot Manager Security Validation or Internal Error.
One overlap is worth knowing. If you enable Update boot manager in NTLite, the media carries a 2023-signed boot manager, which only boots on firmware that already trusts the Windows UEFI CA 2023. That produces a Secure Boot rejection too, but from the firmware rather than from shim, and the migration guide covers it.
Frequently Asked Questions
Is this the same as the Secure Boot 2023 certificate migration?
No. The 2011-to-2023 migration is about firmware refusing Windows’ own boot manager, and it shows as "Windows Boot Manager - the boot manager encountered a security validation or internal error" or stop code 0xC0430001. The 0x1A screen with Shim UEFI key management comes from a third-party USB loader such as Ventoy, and it fails before Windows setup is ever reached. The two look similar because both are Secure Boot refusing to boot an installer, but the cause and the fix are unrelated.
What does 0x1A mean?
It is EFI_SECURITY_VIOLATION, status code 26. Shim prints it when the binary it was asked to load next is not signed by anything shim trusts: not the firmware db, not shim’s built-in vendor certificate, and not an enrolled Machine Owner Key.
Do I have to enroll the key on every PC?
Yes. A Machine Owner Key is stored in that machine’s firmware NVRAM, not on the USB stick. The stick only carries the certificate file you enroll from. Each new machine needs the one-time enrollment, and clearing or updating firmware can drop an existing one.
The MOK screen never appears, I only get the error. What now?
Then shim itself was rejected, which is a different problem. Some firmware trusts only the Windows UEFI CA and has the Microsoft 3rd-party UEFI CA disabled, and shim is signed by that third-party CA. Enable the third-party CA in firmware setup if the option exists, or disable Secure Boot, boot the drive, and run MokManager.efi directly to enroll before re-enabling.
Is enrolling the key safe?
It is a deliberate trust decision. Ventoy ships the same certificate to every install rather than generating one per drive, so a machine that trusts it will boot anyone else’s Ventoy stick too. The loader also chains arbitrary boot images by design, which is the point of the tool and also the reason the chain of trust stops there. On a machine where physical access is part of your threat model, prefer a plain FAT32 installer stick instead.
Does building the image in NTLite change any of this?
No. This failure happens in the USB loader before any image content is read, which is why a previously working ISO on the same stick fails identically once Secure Boot starts enforcing. Nothing in a preset, component removal, or update integration affects it. NTLite is only involved if you choose the plain FAT32 route, where the Spanned, split (SWM) image format keeps every file under the 4 GB FAT32 limit.
Next Steps
If you take the FAT32 route, save the SWM format choice into a preset so every build comes out installer-ready. Download NTLite to get started, and see the Apply reference page for the image format and ISO creation steps.