The Ventoy drive works on your PC and dies on the next one with a blue screen and a security violation. Nothing is broken and the drive is not infected - the PC is doing exactly what Secure Boot is for. Two ways through, and one honest reason some people skip Ventoy for locked-down machines.
Verification failed: (0x1A) Security Violation is the most misunderstood screen in the Ventoy world. Secure Boot only starts bootloaders signed by keys the firmware trusts. Ventoy's bootloader is signed - but with a key your PC does not know yet, so the firmware refuses it. Rufus-written Windows drives rarely show this screen because they ride the standard Microsoft-signed boot path. For Ventoy, the fix is a one-time introduction between the PC and the key, and it takes about a minute per machine.
The full enrolment is demonstrated click by click in the Ventoy Complete Guide video on this channel - watch that section before doing it the first time if the firmware screens look unfamiliar.
The blunt alternative: enter the BIOS or UEFI setup, set Secure Boot to Disabled, save and boot. It always works, and for your own machine it is a legitimate choice. Two cautions keep it honest. On a PC you do not own - a client's, an office machine - changing firmware security settings without the owner's knowledge is not your call. And if the drive is BitLocker-encrypted, changing Secure Boot state can trigger the recovery-key demand at the next Windows start; have that key located before you touch the setting, not after.
This is the comparison point the error teaches. A Rufus Windows USB boots through the ordinary Microsoft-signed chain, including its small signed UEFI NTFS stage when the image has oversized files - so the firmware's trust check passes with no enrolment, no BIOS visit, nothing. On a locked-down office laptop where you cannot change firmware settings and should not enrol foreign keys, that difference is decisive. It is the practical reason the toolkit drive is Ventoy but the one-off install on a stranger's PC is so often Rufus: same destination, very different relationship with the machine's security.
The video shows the 0x1A screen appearing on a real machine, the enrolment that clears it, and the Rufus drive booting past the same firmware without a murmur.
Watch Full VideoIt is the standard MokManager mechanism Linux has used for years - you are telling this one PC to trust Ventoy's signing key. It does not weaken Windows itself, and the trust can be removed from the same manager. Only enrol it on PCs where you are entitled to make that decision.
Yes. The trust lives in each machine's firmware, not on the USB drive, so every new Secure Boot PC asks once. After enrolment that machine boots Ventoy drives normally from then on.
BitLocker measures the boot environment, and a Secure Boot change alters that measurement, so Windows demands proof the change was yours. Enter the 48-digit recovery key from your Microsoft account or backup. Next time, suspend BitLocker before changing firmware settings and resume it after.