Riot Vanguard Explained: TPM 2.0, HVCI, and the Always-On Kernel Bootguard

Vanguard does something most kernel anti-cheats do not: its driver has historically loaded before you launch the game. When Windows finished boot, vgk.sys was already resident in ring 0, and the Riot Vanguard service was already running under the Service Control Manager. That single design decision reshaped the adversary problem for six years, and it is worth understanding precisely because Riot began softening it in June 2026.

What Riot Vanguard actually is

Riot Vanguard is the anti-cheat system Riot Games ships with Valorant and, since May 2024, with League of Legends. It consists of three pieces on Windows: a kernel-mode driver (vgk.sys), a usermode Windows service registered as vgc, and a tray helper (VGTray.exe). The usermode components handle game integration, communication with Riot's backend, and telemetry. The driver is the interesting part. It sits in ring 0, monitors the system, and provides the attestations the usermode service reports upstream.

Most kernel anti-cheats today (Easy Anti-Cheat, BattlEye, Ricochet in its kernel iteration) install their drivers as demand-start services. The driver loads when the game launches and unloads when the game exits. That is the model we covered in our breakdown of usermode versus kernel versus hybrid anti-cheat. Vanguard broke from that model at launch on April 7, 2020 and stayed with it until Vanguard On-Demand shipped in 2026.

Boot time anti cheat: why timing matters

The Windows Service Control Manager honors five start types for services: SERVICE_BOOT_START (0), SERVICE_SYSTEM_START (1), SERVICE_AUTO_START (2), SERVICE_DEMAND_START (3), and SERVICE_DISABLED (4). Boot-tier drivers are loaded by ntoskrnl before anything the SCM starts. Vanguard installed its driver as an early-start kernel service, so vgk.sys was resident during I/O initialization, well before any userspace process ran. Microsoft documents the semantics at learn.microsoft.com/en-us/windows-hardware/drivers/install/specifying-the-load-order-for-a-driver.

A registry entry for a boot-tier driver looks approximately like this:

[HKLM\SYSTEM\CurrentControlSet\Services\vgk]
Type          = 1                 ; SERVICE_KERNEL_DRIVER
Start         = 0                 ; SERVICE_BOOT_START (loaded by ntoskrnl)
ErrorControl  = 1                 ; SERVICE_ERROR_NORMAL
ImagePath     = \??\C:\Program Files\Riot Vanguard\vgk.sys
Group         = "Base"

The implication for adversaries is severe. A demand-start anti-cheat has to race with any cheat driver already resident when the game launches. Vanguard flipped the ordering. Any driver that wanted to hide from Vanguard had to be loaded after Vanguard was already watching, which means it had to survive live inspection rather than pre-empt one. Our companion post on how kernel cheats bypass usermode AC walks through why that ordering constraint hurts so much.

For signed-driver-abuse chains (where an attacker weaponizes a legitimately-signed third-party driver), this is the harder half of the problem. A DSE bypass that loads an unsigned driver has to do it while Vanguard is auditing every driver load through its callbacks.

Is Vanguard ELAM? No, and the distinction matters

Early Launch Anti-Malware is a specific Microsoft mechanism. ELAM drivers are certified by Microsoft, signed with an ELAM-specific certificate, and loaded by the Windows kernel before any other third-party boot driver. They exist to attest to the health of subsequent boot drivers, and their only legitimate use is anti-malware. Microsoft documents the requirements at learn.microsoft.com/en-us/windows-hardware/drivers/install/elam-driver-requirements.

Vanguard is not an ELAM driver. It is a regular kernel driver with an early start type, launched by the SCM through the standard driver load path. ELAM drivers get access to specific ELAM interfaces, cannot arbitrarily hook kernel structures without breaking their Microsoft attestation, and are audited by Microsoft's anti-malware team. Vanguard operates under standard WHQL and attestation-signing rules with none of those constraints. Our post on Windows kernel driver signing in 2026 covers where WHQL, attestation, and EV certificates fit together today. The distinction gets muddled in coverage; Riot has been reasonably transparent in dev.riotgames.com posts. It is not ELAM. It is a kernel driver that happens to load early.

League of Legends Vanguard: TPM 2.0 on Windows 11, not Secure Boot

Riot rolled Vanguard out to League of Legends in a phased release. Patch 14.8 landed on the Philippine server on April 17, 2024. The global rollout followed with Patch 14.9 on May 1, 2024. A lot of coverage got the requirements wrong.

On Windows 11, League of Legends requires TPM 2.0 to be enabled. If TPM 2.0 is missing or disabled, the client throws error VAN9001, documented at support.riotgames.com. Windows 10 systems are exempt from that TPM check for LoL, a deliberate concession to older hardware.

Secure Boot is where the requirements diverge from Valorant. Valorant on Windows 11 enforces Secure Boot. League of Legends does not. Riot's public explanation cited compatibility with older motherboard firmware. If you have seen a blog claim that LoL requires Secure Boot, that claim is wrong.

The rationale behind the TPM 2.0 check is a chain of trust. Measured Boot, backed by TPM 2.0, records what actually loaded during boot into PCRs (Platform Configuration Registers). Vanguard can query TPM measurements through TBS (TPM Base Services) and correlate them with what it sees at runtime.

Verifying whether TPM 2.0 is actually available (and at what version) from PowerShell is straightforward:

Get-Tpm | Format-List TpmPresent, TpmReady, TpmEnabled, ManufacturerVersion

Get-CimInstance -Namespace 'Root\CIMv2\Security\MicrosoftTpm' `
                -ClassName Win32_Tpm |
  Select-Object SpecVersion, PhysicalPresenceVersionInfo

Confirm-SecureBootUEFI

If SpecVersion begins with 2.0, TPM 2.0 is present. If TpmReady is False, the TPM exists but is not provisioned, which will fail Vanguard's Windows 11 check just as reliably as no TPM at all. Confirm-SecureBootUEFI returns True on a properly enrolled Secure Boot machine and throws if the firmware is in legacy CSM mode; that check matters for Valorant, less so for LoL.

Vanguard On-Demand: the 2026 pivot

On June 24, 2026, Riot released Vanguard On-Demand. The change is more than incremental. On eligible systems, the driver stays dormant at Windows boot and loads only when a Riot game launches. It closes when the game exits. That is the same lifecycle EAC and BattlEye have used for a decade, and Riot moving toward it after six years of defending always-on is a real concession.

Eligibility requires Windows 11 25H2 or later with UEFI Secure Boot, TPM 2.0, IOMMU, Virtualization-Based Security (VBS), and Hypervisor-Protected Code Integrity (HVCI) all enabled. Miss any one and the Vanguard Pre-Check bar refuses to activate On-Demand mode. Riot stated at launch that roughly 35% of Valorant's playerbase met the bar, growing 1 to 2 percentage points per month as newer hardware ages in.

The security model relies on Runtime Driver Attestation, co-developed with Microsoft's Xbox OS Security team. When Vanguard starts for a game session, it queries attestation data covering the boot state and every driver load event that occurred while Vanguard was dormant. If any driver loaded during the dormant window is not on Vanguard's allowlist, the game refuses to run. Riot traded persistent monitoring for cryptographic replay of what the kernel did while nobody was watching.

For players, a machine that clears the hardware bar can boot without Vanguard resident and only pay the ring 0 tax while Valorant or LoL is running. For cheat developers, the timing window did not actually open, because any driver loaded during the dormant window is a permanent black mark against the session.

Hypervisor detection and the VM problem

Vanguard actively probes for hypervisor presence. CPUID leaf 0x40000000 through 0x400000FF is the hypervisor CPUID range, and the presence of a hypervisor is trivially detectable via bit 31 of ECX in CPUID.1. A stealth hypervisor has to lie about all of those in a consistent way, which is difficult when the guest can also time RDTSC deltas around instructions that force a VMEXIT.

Riot's approach is nuanced. Microsoft's Hyper-V root partition is allowed, because Windows 11 24H2 turns Hyper-V on by default whenever VBS is active, and Vanguard On-Demand actively requires it. The check is not "any hypervisor is bad" but rather "an untrusted or non-attested hypervisor is bad." Running LoL or Valorant inside a VMware Workstation guest, or a nested Hyper-V child partition without Riot's approval, will get you refused. Vanguard does not run under Wine or Proton, and Valorant and LoL do not launch on SteamOS or Linux. GamingOnLinux tracks Vanguard's Proton status and the picture has not changed.

This closes a category of cheats: run the game in a VM, put the cheat in the host, use hypervisor-level introspection to read the guest's memory. The cheat process is invisible to any AC inside the guest, and the read pattern looks like normal DRAM access. Vanguard's VM detection eliminates that class of setup on its supported titles. At KyTech we have never targeted Valorant for exactly this stack of reasons.

VBS, HVCI, and vgk.sys under HVCI

Virtualization-Based Security (VBS) moves parts of the Windows kernel into a higher-privileged VTL1 (Virtual Trust Level 1) that VTL0 (the normal kernel) cannot inspect or modify. Hypervisor-Protected Code Integrity (HVCI) runs inside VTL1 and validates every page of executable memory before it can be marked executable in the kernel address space. Our HVCI deep dive covers the mechanism end to end.

For Vanguard, HVCI has two effects. First, its own driver must be HVCI-compatible: no self-modifying code, no dynamically allocated executable memory without the proper NX-then-CI path, no sections that are both writable and executable. Vanguard's vgk.sys has been HVCI-compatible for years, and On-Demand mode elevates HVCI from optional to mandatory.

Second, HVCI enforces the Microsoft signed third-party driver Blocklist. Every historically abused signed-third-party driver (dbutil_2_3.sys, Capcom.sys, various GIGABYTE and MSI utilities) is on that list, and HVCI refuses to load them. Cheat frameworks that relied on a known-good third-party signed driver suddenly need one that is not on the list.

On a machine where Vanguard is running with HVCI enabled and Secure Boot enforced, the cheat developer's options collapse. Even historically reliable primitives get harder. Consider a third-party driver that exposed physical memory mapping to usermode via an IOCTL:

// Illustrative signed-driver primitive: map arbitrary physical memory NonCached,
// copy it out, unmap. This is exactly the pattern Win11 24H2 broke.

NTSTATUS ReadPhysical(PHYSICAL_ADDRESS pa, PVOID out, SIZE_T size)
{
    PVOID mapped = MmMapIoSpace(pa, size, MmNonCached);
    if (mapped == NULL) {
        return STATUS_INSUFFICIENT_RESOURCES;
    }

    __try {
        RtlCopyMemory(out, mapped, size);
    } __except (EXCEPTION_EXECUTE_HANDLER) {
        MmUnmapIoSpace(mapped, size);
        return GetExceptionCode();
    }

    MmUnmapIoSpace(mapped, size);
    return STATUS_SUCCESS;
}

Windows 11 24H2 changed the behavior of MiShowBadMapper so that mapping a NonCached alias over a WriteBack kernel page produces a bugcheck. That single change killed a class of client-side page-table-walking signed-third-party-driver chains that had been the workhorse of external cheats for years. Vanguard's requirements amplify the pressure. Even if the cheat avoids the WB alias problem, HVCI will not let the driver load in the first place.

DMA cheats, IOMMU, and the May 2026 controversy

The one category of cheat that historically ignored client-side kernel anti-cheat is DMA hardware. A PCIe card with FPGA logic (typically running the PCILeech firmware family) reads system memory over the bus without touching the target OS. No process, no driver, no syscall the game or the AC can observe. Vanguard's ring 0 presence does not help if the read is happening from another device on the bus.

In May 2026, Riot pushed a Vanguard update that turns on IOMMU enforcement for accounts flagged for DMA cheat hardware. IOMMU lets the OS restrict which physical addresses a PCIe device can read, cutting DMA cheat cards off from mapping game memory. Community posts then claimed Vanguard was bricking cheaters' machines. Riot publicly denied it, stating that Vanguard "would not and cannot" damage hardware. The likelier explanation for the reported breakage: some UEFI firmware misreports Pre-Boot DMA Protection state, which Riot's own researchers disclosed in December 2025 as four CVEs spanning Asus, Gigabyte, MSI, and ASRock boards.

The controversy: always-on ring 0 access

Kernel anti-cheat has been controversial since Vanguard's original 2020 launch. The concerns are legitimate. A driver that loads at boot and stays resident has access to essentially everything a hostile kernel driver would have: physical memory, all process address spaces, network stack, keyboard and mouse input, filesystem. If it contains a bug, that bug is exploitable at ring 0. Vanguard had its share of early incidents with motherboard fan utilities and older MSI Afterburner builds, largely resolved during Valorant's first year.

The valid criticism is not that Vanguard is uniquely bad. It is that PC gaming has trended toward always-on ring 0 code shipped by whoever makes the game you want to play, with no principled way to audit any of it independently. Vanguard On-Demand walks part of that concern back for players with modern hardware, but not for the majority on Windows 10 or Windows 11 pre-25H2.

Vanguard versus other kernel anti-cheats

The comparison to demand-start kernel anti-cheats highlights where Vanguard sits in 2026:

The row that costs Vanguard the most goodwill is the last one. Removing Riot Vanguard requires a reboot because the driver cannot be unloaded from a running system while the service is active. Players who install Valorant once and then move on live with vgk.sys on their machine until they explicitly uninstall it and restart.

How KyTech handles this

KyTech does not ship a product for Valorant or League of Legends. This section exists to explain honestly why.

Boot-loaded kernel anti-cheat with TPM attestation, active hypervisor detection, HVCI-enforced driver signing, and (as of June 2026) IOMMU enforcement for DMA-flagged accounts does not leave a viable timing window for a competing kernel driver to load first, hide from ongoing kernel-side introspection, and survive attestation. Vanguard On-Demand's Runtime Driver Attestation closes even the small window a demand-start clone would have created. Every honest engineer working on this class of problem understands where the current frontier is. Valorant sits on the far side of it, and charging a customer for a product we are not certain we can keep working would be dishonest.

KyTech was founded in 2025 by two engineers. We ship kernel-mode products for Apex Legends, Counter-Strike 2, Overwatch 2, Call of Duty (BO7 era), Forza Horizon 6, and Roblox. Each of those titles ships an anti-cheat we have studied at the kernel level and shipped against. Our Apex product is where the current beta HWID spoofer lives, and it is the reference for how we build against demand-start kernel AC and Byfron-tier hybrid AC alike. On the VAC side, KyTech CS2 is our flagship, because Valve's demand-start model leaves exactly the timing window Vanguard's boot posture closes. Our press kit and pricing page cover the rest of what KyTech ships.

If you came here looking for a KyTech option for Valorant, there is not one, and there will not be one until the underlying situation changes in a way that lets us build something we are willing to put our name on. If you play any of the titles above, our product list is here. If you want to understand how the tiers of anti-cheat below Vanguard actually differ from each other, the usermode versus kernel versus hybrid breakdown is the right place to start.