Ventoy 1.1.15 Fixes Secure Boot Disabled Boot Issue for UEFI CA 2023 Transition

Ventoy 1.1.15 was released on June 25, 2026, following Ventoy 1.1.14 on June 24, to update the tool’s Secure Boot shim for Microsoft’s UEFI CA 2023 transition and fix a boot failure when Secure Boot is disabled. That sounds like a niche maintenance release for a niche utility, but it lands at the exact point where Microsoft’s oldest Secure Boot trust chain is aging out of the Windows ecosystem. For anyone who keeps a rescue USB in a drawer, images lab machines, or installs Windows on awkward hardware, this is the kind of small upstream change that decides whether a trusted tool still works when the firmware gets stricter. Ventoy’s rapid-fire update is less about a shiny feature than about survival in the new Secure Boot era.

A USB Utility Becomes a Canary for the Secure Boot Rollover​

Ventoy has always occupied a useful corner of the Windows toolbox because it breaks the usual rhythm of bootable USB creation. Instead of rewriting a flash drive every time a new Windows, Linux, WinPE, recovery, or hypervisor image is needed, Ventoy lets the user prepare the drive once and then copy image files onto it like ordinary files. For technicians, that convenience is not cosmetic; it turns one USB stick into a portable boot library.
That convenience also makes Ventoy unusually exposed to changes in firmware trust policy. A classic ISO-writing tool can create media that looks, to the boot chain, very much like Microsoft’s own installer media. Ventoy has to insert itself into the process, display a menu, chainload images, and keep working across a messy field of UEFI implementations, Secure Boot configurations, and operating system bootloaders.
The June 2026 update cycle shows the price of that ambition. Ventoy 1.1.13 appeared and was then deprecated because of a mistake. Ventoy 1.1.14 followed with the Secure Boot shim update, a synchronized VentoyPlugson update, and a new VTOY_SECURE_BOOT_POLICY option. Ventoy 1.1.15 then arrived shortly after to fix a boot issue that could occur when Secure Boot was disabled in UEFI firmware.
That sequence is messy, but it is also revealing. The old boundary between “Secure Boot problems” and “non-Secure Boot problems” is no longer clean. Updating the shim to follow the new certificate world can disturb machines even when the Secure Boot toggle is off, because firmware behavior is not a single standardized experience so much as a collection of platform-specific interpretations.

Microsoft’s 2011 Trust Chain Has Reached Its Expiration Date​

The backdrop is Microsoft’s Secure Boot certificate transition, a long-planned but now very real migration away from certificates issued in the early Windows 8 era. Secure Boot depends on firmware databases that decide which boot components are trusted before the operating system is allowed to load. The trust anchors that have underpinned much of the Windows PC ecosystem since 2011 are reaching the end of their validity window in 2026.
Microsoft’s replacement certificates, including the Windows UEFI CA 2023 and related 2023-era keys, are intended to keep the boot chain trustworthy after the older authorities expire. In plain English, Windows PCs need a refreshed set of keys so that future bootloaders, boot managers, and pre-OS components can be signed and verified without leaning forever on credentials from 15 years ago.
This is not simply bureaucratic key rotation. Secure Boot exists because the most dangerous malware does not wait politely for Windows Defender to start. Bootkits and pre-OS tampering attack the stage before the operating system can defend itself, which is why the boot path has become one of the most heavily policed parts of modern PC security.
The complication is that the PC ecosystem is not one thing. It is consumer laptops, OEM desktops, enthusiast motherboards, embedded systems, enterprise fleets, lab machines, offline recovery environments, old ISOs, new ISOs, third-party boot managers, Linux shims, hypervisor installers, and forgotten USB media. A certificate transition across that landscape was never going to be as simple as shipping a Windows Update and declaring victory.

Ventoy’s Shim Update Is a Compatibility Patch With Security Consequences​

The headline change in Ventoy 1.1.14 is the updated Secure Boot shim file to address the UEFI CA 2023 issue. In the Secure Boot world, the shim is the small but crucial bridge that allows a bootloader path to be accepted under firmware policy. For Linux distributions and multi-boot tools, shim has long been part of the uneasy compromise between user-controlled booting and platform-enforced trust.
Ventoy’s documentation now warns that since the 1.1.13 generation, users need to enroll a new key the first time they boot Ventoy in this new Secure Boot arrangement. That is the kind of sentence that will make normal users nervous and sysadmins nod grimly. Secure Boot key enrollment is manageable, but it is not the same frictionless experience as copying an ISO onto a flash drive.
This is where the politics of Secure Boot meets the practical world of repair benches. Microsoft’s platform security model wants fewer unsigned or ambiguously signed things executing before Windows. Tools like Ventoy exist because users and administrators need flexibility precisely when the machine is broken, being reimaged, or being asked to boot something it did not ship with.
The new VTOY_SECURE_BOOT_POLICY option matters because it gives users more control over how Ventoy behaves inside that tension. Ventoy’s own Secure Boot model has historically favored broad bootability, with options for users who want stricter policy enforcement. That is useful, but it also places responsibility back on the person preparing the media.
For home enthusiasts, that responsibility may mean reading a prompt carefully and enrolling a key once. For enterprises, it means deciding whether Ventoy belongs in the approved toolkit at all, and if it does, exactly how it should be configured and documented. In 2026, a bootable USB is no longer just a convenience item; it is a policy object.

The Disabled Secure Boot Bug Shows Firmware Still Has Teeth​

Ventoy 1.1.15 is the less glamorous but arguably more urgent release, because it fixes a boot issue when Secure Boot is disabled in UEFI firmware. On paper, that should be the easy mode. If Secure Boot is off, the firmware should not be enforcing Secure Boot verification, and a boot manager should have fewer hoops to jump through.
The reality is less tidy. Modern UEFI firmware often retains Secure Boot-related state, variables, menus, compatibility choices, and vendor-specific logic even when the user-facing switch says Secure Boot is disabled. Some systems distinguish between Secure Boot capability, Secure Boot enablement, Microsoft-only keys, third-party UEFI CA support, setup mode, custom mode, and legacy compatibility behavior.
That is why a bug in the disabled-Secure-Boot path is not contradictory. It is a reminder that tools like Ventoy are not booting against a clean abstract standard; they are negotiating with firmware written by many vendors over many years. One HP, Dell, Lenovo, ASUS, or custom-board behavior can differ just enough to expose a bug that did not appear on the maintainer’s test system.
For WindowsForum readers, this is probably the most practical lesson in the release. If a newly updated boot USB fails, the answer is not always “turn Secure Boot off.” That advice used to be a reliable blunt instrument. In the CA 2023 transition period, it may only move the failure from one branch of firmware logic to another.
The better habit is to treat boot media as something that needs periodic validation, not a talisman. If a Ventoy stick is part of your recovery kit, boot it on representative hardware before you need it. If you manage a fleet, test it against the machine families that matter, including systems with the newest firmware and systems that have received the latest Windows Secure Boot certificate updates.

The Rufus Comparison Is Really a Philosophy Split​

Neowin’s framing naturally invokes Rufus, because Rufus remains the better-known third-party tool for creating Windows installation media with extra knobs. Rufus can write bootable media, download Windows ISOs, and expose options that Microsoft’s own Media Creation Tool does not, including paths that help bypass Windows 11 setup constraints in certain scenarios. It is a purpose-built instrument for producing a particular bootable USB.
Ventoy is different. It is less like a disc burner and more like a pocket boot manager. Rufus turns a USB drive into this installer. Ventoy turns a USB drive into a menu of possibilities.
That distinction matters under Secure Boot. A Rufus-created Windows installer is closer to the expected Microsoft media path, especially when the goal is just to install Windows. Ventoy has to support a broader universe: Windows ISOs, Linux distributions, WinPE images, rescue disks, VHDs, WIMs, and other bootable formats. Every extra use case increases the surface area for firmware weirdness.
But the same breadth is why Ventoy remains so attractive. A field technician does not want six USB sticks labeled Windows 11, Windows Server, Ubuntu, MemTest, rescue, and vendor firmware. A homelab user does not want to rewrite a drive every time a new hypervisor image drops. A sysadmin does not want the incident response kit to depend on which ISO someone remembered to flash last week.
The CA 2023 update does not make Ventoy obsolete. It makes Ventoy’s maintenance cadence more important. In the old world, a working Ventoy stick could go untouched for months or years. In the new world, the boot medium is part of a moving chain of trust, and that chain is being actively replaced beneath it.

Microsoft’s Official Tool Is Safer Because It Is Narrower​

Microsoft’s Media Creation Tool has one great advantage over Ventoy and Rufus: it lives inside Microsoft’s intended lane. It creates Windows installation media for supported scenarios, and it does so without asking the user to understand third-party shims, custom key enrollment, or multi-boot edge cases. That narrowness is a feature.
It is also a limitation. Microsoft’s official tool will not be the favorite of people who need a single USB drive that can boot several operating systems, stage recovery environments, or carry a library of diagnostic images. It will not satisfy users who want more control over setup behavior, local account paths, hardware requirement workarounds, or repeatable lab workflows.
The Security Boot certificate transition sharpens this trade-off. The official tool aligns with Microsoft’s trust chain by design. Third-party tools must adapt to it. Users who pick the third-party route get flexibility, but they also inherit more operational responsibility.
That is not a moral failure by the third-party tools. It is the predictable outcome of a locked-down boot ecosystem that still needs to support legitimate repair, recovery, and installation work. The more Windows depends on pre-OS trust enforcement, the more every tool that touches the boot path must behave like infrastructure rather than a casual utility.
Microsoft would likely argue that this is exactly the point. Boot media should be trustworthy, revocable, and maintained. The counterargument, familiar to anyone who has recovered a dead machine at 2 a.m., is that recovery tooling must remain flexible enough to work when the official path does not.

The Enterprise Risk Is Not Ventoy, It Is Forgotten Media​

The obvious enterprise reaction to a Ventoy Secure Boot update is to ask whether Ventoy itself is safe to use. That is a fair question, especially because boot tools operate before the protections and logging that administrators rely on inside Windows. But the larger operational risk is not any one named utility; it is the pile of old boot media scattered across IT closets, desks, crash carts, and remote office kits.
A USB stick created in 2022 may still boot fine on some systems. It may fail on newer systems with updated firmware policy. It may work only if Secure Boot is disabled. It may work in one laptop line and fail in another. It may contain an old Windows installer whose boot components are signed under assumptions that are no longer universal.
That uncertainty is poisonous during an outage. The worst time to discover that recovery media no longer boots is during a ransomware response, a BitLocker recovery event, a failed firmware update, or a broken Windows feature update. The Secure Boot certificate rollover turns stale media from a mild nuisance into an availability risk.
Enterprises should be especially wary of treating the CA 2023 migration as a Windows-only patching task. Updating endpoints through Windows Update is only part of the job. The boot media used to service those endpoints must be refreshed and tested as well. So must deployment shares, offline images, WinPE environments, vendor firmware tools, and any custom recovery processes that assume old boot behavior.
Ventoy 1.1.15 is a useful prompt because it makes the invisible visible. If a community boot tool has to change its shim, add policy controls, and fix disabled-Secure-Boot behavior within a day, then the underlying platform shift is not theoretical. It is already changing what boots.

Enthusiasts Are Being Asked to Become Their Own PKI Clerks​

For Windows enthusiasts, the new Ventoy behavior adds an awkward ceremony: first-boot key enrollment. Many users have seen Secure Boot as a BIOS checkbox, not as a trust database with keys, authorities, allow lists, and revocation lists. Ventoy’s update drags some of that machinery into view.
That can be empowering. A user who understands Secure Boot keys is better equipped to run Windows, Linux, and recovery tools on their own terms. They can distinguish between disabling Secure Boot entirely and enrolling a key for a specific boot path. They can make more informed decisions about when convenience is worth a reduction in policy enforcement.
It can also be dangerous. Key enrollment prompts are not something users should click through blindly. The entire purpose of Secure Boot is to limit what firmware will trust before the operating system loads. Adding a key expands that trust boundary, and expanding it casually undermines the security model.
Ventoy’s documentation has long acknowledged that its Secure Boot approach involves trade-offs. The new Secure Boot policy option is therefore welcome, because it lets users move away from the broadest possible boot behavior if they want stricter enforcement. But the existence of the option does not make the decision easy.
This is the uncomfortable middle ground of modern PC ownership. Microsoft’s security direction assumes managed trust, measured boot, attestation, and controlled startup paths. Enthusiast computing assumes experimentation, dual-booting, recovery images, unsigned tools, and hardware reuse. Ventoy lives directly in the seam between those worlds.

HP’s Boot Problems Foreshadowed a Broader Support Burden​

The recent reports of HP systems encountering serious boot trouble after Secure Boot 2023 key updates were a warning shot for the whole ecosystem. Whether a specific incident is caused by firmware, Windows servicing, certificate state, or an interaction between them, the support burden looks the same to the person in front of the machine: it will not boot, and the usual fix may not be obvious.
That is the nightmare scenario for a root-of-trust migration. Security engineers can correctly say that certificate rollover is necessary and overdue. Users can also correctly say that a computer that fails to boot after a security update is not meaningfully more secure in the moment they need it.
The gap between those positions is where OEM quality matters. Firmware updates, Windows servicing stack changes, boot manager signing, recovery media, and third-party tools all have to move in coordination. Any weak link becomes a support forum thread, a help desk ticket, or a field visit.
Ventoy’s update is not responsible for OEM boot problems, but it is reacting to the same terrain. The updated shim addresses compatibility with the new CA world. The disabled-Secure-Boot fix acknowledges that even fallback paths can break. The key enrollment note tells users that the trust relationship has changed.
This is why the Secure Boot rollover should be understood as a platform migration, not a patch. It has a schedule, dependencies, prerequisites, failure modes, and user education problems. Microsoft may be driving the transition, but everyone who boots code before Windows has to participate.

Windows 11’s Hardware Rules Made Boot Tools Political​

It is impossible to discuss Rufus, Ventoy, and Windows 11 without mentioning Microsoft’s hardware requirements. TPM 2.0, Secure Boot capability, supported CPUs, and Microsoft account pressure during setup turned bootable USB utilities into instruments of user agency. They are no longer just ways to install Windows; they are ways to negotiate with Microsoft’s definition of an acceptable Windows PC.
That does not mean every workaround is wise. Installing Windows 11 on unsupported hardware can create future update, driver, and security complications. Bypassing account setup or requirement checks may be reasonable in a lab and reckless in a business. Context matters.
But Microsoft’s strictness created demand for tools that expose choices the official installer hides or discourages. Rufus became famous for those choices. Ventoy became valuable because it keeps many possible paths on one drive, including Windows images and non-Windows tools that Microsoft has no reason to prioritize.
The Secure Boot CA 2023 transition complicates that politics. Microsoft can credibly say the certificate update is about security hygiene, not user control. Still, the practical effect is that third-party boot paths must keep revalidating themselves against Microsoft-led trust infrastructure. The company does not have to ban a tool to make its maintenance harder; the platform can simply move.
That is not inherently malicious. Root certificate expiration is real. Bootkits are real. Fifteen-year-old trust anchors cannot last forever. But it does mean users who rely on non-Microsoft boot workflows should stop treating them as static utilities and start treating them as dependencies that need lifecycle management.

The New Rule for Rescue USBs Is Patch, Rebuild, Test​

The old habit was simple: once a boot USB worked, it was done. Maybe the ISO got stale, but the medium itself was considered reliable. Ventoy’s latest release is a reminder that this assumption has expired along with the old certificates.
For a home user, the new routine should be modest but real. Update Ventoy. Re-enroll the new key if Secure Boot requires it. Keep a known-good Windows installer created by Microsoft’s tool or Rufus as a fallback. Test the stick on the machine you actually expect to rescue.
For IT departments, the routine should be formal. Recovery media should have versioning, ownership, replacement schedules, and validation across representative hardware. If Secure Boot policy is part of the organization’s security baseline, then bootable USB tools should not be exempt from that policy just because they are convenient.
The transition also argues for keeping more than one path available. A Ventoy drive is excellent for breadth. A dedicated Windows installer is excellent for predictability. PXE or network boot is excellent for scale. Cloud recovery options are useful when local media fails. None of these replaces the others completely.
Most importantly, the rescue process should be documented while everything is calm. If the first time someone sees Ventoy’s new key enrollment flow is during an emergency, the organization has already lost time. A five-minute test in June can save an hour of guessing in October.

The Small Changelog That Should Change Your Boot Kit​

Ventoy 1.1.15 is not a dramatic release by feature count, but it is a useful forcing function for anyone who depends on removable boot media. The concrete lesson is that the Secure Boot certificate transition has reached the tools in your drawer, not just the firmware in your laptop.

• Ventoy 1.1.14 updated its Secure Boot shim for the UEFI CA 2023 transition and requires new key enrollment on first boot in affected Secure Boot scenarios.
• Ventoy 1.1.15 fixed a boot issue that could occur even when Secure Boot was disabled in UEFI firmware.
• Ventoy 1.1.13 should be avoided because the project deprecated that release after identifying a mistake.
• Windows users should refresh and test old Ventoy drives rather than assuming previously working boot media will survive the 2026 trust-chain migration unchanged.
• Administrators should treat recovery USBs, WinPE images, deployment media, and multi-boot tools as managed assets with their own update and validation cycle.
• A dedicated Microsoft or Rufus-created Windows installer remains a sensible fallback even for users who prefer Ventoy’s multi-ISO convenience.

The deeper story is that the PC boot process is becoming less forgiving because it has to be. Microsoft’s Secure Boot certificate rollover is a necessary maintenance event for a security model that cannot depend forever on 2011-era trust anchors, but necessary does not mean painless. Ventoy’s rushed sequence of releases is the ecosystem adapting in public: one shim update, one policy knob, one boot fix, and one more reminder that the tools we use to repair Windows are now part of the same security machinery as Windows itself.

---

References​

1. Primary source: Neowin
   Published: Thu, 25 Jun 2026 08:18:00 GMT
   
   Loading…

   www.neowin.net
2. Official source: learn.microsoft.com
   
   

   Update Secure Boot Certificates for Windows Devices - Windows Client | Microsoft Learn

   Update your Windows devices to maintain Secure Boot protection with 2023 certificates before they expire in June 2026.

   learn.microsoft.com
3. Official source: microsoft.com
   
   

   Prepare your servers for Secure Boot certificate updates | Microsoft Windows Server Blog

   The original Secure Boot certificates introduced in 2011 are approaching the end of their planned lifecycle, with expirations beginning in late June 2026.

   www.microsoft.com
4. Related coverage: windowslatest.com
   
   

   Windows 11 Secure Boot update released to all, hours ahead of expiry

   Microsoft has released Secure Boot 2023 certificates to all eligible Windows 11 and Windows 10 PC. Here's how to check if you got the update.

   www.windowslatest.com
5. Related coverage: notebookcheck.net
   
   

   Microsoft sets 2026 deadline for Secure Boot certificate expiration - Notebookcheck News

   Microsoft has issued new guidance warning that 2011 Secure Boot certificates begin expiring in June 2026. Windows updates are rolling out 2023 replacement certificates, with some PCs requiring OEM firmware updates.

   www.notebookcheck.net
6. Related coverage: ventoy.net
   
   Ventoy

   Ventoy is an open source tool to create bootable USB drive for ISO files. With ventoy, you don't need to format the disk again and again, you just need to copy the iso file to the USB drive and boot it.

   www.ventoy.net

Spoiler: Additional references (6)

1. Related coverage: windowscentral.com
   
   

   Microsoft warns Secure Boot certificates will expire in 2026 | Windows Central

   After 15 years, the original Secure Boot certificates that keep your PC secure during boot are expiring. Here's what you need to know.

   www.windowscentral.com
2. Related coverage: tomshardware.com
   
   

   Microsoft is refreshing Secure Boot certificates to plug security holes before they happen — if you bought a PC last year, you should be set | Tom's Hardware

   Be sure to keep Windows 11 systems updated to get refreshed security certificates.

   www.tomshardware.com
3. Related coverage: pcgamer.com
   
   

   Secure Boot certificates used by anti-cheat software are set to expire in June but new ones are already in the mail | PC Gamer

   You shouldn't have to worry about expired certificates if you keep your PC up-to-date.

   www.pcgamer.com
4. Related coverage: techradar.com
   
   

   Still using Windows 10? Microsoft is automatically replacing Secure Boot certificates on older PCs ahead of expiration, so you might want to update ASAP | TechRadar

   Secure Boot certificate upgrades is bad news for Windows 10

   www.techradar.com
5. Related coverage: advcloudfiles.advantech.com
   
   Loading…

   advcloudfiles.advantech.com
6. Related coverage: pcbug.org
   
   Slide 1

   PDF document

   pcbug.org